Chapter 12

Heterogeneous Architecture
 Chapter 12 Objectives
• Introduce a general methodology of
making architecture decisions.
• Summarize the benefits and limitations of
each architectural style.
• Demonstrate how to apply the general
principles in case study examples.
 Motivation
• Real-World Projects Are Complex!
• Not likely One Architecture Suffices
• Think About Designing a Castle
– Walls
– City Hall
– Civilian Housing ...
 Heterogeneous Arch.
• Many ways to have heterogeneous arch.
• (1) Hierarchical
– Components composed using on arch.
– Each component internally using a different
one
• (2) Mixture of Arch.
– E.g., filter of a pipe&filter arch. accesses
central DB
 Our Plan
• Study How to Select Architecture Styles
• Go Through a Case Study
 Methodology of Architecture Decision

• Question: Is the job of design to find one

feasible solution? – No!
• A Designer Has To
– Exhaust all possible solutions
– Pick up the best one
• Task here:
– Given the list of architectural styles
– Pick up the best one
 Process of Choosing Style
• Arch. Style Heavily Depends on
Requirement Analysis
• Example:
– Why does not DOS in 80’s runs in Kernel
Mode?
– Limitation of the resources + different
requirements (user’s in 80’s don’t care too
much about crash of computers!)
 Flow Chart of Arch. Decision
Project Start

Yes

Gather Collect System Define Quality

Requirements Constraints Attributes

All Architectures Propose One

Yes No
Enumerated? Architecture

Solution Set
Empty?

No

Quality Attributes No
Evaluate and Select
Satisfied?
the Best Arch. Yes

Collect the Architecture

in Alternative Solution
Set
 Quality Attributes
• Used to make architectural decision
• Common Quality Attributes:
– Efficiency (time and space)
– Functionality (completeness, interoperability)
– Portability (hardware independence,
installability)
– Reliability (error tolerance, availability)
– Usability (user interface, learnability)
 Architectural Decision Procedure
• (1) Determine the required quality
attributes in requirement analysis
• (2) Quantify the quality attributes
– Many can be directly quantified
• E.g., time efficiency by throughput, latency, etc.
– Many should be assigned qualitative values
first, then quantified
• E.g., “Excellent”  100, “Average” 50, ...
• (3) Compute the weighted sum
 Example: Which to Choose?

Design 1 10 90 90 80 100 51
Design 2 80 80 20 90 70 73
Design 3 30 80 30 90 60 47
Design 4 20 20 20 20 100 36
Design 5 90 10 10 30 60 62

Example: Weighted Sum of Design 1

10*50% + 90*10% + 90*10% + 80*10% + 100*20% = 51

Solution: Design 2
 Problems Solved?
• Not Yet!
• Decision Framework Done!
• But How to Evaluate Architecture Design
Against Quality Attributes?
 Methods of Evaluating Arch. Style
• Largely depends on designers’ expertise
• However, tools available
– Engineering handbook
• E.g., typical applications such as DB app., Web
App. – typical designs in textbook/handbook
– Qualitative Evaluation of Arch. Styles
• See diagram in next slide
Evaluate System Arch. Design?
• Many approaches available
– ATAM (Architecture Trade-off Analysis
Method)
– SAAM (Software Architecture Analysis
Method)
– ARID (Active Reviews for Intermediate
Designs)
 SAAM (Software Architecture Analysis
Method )
• Idea: Evaluate design against Scenarios
• Scenario
– Similar but different from use case
• Can contain situations not included in the scope of
the project
• Example:
– Given an online registration system
• Sample scenario: what if the internal registration
form is changed?
• It tests the “modifiability” of the system
 Case Study: Tax Payer Design

AmericanCitizenTaxHandler AmericanCitizenTaxHandler AmericanTaxPayer

#yearlyIncome : double #yearlyIncome : double
+ReportTax() : double +ReportTax() : double +ReportTax() : int

AmericanLawyer AmericanLawyer

+ReportTax() : int +ReportTax() : int

AmericanLawyer AmericanLawyer
IRS IRS
+ReportTax() : int +ReportTax() : int

Desgin 1 Desgin 2
 Design Objective: Tax Report Processor

• Functionality:
– Process tax return forms
– Information incorporated into an tax payer
object
– The object’s type determined by occupation of
the tax payer
• E.g., AmericanLayer, AmericanProfessor, etc.
 Quality Attributes
