SOFTWARE ARCHITECTURE AND DESIGN PATTERNS

UNIT-II
UNIT-II: Analyzing Architectures: Architecture Evaluation, Architecture design decision
making, ATAM, CBAM
Moving from One System to Many: Software Product Lines, Building systems from off the
shelf components, Software architecture in future

1. ARCHITECTURE EVALUATION
Architecture evaluation has come to provide relatively a low-cost risk mitigation capability.
Making sure the architecture is the right one simply makes good sense. An architecture
evaluation should be a standard part of every architecture-based development methodology.
Evaluation can also be used to choose between two competing architectures by evaluating both
and seeing which one fares better against the criteria for "goodness."

Evaluations can be planned or unplanned.

 A planned evaluation is considered a normal part of the project's development cycle. It

is scheduled well in advance, built into the project's work plans and budget, and follow-
up is expected.
 An unplanned evaluation is unexpected and usually the result of a project in serious
trouble and taking extreme measures to try to salvage previous effort.

The planned evaluation is ideally considered an asset to the project, at worst a distraction from it.
Planned evaluations are pro-active and team-building.

An unplanned evaluation is more of an ordeal for project members, consuming extra project
resources and time in the schedule from a project already struggling with both. Unplanned
evaluations are reactive, and tend to be tension filled. An evaluation's team leader must take care
not to let the activities devolve into finger pointing.

A successful evaluation will have the following properties:

 Clearly articulated goals and requirements for the architecture. Architecture is only
suitable, or not, in the presence of specific quality attributes. One that delivers
breathtaking performance may be totally wrong for an application that needs
modifiability.
 Controlled scope. In order to focus the evaluation, a small number of explicit goals
should be enumerated. The number should be kept to a minimum? Around three to five?.
 Cost-effectiveness. Evaluation sponsors should make sure that the benefits of the
evaluation are likely to exceed the cost. The types of evaluation we describe are suitable
for medium and large-scale projects but may not be cost-effective for small projects.
 Key personnel availability. It is imperative to secure the time of the architect or at least
someone who can speak authoritatively about the system's architecture and design. This
person (or these people) primarily should be able to communicate the facts of the
architecture quickly and clearly as well as the motivation behind the architectural
decisions.

IV B. Tech I Semester (R16) 2019-20 1

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
 Competent evaluation team. Ideally, software architecture evaluation teams are separate
entities within a corporation, and must be perceived as impartial, objective, and
respected. The team must be seen as being composed of people appropriate to carry out
the evaluation, so that the project personnel will not regard the evaluation as a waste of
time and so that its conclusions will carry weight.
 Managed expectations. Critical to the evaluation's success is a clear, mutual
understanding of the expectations of the organization sponsoring it. The evaluation
should be clear about what its goals are, what it will produce, what areas it will (and will
not) investigate, how much time and resources it will take from the project, and to whom
the results will be delivered.
2. Architecture Tradeoff Analysis Method (ATAM)

The ATAM is so named because it reveals how well architecture satisfies particular quality
goals, and it provides insight into how quality goals interact? That is, how they trade off. The
ATAM is designed to elicit the business goals for the system as well as for the architecture. It is
also designed to use those goals and stakeholder participation to focus the attention of the
evaluators on the portion of the architecture that is central to the achievement of the goals.

2.1 Participants in the ATAM:

The ATAM requires the participation and mutual cooperation of three groups:

 The evaluation team: This group is external to the project whose architecture is being
evaluated. It usually consists of three to five people. Each member of the team is assigned
a number of specific roles to play during the evaluation.
 Project decision makers: These people are empowered to speak for the development
project or have the authority to mandate changes to it. They usually include the project
manager, and, if there is an identifiable customer who is footing the bill for the
development, he or she will be present (or represented) as well.
 Architecture stakeholders: Stakeholders have a vested interest in the architecture
performing as advertised. They are the ones whose ability to do their jobs hinges on the
architecture promoting modifiability, security, high reliability, or the like. Stakeholders
include developers, testers, integrators, maintainers, performance engineers, users,
builders of systems interacting with the one under consideration, and others.

Role Responsibilities Desirable characteristics

