Heterogeneous

Architectures
 For a large-scale software project,
heterogeneous architecture styles are used to
combine benefits of multiple styles and to
ensure quality and appropriateness.
Methodology of Architecture Decision
 Choosing Software System Architecture

 Requirements analysis has strong affinity with architecture selection.

 Architecture decisions are a result of requirements, priorities and constraints
(e.g., cost, time to create).

 The architecture most appropriate would be "optimal," trading off the various
competing needs of the system, rather than being good at one thing.

 Example: Operating System Design

 This is another common architecture (e.g. Mac OS, Unix, Windows).
 Advantage: High stability — a mistake in one layer does not spread to the
other layers.
 Architecture Selection Process

Actors: System analysts, software architects, stakeholders

1. Outline project details, requirements, constraints, and characterization of

quality attributes.
2. Functional Decomposition: Brief system functionalities
3. Suggest possible architectural patterns.
4. Mapping and Validation: Assign necessary functions against architecture
layers.
5. Measurable Quality Attributes Evaluation
6. Documentation: Create documentation on these proposed architectures as
candidate solutions
 Architecture Designs

Further Steps:

1. Do this for all proposed styles of architecture.

2. Evaluate results: Verify the satisfaction of required functions.
3. For each of the designs evaluate quality attributes
4. Refinement: Revise requirements
5. If no design are working:

i. Extend deadlines.
ii. Adjust budgets.
iii. Minimize functional requisites.

6. Then start over but with more precise limits.

7. End with either the best fitting architecture, or extinguish the project.
Quality Attributes
 Quality Attributes

 Part of a system’s nonfunctional requirements.

 Must be defined before detailed design begins.

Examples of Quality Attributes:

 Efficiency: Time Efficiency, Resource Economy.

 Functionality: Completeness, Security, Interoperability.

 Maintainability: Expandability, Modifiability, Testability.

 Portability: Hardware/Software Independence, Reusability.

 Reliability: Error Tolerance, Availability.

 Usability: Code Understandability, User Interface, Learnability.

 Challenges and Requirements

Implementation of architecture selection varies by practitioner expertise and

experience.
 Challenging Step:
1. Identifying and evaluating project quality attributes.
2. Relies on expertise of software architects and system analysts.
Special Requirements:
Vary by application domain and stakeholder priorities.
Example:
 IBM mainframes for banks prioritize maintainability, reliability, and security.
 Other stake holders may prefer efficiency over security.
 Quantitative vs. Qualitative Evaluation

 Some quality attributes can be measured directly (e.g., performance).

Examples: Bandwidth, throughput, latency, loss rate, jitter rate.

 Others (e.g., understandability, reliability) can be mapped qualitatively.

Example: "Excellent" = 90, "Bad" = 20 on a 100-point scale.

Quantitative Evaluation Framework

Steps:
1. Assign weighting factors to quality attributes based on stakeholder importance.
Example: Performance = 50%, Cost-effectiveness = 20%.
2. Evaluate each design using a scale (e.g., 0–100) for each quality attribute.
3. Calculate total weighted score for each design.
 A weighted score can be calculated for each design.
 For example, the total score of Design 1 is calculated as follows:
 10*50% + 90*10% + 90*10% + 80*10% + 100*20% = 51
 By comparing the total scores of all designs, we find that the choice is Design 2.
Once a quantitative evaluation framework is defined, software architects can

proceed with the architecture design with the following two steps:

1. Choose a proper architecture style.

2. Furnish the details of the architecture design.

For example, when the pipe-filter style is chosen, software architects still have to
determine what the filters will be and how to connect them.

Final Steps in Architecture Design

1. Choose an appropriate architecture style.
Example: Pipe-Filter,
2. Detail the design:
i. Define components (e.g., filters in pipe-filter).
ii. Specify interactions and connections between components.
Selection of Architecture Styles
 Selection often depends on software architect expertise.

 General Direction

 A concise comparison of the architecture styles and enumerates quality attributes.

 Each cell denotes whether an architecture style meets the corresponding quality

attribute as follows:

i. “+” signifies good,

ii. “++” signifies very good,

iii. “-” signifies bad, and

iv. “—” signifies very bad.

v. An empty cell denotes no explicit judgment for the style/attribute pair in the

general case..
Evaluation of Architecture Designs
 Evaluation Approaches

There are many systematic evaluation approaches, such as

 SAAM (Software Architecture Analysis Method)

 ATAM (Architecture Trade-off Analysis Method)

 ARID (Active Reviews for Intermediate Designs)

 How to Choose the Right Method

 Use SAAM for an initial evaluation focusing on modifiability and

scenario-based risks.

 Use ATAM for a comprehensive trade-off analysis involving multiple

quality attributes.

 Use ARID to validate and refine intermediate designs before full

implementation.

 Each method can be tailored to the project's needs, and combining

these methods may provide a more robust analysis.

 SAAM Analysis

The SAAM analysis process generally consists of three stages:

1. Define a collection of design scenarios that cover the functional and

nonfunctional requirements. Quality attributes should be reflected.

2. Perform an evaluation on all candidate architecture designs, using the

collection of scenarios.

3. Perform an analysis on the interaction relationship among scenarios

Case Study: Online Tax Processing System for
the Internal Revenue Service (IRS)
To improve the time efficiency, duplication of the current designs can be
considered. A task dispatcher accesses the sequential user data and distributes
the data to a number of IRS offices.
To evaluate the two candidate designs, the following three scenarios are designed:

 Scenario 1: Add one more occupation, called AmericanFarmer, into the system.
This scenario tests the expandability of the system.

 Scenario 2: Perform a virtual exhaustive testing on the system. How will the
system behave if it has to process one million taxpayers per day? The IRS object
includes a list of one million taxpayers, and it has to process each one by calling
the ReportTax() operation. This scenario tests the performance of the system.

 Scenario 3: Alter the tax rate calculation algorithm in ReportTax(), for example,
to change the rules of itemized deduction. This scenario tests the modifiability
of the system
 Evaluation Result

Scenario 1:
1. In Design 1 (on the left ), if a new class American-Farmer is added, the code
of the IRS class has to be modified.
2. Design 2 is superior due to its compliance with OCP (Open/Closed Principle).

Scenario 2: Both designs perform similarly under standard load.

1. Design 1 will have a slightly higher overhead in deciding which ReportTax()
operation to call based on the type of taxpayer instance.
2. Design 2's scalability is enhanced with the batch sequential architecture.

Scenario 3:
If the tax calculation algorithm changes, the AmericanCitizenTaxHandler class
has to be modified in both designs. Algorithm changes require updates in both
designs but can be optimized by introducing a strategy pattern.
The summarize result of the SAAM analysis on the two
architecture designs
 Software Architecture and Design
Illuminated, Qian, K., Fu, X., Tao, L.,
& Xu, C., Jones & Bartlett Learning,
MA, 2009

Ch # 12