• System expandability.
– More occupation types can be added
• E.g., AmericanFarmer, AmericanBusinessOwner, etc.
• System performance.
– Be able to process millions of cases per day
– Space efficiency is less concern
• System modifiability
– Format of tax forms and the method of calculating tax
rates change every year.
• System must be ready for such changes.
 Scenario 1: Expandability
• Scenario 1:
– Add AmericanFarmer
– What will happen?
 Scenario 2: Performance
• Scenario 2:
– Do a virtual testing.
– How will the system behave if it has to
process 1 million tax payers per day?
 Scenario 3: Modifiability

• Scenario 3:
– change the tax rate calculation method (e.g.,
to change the rules of itemized deduction).
 Evaluating Scenario 1
• Scenario 1:
– Add AmericanFarmer, What will happen?

AmericanCitizenTaxHandler AmericanCitizenTaxHandler AmericanTaxPayer

#yearlyIncome : double #yearlyIncome : double
+ReportTax() : double +ReportTax() : double +ReportTax() : int

AmericanLawyer AmericanLawyer

+ReportTax() : int +ReportTax() : int

AmericanLawyer AmericanLawyer
IRS IRS
+ReportTax() : int +ReportTax() : int

Design 2 is better!
Desgin 1 Desgin 2
 Evaluating Scenario 2
• Scenario 2:
– How will the system behave if it has to
process 1 million tax payers per day?
AmericanCitizenTaxHandler AmericanCitizenTaxHandler AmericanTaxPayer
#yearlyIncome : double #yearlyIncome : double
+ReportTax() : double +ReportTax() : double +ReportTax() : int

AmericanLawyer AmericanLawyer

+ReportTax() : int +ReportTax() : int

AmericanLawyer AmericanLawyer
Both designs
IRS IRS have similar
+ReportTax() : int +ReportTax() : int
performance!
Desgin 1 Desgin 2
 Evaluating Scenario 3
• Scenario 3:
– change the tax rate calculation method (e.g., to
change the rules of itemized deduction).

AmericanCitizenTaxHandler AmericanCitizenTaxHandler AmericanTaxPayer

#yearlyIncome : double #yearlyIncome : double
+ReportTax() : double +ReportTax() : double +ReportTax() : int

AmericanLawyer AmericanLawyer

+ReportTax() : int +ReportTax() : int

AmericanLawyer AmericanLawyer
IRS IRS
+ReportTax() : int +ReportTax() : int

Desgin 1 Desgin 2
Both ok. Any
refinements?
 OCV (Online Computer Vendor)
• Business Ideology:
– Sell computers directly!
• Consumer order online
  Parts Ordered
 Product Assembled
  Product Shipped

• Benefits:
– Low inventory cost & maximize efficiency
 Requirement 1
• Web portal provided to customers
• Order can be highly customized
– Allows configuration of products step by step
• Customer can
– check out shopping cart,
– or save the shopping cart for later use.
• Credit card the only acceptable payment
method.
• The web portal should be able to serve
10000 customers simultaneously.
 Requirement 2
• A subsystem be provided to product
designers.
• When product released, the designer can
input the basic configuration of the product
• When the specification of the new product is
done, the corresponding web pages should
be automatically generated
• Inventory DB and the subsystem for
assembly lines should also incorporate the
information immediately.
 Requirement 3
• A subsystem should be developed to
assist assembly lines.
• Each worker on an assembly line is
equipped with a computer system which
shows the job details that the worker has
to perform.
 Requirement 4
• An automatic inventory management system
should be developed to trace the inventory.
• An automatic scheduler reports the
estimated number of parts required every
day.
• The reports, if approved by business
managers, are converted to parts orders to
suppliers.
 Requirement 5
• The whole OCVS system should bridge
information among all departments to
maximize the efficiency of the organization.
• The involved departments include
– order processing department
– manufacture and shipping department
– product design engineers
– business strategy makers
 Requirement 6 (Quality Attributes)
• Expandable
– new products can be easily added
– can expand to serve more customers.
– cost of system increases linearly
• Modifiable
– Allows modification of internal representation of
products and configuration process over the time.
– The business rules (e.g., parts usage prediction),
web pages of products, and configuration
process will go through frequent changes.
 Requirement 6
(Quality Attributes)

• Reliable and available