Sets up the evaluation; coordinates withWell-organized, with managerial
Team Leader client, making sure client's needs are skills; good at interacting with
met; establishes evaluation contract; client; able to meet deadlines
Runs evaluation; facilitates elicitation of
Comfortable in front of
scenarios; Administers scenario
audience; excellent facilitation
Evaluation Leader
selection/prioritization process; skills; good understanding of
architectural issues
Writes scenarios on flipchart or Good handwriting; stickler about
Scenario Scribe
whiteboard during scenario elicitation; not moving on before an idea

IV B. Tech I Semester (R16) 2019-20 2

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
captures agreed-on wording of each (scenario) is captured; can
scenario, halting discussion until exact absorb and distill the essence of
wording is captured technical discussions
Captures proceedings in electronic form Good, fast typist; well organized
on laptop or workstation, raw scenarios, for rapid recall of information;
Proceedings Scribe
issue(s) that motivate each scenario good understanding of
architectural issues;
Helps evaluation leader stay on schedule; Willing to interrupt discussion to
helps control amount of time devoted to call time
Timekeeper
each scenario during the evaluation
phase
Keeps notes on how evaluation process Thoughtful observer;
could be improved or deviated from; knowledgeable in the evaluation
Process Observer usually keeps silent but may make process; should have previous
discreet process-based suggestions to the experience in the architecture
evaluation leader during the evaluation; evaluation method
Helps evaluation leader remember and Fluent in the steps of the method,
carry out the steps of the evaluation and willing and able to provide
Process Enforcer
method discreet guidance to the
evaluation leader
Raise issues of architectural interest that Good architectural insights; good
stakeholders may not have thought of insights into needs of
stakeholders; experience with
Questioner systems in similar domains;
unafraid to bring up contentious
issues and pursue them; familiar
with attributes of concern

2.2 Outputs of the ATAM:

1. A concise presentation of the architecture. The architecture is presented in one hour

2. Articulation of the business goals. Frequently, the business goals presented in the ATAM
are being seen by some of the assembled participants for the first time and these are
captured in the outputs.
3. Prioritized quality attribute requirements expressed as quality attribute scenarios.
4. A set of risks and non-risks.
 A risk is defined as an architectural decision that may lead to undesirable
consequences in light of quality attribute requirements.
 A non-risk is an architectural decision that, upon analysis, is deemed safe.
 The identified risks form the basis for an architectural risk mitigation plan.
5. A set of risk themes. When the analysis is complete, the evaluation team examines the
full set of discovered risks to look for overarching themes that identify systemic
weaknesses in the architecture or even in the architecture process and team. If left
untreated, these risk themes will threaten the project’s business goals.

IV B. Tech I Semester (R16) 2019-20 3

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
6. Mapping of architectural decisions to quality requirements. For each quality attribute
scenario examined during an ATAM, those architectural decisions that help to achieve it
are determined and captured.
7. A set of identified sensitivity and tradeoff points. These are architectural decisions that
have a marked effect on one or more quality attributes.

2.3 Phases of the ATAM: Activities in an ATAM-based evaluation are spread out over four
phases.

Phase Activity Participants Typical duration

Partnership and preparation:
Proceeds informally as
Logistics, planning, Evaluation team leadership and
0 required, perhaps over
stakeholder recruitment, key project decision-makers
a few weeks
team formation
Evaluation team and project 1-2 days followed by a
1 Evaluation: Steps 1-6
decision-makers hiatus of 2-3 weeks
Evaluation team, project
2 Evaluation: Steps 7-9 2 days
decision makers, stakeholders
Follow-up: Report
Evaluation team and evaluation
3 generation and delivery, 1 week
client
process improvement

2.4 Steps of the Evaluation Phases

1. Present the ATAM (0 hours): Participants already familiar with process.

2. Present business drivers (0.25 hours): The participants are expected to understand the
system and its business goals and their priorities. A brief review ensures that these are fresh in
everyone’s mind and that there are no surprises.
3. Present architecture (0.5 hours): All participants are expected to be familiar with the
system. A brief overview of the architecture, using at least module and C&C views, is presented.
1-2 scenarios are traced through these views.
4. Identify architectural approaches (0.25 hours): The architecture approaches for specific
quality attribute concerns are identified by the architect. This may be done as a portion of step 3.
5. Generate QA utility tree (0.5-1.5hours): Scenarios might exist: part of previous evaluations,
part of design, part of requirements elicitation. Put these in a tree. Or, a utility tree may already
exist.
6. Analyze architectural approaches (2-3 hours): This step—mapping the highly ranked
scenarios onto the architecture—consumes the bulk of the time and can be expanded or
contracted as needed.
7. Brainstorm scenarios (0 hours): This step can be omitted as the assembled (internal)
stakeholders are expected to contribute scenarios expressing their concerns in step 5.

