1. 5. Evaluation of Architecture Designs
1.1. Evaluate System Arch. Design?
1.1.1. ATAM (Architecture Trade-off Analysis Method)
1.1.2. SAAM (Software Architecture Analysis Method
1.1.3. ARID (Active Reviews for Intermediate Designs)
1.2. SAAM ( Software Architecture Analysis Method)
1.2.1. Evaluate design against Secenarios
1.2.2. Scenario
1.2.2.1. Similar but different from use case
1.2.2.2. Can contain situations not included in the scope of the project
1.3. Design Objective: Tax Report Processor
1.3.1. Process tax return forms
1.3.2. Information incorporated into an tax payer object
1.3.3. The object's type determined by occupation of the tax payer
1.4. Quality Attributes
1.4.1. System expandability
1.4.1.1. More occupation types can be added
1.4.2. System performance
1.4.2.1. Be able to process millions of case per day
1.4.2.2. Space efficiency a less concern
1.4.3. System modifiability
1.4.3.1. Format of tax forms and the method of calculating tax rates change every year
1.4.3.2. System must be ready for such changes
1.5. OCV
1.5.1. Business Ideology
1.5.1.1. Sell computers directly
1.5.2. Consumer order online
1.5.2.1. Parts ordered
1.5.3. Benefits
1.5.3.1. Low inventory cost & maximized efficiency
1.6. Two Steps
1.6.1. Selection of Architecture Style
1.6.2. High Level Design
1.7. Selection of Architecture Styles
1.7.1. Data flow
1.7.1.1. Batch & sequential
1.7.1.2. Pipe & filter
1.7.1.3. Process control
1.7.2. Data centric
1.7.2.1. Repository
1.7.2.2. Blackboard
1.7.3. Hierachy
1.7.3.1. Main-subroutine
1.7.3.2. Master/Slave
1.7.3.3. Layered
1.7.3.4. Virtual Machine
1.7.4. Implicit Invocation
1.7.4.1. Event based
1.7.4.2. Buffered message
1.7.5. Interaction Based
1.7.5.1. MVC
1.7.5.2. PVC
1.7.6. Distributed System
1.7.6.1. Client server
1.7.6.2. Multi-tier
1.7.6.3. Broker
1.7.6.4. SOA
1.7.7. Component Based
1.7.7.1. Candidate
1.8. Finalists
1.8.1. Batch sequential + repository
1.8.2. Layered or multi-tier
1.8.3. Service oriented architecture (SOA)
1.8.4. Component based architecture (CBA)
1.9. SOA vs. CBA
1.9.1. Dis of CBA
1.9.1.1. Older technique than SOA
1.9.1.2. No directory service such as UDDI
1.9.2. Benefits
1.9.2.1. Better efficiency
1.10. Final Decision
1.10.1. CBA vs. Batch sequential + data repository
1.10.1.1. CBA wins
1.10.2. How about multi-tier?
1.10.2.1. Good for web-portal
1.10.2.2. However, how about manufacturing system?
1.10.2.3. Mixed mode not clear cut -> out
1.10.3. Final decision: CBA
1.11. Order processing component
1.11.1. Similar to order processing system
1.11.2. Which architecture style to use?
1.11.2.1. MVC
1.11.2.2. CBA
1.12. Why separate controller and configuration
1.12.1. Controller handles the details
1.12.2. Configuration class handles the business logic
1.13. Inventory Management
1.13.1. Requirements
1.13.1.1. Manage all part (CPU, disk,..)
1.13.1.2. Allows reservation for an order
1.13.1.3. Interacts with manufacturing component to check out parts
1.13.1.4. Routinely check stock, generate order to supplies
1.13.2. Needed component
1.13.2.1. Backend DB
1.13.2.2. Controller which interacts with others
1.13.2.3. Satellite computer (barcode scanners) by workers
1.14. Design of Core-Engine Module
1.14.1. Architecture selection
1.14.1.1. Event-based
1.14.2. Assembly line started
1.14.2.1. Retrieve list of orders of the day
1.14.2.2. Send requests to inventory for parts
1.14.3. Parts delivered at one stage
1.14.3.1. Based on part code, find the order which uses it and update the information
1.14.3.2. When all parts ready, triggers the all parts ready event
1.15. Design of MS-Controller
1.15.1. Requirements
1.15.1.1. Interact with inventory for smooth supply-chain
1.15.1.2. Manage all stage computers for coordinating process
1.15.2. Architecture selection: Layered style
1.16. Design of Core Engine
1.16.1. All parts ready for an order
1.16.1.1. Schedule job to one of assembly lines
1.16.1.2. Consult business logic about split of manufacture process
1.16.1.3. Map "logical stages" to physical stages
1.16.2. Chassis arrived at one stage
1.16.2.1. Send job details to the stage computer
1.16.3. Parts malfunction
1.16.3.1. Send instruction: "Pull the chassis off line"
1.16.3.2. Send emergency parts retrieval requests
2. 1. Overview
2.1. Motivation
2.1.1. Real world projects are complex
2.1.2. Not likely one architecture suffices
2.1.3. Think about designing a castle
2.1.3.1. Walls
2.1.3.2. City hall
2.1.3.3. Civilian housing
2.1.4. Heterogeneous architecture styles are used to combine benefits of multiple styles and to ensure quality and appropriateness
2.2. Heterogeneous Architecture
2.2.1. Many ways to have heterogeneous arch
2.2.2. Hierarchical
2.2.2.1. Components composed using on arch
2.2.2.2. Each component internally using a different one
2.2.3. Mixture of Arch
3. 2. Methodology of Architecture Decision
3.1. Methodology of architecture decision
3.1.1. Question: Is the job of design to find one feasible solution? - No!
3.1.2. A designer has to
3.1.2.1. Exhaust all possible solutions
3.1.2.2. Pick up the best one
3.1.3. Task here
3.1.3.1. Given the list of architectural styles
3.1.3.2. Pick up the best one
3.2. Process of choosing styles
3.2.1. Architecture style heavily depends on requirement analysis
4. 3. Quality Attributes
4.1. Quality attributes
4.1.1. Used to make architectural decision
4.1.2. Common quality atrributes
4.1.2.1. Efficiency (time and space)
4.1.2.2. Functionality (completeness, interoperability)
4.1.2.3. Portability (hardware independence, instalability)
4.1.2.4. Reliability (error tolerance, availability)
4.1.2.5. Usability (user interface, learnability)
4.1.3. Architectural decision procedure
4.1.3.1. Determine the required quality attributes in requirement analysis
4.1.3.2. Quantify the quality attributes
4.1.3.2.1. Many can be directly quantified
4.1.3.2.2. Many should be assigned qualitative values first, the quantified
4.1.3.3. Compute the weighted sum
5. 4. Selection of Architecture Styles
5.1. Problem solved?
5.1.1. Not yet!
5.1.2. Decision framework done!
5.1.3. But how to evaluate architecture design against quality attributes?
5.2. Methods of evaluating Arch. Style
5.2.1. Largely depends on designer's expertise
5.2.2. However, tool available
5.2.2.1. Engineering handbook
5.2.2.2. Qualitative evaluation of Arch. Styles