– especially for the modules that interact with
customers and manufacture line.
• Time efficiency is required for all
modules.
– Bottom line: Sell1 million PCs per year.
– Peak time requirement: to support 10000
customers simultaneously.
 Two Steps
• Selection of Architecture Style
• High Level Design
Selection of Architecture Styles
• Data Flow
– Batch & Sequential:
• Candidate: suitable for order processing process.
Cons: low efficiency, assembly line support not
covered yet.
– Pipe & Filter:
• Ruled out: data transferred among dept. is not
stream
– Process Control:
• Ruled out: OCVS not in its application domain (e.g.,
embedded systems)
Selection of Architecture Styles
• Data Centric
– Repository
• Candidate: suits the needs for storing customer
data and product configuration.
• Cons: the pure model forbids communication
among system components.
– Blackboard
• Ruled out: OCVS not quite in its app. domain.
Debugging and testing very hard
Selection of Architecture Styles
• Hierarchy
– Main-Subroutine
• Ruled out: OCVS has to support multiple tasks (e.g., order
processing, inventory management and prediction, etc.).
There is no need for a central coordinator.
– Master/Slave
• Ruled out: similar to Main-program-Subroutine.
– Layered
• Candidate: the services of OCV can be classified into layers.
– Virtual Machine
• Ruled out: OCVS is not in its application domain (e.g.,
machine simulation and porting of existing systems)
 Selection of Architecture Style
• Implicit Invocation
– Event Based
• Ruled out: OCVS does not fall in its application
domain (e.g., GUI applications)
– Buffered Message
• Ruled out: OCVS does not fall in its application
domain.
 Selection of Architecture Style
• Interaction Based
– MVC
• Ruled out: Although the web portal subsystem
which interacts with customers may be a good
candidate using MVC, the OCVS system has many
other non-interactive sub-systems. Hence MVC is
not the most appropriate architecture style for
OCVS.
– PAC
• Ruled out: similar reason as MVC.
 Selection of Architecture Style
• Distributed System
– Client Server
• Ruled out: the model does not suit the multiple
components and multiple tasks of OCVS.
– Multi-tier
• Candidate: similar to layered system.
– Broker
• Ruled out: low efficiency and difficulty in testing.
– SOA
• Candidate: suits loosely coupled services and
departments.
 Selection of Architecture Style
• Component Based
– Candidate: suits loosely coupled services
provided by OCV. It has very good support
from UML. The architecture is very similar to
SOA, except that SOA provides service
directory (such as UDDI) to locate services,
which is not needed here.
– Cons: data representation may not be as
flexible as XML (semi-structured)
representation in SOA.
 Finalists
• Batch Sequential + Repository
• Layered or Multi-tier
• Service Oriented Architecture (SOA)
• Component Based Architecture (CBA)
 SOA vs. CBA
• Disadvantages of CBA (compared with SOA)
– Older technique than SOA
– No directory service such as UDDI (service yellow
page)
• Benefits
– Better efficiency
• No need to convert to XML, use binary data
exchange
• Can be stateful (unlike SOA)
– No need for directory service because all
components are well known inside
 Final Decision
• CBA vs. Batch Sequential + Data
Repository
– CBA wins (better support for concurrency)
• How about multi-tier?
– Good for web-portal
– However, how about manufacturing system?
• Many components mixed on the same tier -> not
clear cut  out
• Final Decision: CBA
 CBA Design
* 1
Financial
Department
ChargeCard
CreditCard
Company

Check Order
SaveOrder
Place Order4 Order Data
Processing ReadOrder Repository
* 1
Customer TakeOrder UpdateOrderStatus

ReserveParts
* 1 RetrieveParts
Inventory Manufacture
Management & Shipping
1 *
Parts Shipping Service
Suppliers Supplier
 Is The Design Complete?
• Req 1 (customer web portal)
– mapped to the Order Processing component.
• Req 2 (insertion of product configuration)
– not satisfied by the architecture design.
– System analysts and software architects suggest
removing this requirement.
– The argument is:
• to achieve Req 2, a specific product description language has
to be defined and the corresponding language interpreter has
to be implemented. Since OCVS does not release more than
20 products per year, there is really no need to build a
product description language and interpretation system. A
more convenient way is to insert product configuration
modules into the order processing system manually by
system engineer.
 Is the Design Complete?