IV B. Tech I Semester (R16) 2019-20 4

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
8. Analyze architectural approaches (0 hours): This step is also omitted, since all analysis is
done in step 6.
9. Present results (0.5 hours): At the end of an evaluation, the team reviews the existing and
newly discovered risks, non-risks, sensitivities, and tradeoffs and discusses whether any new risk
themes have arisen.

3. Cost Benefit Analysis Method (CBAM)

The software architect or decision maker wishes to maximize the difference between the benefit
derived from the system and the cost of implementing the design. The CBAM begins where the
ATAM concludes and, in fact, depends upon the artifacts that the ATAM produces as output.
Figure 1 depicts the context for the CBAM.

Figure 1: Depicts the context for the CBAM

Implementing the CBAM

A process flow diagram for the CBAM is given in Figure 12.3. The first four steps are annotated
with the relative number of scenarios they consider. That number steadily decreases, ensuring
that the method concentrates the stakeholders' time on the scenarios believed to be of the greatest
potential in terms of ROI.
Step 1: Collate scenarios: Collate the scenarios elicited during the ATAM exercise, and give
the stakeholders the chance to contribute new ones. Prioritize these scenarios based on satisfying
the business goals of the system and choose the top one-third for further study.
Step 2: Refine scenarios: Refine the scenarios output from step 1, focusing on their stimulus-
response measures. Elicit the worst-case, current, desired, and best-case quality attribute
response level for each scenario.
Step 3: Prioritize scenarios: Allocate 100 votes to each stakeholder and have them distribute
the votes among the scenarios, where their voting is based on the desired response value for each
scenario. Total the votes and choose the top 50% of the scenarios for further analysis. Assign a
weight of 1.0 to the highest-rated scenario; assign the other scenarios a weight relative to the
highest rated. This becomes the weighting used in the calculation of a strategy's overall benefit.
Make a list of the quality attributes that concern the stakeholders.
Step 4: Assign utility: Determine the utility for each quality attribute response level (worst-case,
current, desired, and best-case) for the scenarios from step 3.

IV B. Tech I Semester (R16) 2019-20 5

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
Step 5: Develop architectural strategies for scenarios and determine their expected quality
attribute response levels: Develop (or capture already developed) architectural strategies that
address the chosen scenarios and determine the "expected" quality attribute response levels that
will result from them. Given that an architectural strategy may have effects on multiple
scenarios, we must perform this calculation for each scenario affected.
Step 6: Determine the utility of the "expected" quality attribute response levels by
interpolation: Using the elicited utility values (that form a utility curve), determine the utility of
the expected quality attribute response level for the architectural strategy. Do this for each
relevant quality attribute enumerated in step 3.
Step 7: Calculate the total benefit obtained from an architectural strategy: Subtract the
utility value of the "current" level from the expected level and normalize it using the votes
elicited in step 3. Sum the benefit due to a particular architectural strategy across all scenarios
and across all relevant quality attributes.
Step 8: Choose architectural strategies based on ROI subject to cost and schedule
constraints: Determine the cost and schedule implications of each architectural strategy.
Calculate the ROI value for each as a ratio of benefit to cost. Rank-order the architectural
strategies according to the ROI value and choose the top ones until the budget or schedule is
exhausted.
Step 9: Confirm results with intuition: For the chosen architectural strategies, consider
whether these seem to align with the organization's business goals. If not, consider issues that
may have been overlooked while doing this analysis. If there are significant issues, perform
another iteration of these steps.

4. SOFTWARE PRODUCT LINES

Software architecture represents a significant investment of time and effort, usually by senior
talent. So it is natural to want to maximize the return on this investment by re-using architecture
across multiple systems. Architecturally mature organizations tend to treat their architectures as
valuable intellectual property and look for ways in which that property can be leveraged to
produce additional revenue and reduce costs. Both are possible with architecture re-use.

Software product lines based on inter-product commonality represent an innovative, growing

concept in software engineering. Every customer has its own requirements, which demand
flexibility on the part of the manufacturers. Software product lines simplify the creation of
systems built specifically for particular customers or customer groups.

