Scribd
Upload
34 views12 pages

Week 11 Lecture No. 2: Heterogeneous Architectural Styles

This document discusses heterogeneous architectural styles and the methodology for selecting software architectures. It covers that multiple architecture styles are often used together in large projects, like how different styles are used for different parts of a medieval castle. When choosing architectures, all quality attributes and system constraints must be considered to select the optimal design. Various evaluation approaches can then be used to systematically analyze candidate architecture designs against defined scenarios and requirements. The process involves defining scenarios, evaluating designs using those scenarios, and analyzing interactions among scenarios.

Uploaded by

Husnain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
34 views12 pages

Week 11 Lecture No. 2: Heterogeneous Architectural Styles

This document discusses heterogeneous architectural styles and the methodology for selecting software architectures. It covers that multiple architecture styles are often used together in large projects, like how different styles are used for different parts of a medieval castle. When choosing architectures, all quality attributes and system constraints must be considered to select the optimal design. Various evaluation approaches can then be used to systematically analyze candidate architecture designs against defined scenarios and requirements. The process involves defining scenarios, evaluating designs using those scenarios, and analyzing interactions among scenarios.

Uploaded by

Husnain
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Week 11

Lecture No. 2

Heterogeneous Architectural Styles


Heterogeneous Architectures

 The responsibility of a good software architect is not to work out one feasible solution, but to
determine which architecture best suits the business needs.

 A number of architecture styles have been covered, including the data flow architectures (pipe filter,
process control), data centric architectures (repository), hierarchical, implicit asynchronous
communication, interaction-oriented, distributed, and component-based architectures.

 Given the large number of alternative architecture styles available, how do you choose the right one
that will achieve the project goals optimally (e.g., with the minimal cost)? This section guides you
through a brief introduction of the general methodology of determining software architecture under
given system constraints.
Example

 In practice, multiple architecture styles often have to be used in the same project.
Imagine yourself as the architect of a medieval castle.

 It is unlikely that the same architecture style can be used for all parts of a castle (e.g.,
moat, tower, drawbridge, curtain wall, castle hall, residential buildings for civilians).

 Similarly, 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

 An especially challenging step in architecture selection process is identifying and


evaluating project quality attributes.
 The success of this step depends on the expertise and experiences of software architects
and system.
 When all quality attributes are represented quantitatively, software architects can
enumerate feasible architecture designs and evaluate each quality attribute for each
design.
 As each quality attribute is assigned a weighting factor, defined during the earlier
requirement analysis, a total score can be calculated for each design
 When the evaluation process is complete, the design with the highest score can be
selected.
 The process of selecting the architecture of a software system is closely related to requirements
analysis.
 The requirements of a system, the priority of each requirement, and the system constraints
(project budget, release date, etc.) all determine the architecture to be used, even if it might not
be the most elegant, the fastest, or the most economical.
 The chosen architecture must be “optimal” and not necessarily focus on one particular aspect
of the system constraints.
.
Example

 Suppose that the system analysts on a project identify five quality attributes
during the requirement analysis: performance, reliability, usability, reusability,
and cost-effectiveness.
 Each of the quality attributes is assigned a percentage weighting factor; for
example, performance accounts for 50% of stakeholder concern among all quality
attributes. For each quality attribute the evaluation is represented using a value
between 0 and 100.
 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.
Evaluation of Architecture

 There are many systematic evaluation approaches, such as ATAM (Architecture


Trade-off Analysis Method), SAAM (Software Architecture Analysis Method),
and ARID (Active Reviews for Intermediate Designs).
SAAM

 The general idea of SAAM is to evaluate candidate architecture designs using a


collection of scenarios.
 A design scenario represents an important usage of a system and reflects the
viewpoints of stakeholders.
 A use case captures the required usage of the system; however, a scenario may
contain situations that are not included in the current scope of the project.
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.

You might also like