• Req 3 (computer assisted manufacture system)
– Mapped to the Manufacture & Shipping component.
• Req 4 (smart inventory management)
– Mapped to the Inventory Management component.
• Req 5
– Reflected in the design of the overall structure where the
Data Repository component takes the charge of
maintaining live data.
 Is the Design Complete?
• expandability
– can be solved by manual addition of product
configuration modules into the Order Processing
component (not as good as the product description
language solution, but much less costly).
• Time efficiency and availability can be achieved
through replication of components, e.g., Order
Processing and Data Repository components.
• modifiability
– Not handled well
– When internal data representations of customer
profile or order details are changed, Data Repository
and other correlated components have to be modified.
 Order Processing Component
• Similar to Order Processing System (OPS)
• Which architecture style to use?
– MVC
• Good for separating presentation and business
logic
– Component Based Architecture
• Good for functional division
 Architecture of OPC

forward4
Product Config. forward4
3 forward (Model A1)

forward4
Browse Product Product Config. forward4
3 forward Check Out
Catalog (Model B1)

3 forward
Product Config. forward4
forward4 (Model B2)

3 forward
Drill Down: Product Configuration

Configuration
Request Update
Controller -state : int
-part list : object
+doPost() -instructions : string
Browser +getPartList() : object
+getInstructions() : string
+setSelectedParts()
+Next()
Forward Forward Forward +Prev()
+Cancel()
+Complete()

Error.jsp ProdConfig.jsp Catalog.jsp

(view) (view) (view)
 Why separate Controller and Configuration

• Controller handles the details

– E.g., HTTP request parameters
• Configuration class handles the business
logic
 Drill Down: State Diagram
Cancel()

setSelectedParts()
ConfigCPU Cancel()
entry/set part list to {1.5GHZ, 2.8GHZ, ...}
Cancel()
Next() Prev()
setSelectedParts()
Cancel()
ConfigMemory
Confirmed
entry/set part list to {500MB, 1GB, ...}
Next() Complete()
Prev()
setSelectedParts()

ConfigHardDrive ConfigAccessories
entry/set part list to {80GB, 100GB,...} entry/set part list to {mouse, camera, ...}

Next()
Prev() setSelectedParts()
 Inventory Management
• Requirements
– Manage all parts (CPU, disk, ...)
– Allows reservation for an order
– Interacts with manufacturing component to check out
parts
– Routinely checks stock, generates order to suppliers
• Needed components
– Backend DB
– Controller which interacts with others
– Satellite computers (barcode scanners) by workers
 Architecture Selection
• Which style?
– Data Repository + Client-Server (for satalite computers)

Satellite Satellite Satellite

Computer 1 Computer 2 Computer 2

GetNewJob, ReportJobStatus
GetNewJob, ReportJobStatus GetNewJob, ReportJobStatus

Reserve, UndoReserve Parts Inventory

Management
Controller
Order Processing

Daily Order
Insert, Remove, Lock, and Update Records
Retrieve Parts, Report Parts Arrival

Manufacture & Shipping Supplier

Inventory Database
 Manufacturing Department
• Assembly Line
– Maximize unit efficiency

Work Parts Work Parts Work Parts

Station Rack Station Rack Station Rack

Barcode - Barcode - Barcode -

Scanner Scanner Scanner
 Architecture Style Selection
• Which Style?
– Client Server

Manufacture & Shipping Controller

(MS-Controller)

Stage Computer 1 Stage Computer 2 Stage Computer 3

 Design of Manufacturing and
Shipping Controller
• Requirements
– Interact with Inventory for smooth supply-chain
– Manage all stage computers for coordinating process
• Architecture Selection: Layered Style

Order Processing

Communication
Core Engine Business Logic
Layer

1
Inventory Management

1..*

Benefits of separating
Stage Computer
them?
Design of Core-Engine Module?
• Architecture Selection?
– Event-Based!
• Assembly Line Started
– Retrieve list of orders of the day.
– Send requests to inventory for parts
• Parts delivered at one stage
– Based on part code, find the order which uses it
and update the information.
– When all parts ready, triggers the all parts ready
event.
 Design of Core Engine
• All parts ready for an order
– Schedule job to one of assembly lines
– Consult business logic about split of manufacture
process
– Map “logical stages” to physical stages
• Chassis arrived at one stage
– Send job details to the stage computer
• Parts malfunction
– Send instruction: “Pull the chassis off line ...”
– Send emergency parts retrieval requests
 Summary
• Take the solution that works best even if
it’s a mixed solution!