The improvements in cost, time to market, and productivity that come with a successful product
line can be breathtaking. Consider:

 Nokia is able to produce 25 to 30 different phone models per year (up from 4 per year)
because of the product line approach.
 Cummins, Inc., was able to reduce the time it takes to produce the software for a diesel
engine from about a year to about a week.

IV B. Tech I Semester (R16) 2019-20 6

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
 Motorola observed a 400% productivity improvement in a family of one-way pagers.
 Hewlett-Packard reported a time to market reduced by a factor of seven and a
productivity increase of a factor of six in a family of printer systems.

Creating a successful product line depends on a coordinated strategy involving software

engineering, technical management, and organization management.

Architectures for Product Lines: A product line architect needs to consider three things:

1. Identifying variation points: Identifying variation is an ongoing activity. Because of the

many ways a product can vary, variants can be identified at virtually any time during the
development process. Some variations are identified during product line requirements
elicitation; others, during architecture design; and still others, during implementation.
Variations may also be identified during implementation of the second (and subsequent)
products as well.

2. Supporting variation points: In a conventional architecture, the mechanism for achieving

different instances almost always comes down to modifying the code. But in a software
product line, architectural support for variation can take many forms:
Inclusion or omission of elements: This decision can be reflected in the build
procedures for different products, or the implementation of an element can be
conditionally compiled based on some parameter indicating its presence or absence.
Inclusion of a different number of replicated elements: For instance, high-capacity
variants might be produced by adding more servers? The actual number should be
unspecified, as a point of variation. Again, a build file would select the number
appropriate for a particular product.

3. Evaluating the architecture for product line suitability: Like any other, the
architecture for a software product line should be evaluated for fitness of purpose. In fact,
given the number of systems that will rely on it, evaluation takes on an even more
important role for product line architecture.

The good news is that the evaluation techniques described earlier in this book work well
for product line architectures. The architecture should be evaluated for its robustness and
generality, to make sure it can serve as the basis for products in the product line's
envisioned scope. It should also be evaluated to make sure it meets the specific
behavioral and quality requirements of the product at hand. We begin by focusing on the
and how of the evaluation and then turn to when it should take place.

What and How to Evaluate: The evaluation will have to focus on the variation points to
make sure they are appropriate, that they offer sufficient flexibility to cover the product
line's intended scope, that they allow products to be built quickly, and that they do not

IV B. Tech I Semester (R16) 2019-20 7

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
impose unacceptable runtime performance costs. If your evaluation is scenario based,
expect to elicit scenarios that involve instantiating the architecture to support different
products in the family. Also, different products in the product line may have different
quality attribute requirements, and the architecture will have to be evaluated for its ability
to provide all required combinations. Here again, try to elicit scenarios that capture the
quality attributes required of family members.

When to Evaluate: An evaluation should be performed on an instance or variation of the

architecture that will be used to build one or more products in the product line. The extent
to which this is a separate, dedicated evaluation depends on the extent to which the
product architecture differs in quality-attribute-affecting ways from the product line
architecture. If it does not differ, the product line architecture evaluation can be
abbreviated; since many of the issues normally be raised in a single product evaluation
will have been dealt with in the product line evaluation. In fact, just as the product
architecture is a variation of the product line architecture, the product architecture
evaluation is a variation of the product line architecture evaluation. Therefore, depending
on the evaluation method used, the evaluation artifacts (scenarios, checklists, etc.) will
have re-use potential, and you should create them with that in mind. The results of
evaluation of product architectures often provide useful feedback to the product line
architects and fuel architectural improvements.

IV B. Tech I Semester (R16) 2019-20 8

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
5. BUILDING SYSTEMS FROM OFF THE SHELF COMPONENTS
Consider the following situation. You are producing software to control a chemical plant. Within
chemical plants, specialized displays keep the operator informed as to the state of the reactions
being controlled. A large portion of the software you are constructing is used to draw those
displays. A vendor sells user interface controls that produce them. Because it is easier to buy
than build, you decide to purchase the controls? Which, by the way, are only available for Visual
Basic?

What impact does this decision have on your architecture? Either the whole system must be
written in Visual Basic with its built-in callback-centered style or the operator portion must be
isolated from the rest of the system in some fashion. This is a fundamental structural decision,
driven by the choice of a single component for a single portion of the system.

The use of off-the-shelf components in software development, while essential in many cases,
also introduces new challenges. In particular, component capabilities and liabilities are a
principle architectural constraint.

All but the simplest components have a presumed architectural pattern that is difficult to violate.
For example, an HTTP server assumes a client-server architectural pattern with defined
interfaces and mechanisms for integrating back-end functionality. If the architecture you design
conflicts with the architecture assumed by an HTTP server component, you may find yourself
with an exceptionally difficult integration task.

A prototype situated in a specific design context is called a model solution. A model problem
may have any number of model solutions, depending on the severity of risk inherent in the
design context and on the success of the model solutions in addressing it.

Model problems are normally used by design teams. Optimally, the design team consists of an
architect who is the technical lead on the project and makes the principal design decisions, as
well as a number of designers/engineers who may implement a model solution for the model
problem.

An illustration of the model problem work flow is shown in Figure 2. The process consists of the
following six steps that can be executed in sequence:

 The architect and the engineers identify a design question. The design question initiates
the model problem, referring to an unknown that is expressed as a hypothesis.
 The architect and the engineers define the starting evaluation criteria. These criteria
describe how the model solution will support or contradict the hypothesis.
 The architect and the engineers define the implementation constraints. The
implementation constraints specify the fixed (inflexible) part of the design context that
governs the implementation of the model solution. These constraints might include such
things as platform requirements, component versions, and business rules.

IV B. Tech I Semester (R16) 2019-20 9

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
 The engineers produce a model solution situated in the design context. The model
solution is a minimal application that uses only the features of a component (or
components) necessary to support or contradict the hypothesis.
 The engineers identify ending evaluation criteria. Ending evaluation criteria include the
starting set plus criteria that are discovered as a by-product of implementing the model
solution.
 The architect performs an evaluation of the model solution against the ending criteria.
The evaluation may result in the design solution being rejected or adopted, but often
leads to new design questions that must be resolved in similar fashion.

Figure 2: Model problem work flow

IV B. Tech I Semester (R16) 2019-20 10

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II
6. SOFTWARE ARCHITECTURE IN FUTURE
The history of programming can be viewed as a succession of ever-increasing facilities for
expressing complex functionality. In the beginning, assembly language offered the most
elementary of abstractions: exactly where in physical memory things resided (relative to the
address in some base register) and the machine code necessary to perform primitive arithmetic
and move operations.

The 1970s saw a concern with the structuring of programs to achieve qualities beyond correct
function. Data-flow analysis, entity-relation diagrams, information hiding, and other principles or
techniques formed the bases of myriad design methodologies, each of which led to the creation
of subroutines or collections of them whose functionality could be rationalized in terms of
developmental qualities. These elements were usually called modules.

In the 1980s, module-based programming languages, information hiding, and associated

methodologies crystallized into the concept of objects. Objects became the components du jour,
with inheritance adding a new kind of (non-runtime) connector.

In the 1990s, standard object-based architectures, in the form of frameworks, started appearing.
Objects have given us a standard vocabulary for elements and have led to new infrastructures for
wiring collections of elements together. Abstractions have grown more powerful along the way;
we now have computing platforms in our homes that let us treat complex entities, such as
spreadsheets, documents, graphical images, audio clips, and databases, as interchangeable black-
box objects that can be blithely inserted into instances of each other.

Architecture places the emphasis above individual elements and on the arrangement of the
elements and their interaction. It is this kind of abstraction, away from the focus on individual
elements that makes such breathtaking interoperability possible.

In the current decade, we see the rise of middleware and IT architecture as a standard platform.
Purchased elements have security, reliability, and performance support services that a decade ago
had to be added by individual project developers. We summarize this discussion in Figure 3.

.
Figure 3: Growth in the types of abstraction available over time

IV B. Tech I Semester (R16) 2019-20 11

 SOFTWARE ARCHITECTURE AND DESIGN PATTERNS
UNIT-II

Frequently Asked questions

1. Explain about various architecture Evaluation approaches?
2. Explain the participant of ATAM with their roles, responsibilities and characteristics?
3. Write a short note on outputs of ATAM and phases of ATAM?
4. Explain the evaluation steps of ATAM?
5. Briefly explain about Cost Benefit Analysis Method (CBAM) and evaluation steps?
6. Explain about Software Product Lines with suitable examples?
7. Explain in detail about building systems from off the shelf components with examples?
8. Write about Software architecture in future?

IV B. Tech I Semester (R16) 2019-20 12