Unit iii-Architecture in the lifecycle

UNIT III
Architecture in the Life Cycle

CONTENTS
Architecture in Agile Projects–Agility and Architecture methods–
Example–Guidelines – Architecture and Requirements – Gathering
ASRs from requirements documents – Gathering ASRs by
interviewing stakeholders – Understanding Business Goals –
Capturing ASRs–Tying the methods – Designing an Architecture –
Design Strategy – Attribute driven design method – Steps of ADD

Architecture in Agile Projects
● Agile Project-Agile is an approach to project management. The word
'Agile' represents 'Rapid' and 'Respond To Change' and it will
continue driving changes in all types of organizations, especially,
software development. Agile is about delivering the best thing
possible in a limited time period
● Agile project management is an iterative approach to managing
software development projects that focuses on continuous releases
and incorporating customer feedback with every iteration

The authors of the Manifesto go on to describe the twelve principles that
underlie their reasoning:
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-
organizing
teams.
12. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.

How Much Architecture?
We often think of the early software development methods that emerged in the
1970s—such as the Waterfall method—as being plan-driven and inflexible
An Analytic Perspective on Up-front Work vs. Agility
Boehm and Turner, analyzing historical data from 161 industrial projects, examine
the effects of up-front architecture and risk resolution effort. This corresponds
to the COnstructive COst MOdel II (COCOMO II) scale factor called “RESL.”
There are two activities that can add time to the basic project schedule:
■■ Up-front design work on the architecture and up-front risk identification,
planning, and resolution work
■■ Rework due to fixing defects and addressing modification requests.

● So Boehm and Turner synthesized a model that allowed them to plot these
two values against each other. The axes of their graph (Figure 15.1) show
percent of time added for RESL and percent of time added to the schedule.
● The amount of architecture and risk resolution effort is plotted as the
dashed line, moving up and to the right from near the origin, and ranges from
5 to 50 percent of project effort.
● This effort is plotted against three hypothetical projects, measured in
thousands of source lines of code (KSLOC):
■■ One project of 10 KSLOC
■■ One project of 100 KSLOC
■■ One project of 10,000 KSLOC

● The sweet spot is the lowest point on the curve for each size program.
● The 10 KSLOC program (10,000 lines of code) for example, has its sweet spot at
the very beginning. This means that for very small programs, no more than 5
percent of the project schedule should be spent on design/architecture.
● Any more than 5 percent and you are increasing the project’s schedule without
any payback. For 100 KSLOC programs (100,000 lines of code), the sweet spot is
around 25 percent, and for 1000+ KSLOC (1 million lines of code or more), the
sweet spot is around 40 percent.
● The whole point of choosing how much time to budget for architecture is to
reduce risk. Risk may be financial, political, operational, or reputational

Agility and Architecture Methods
1.Architecture Documentation and YAGNI
● Our approach to architecture documentation is called Views and Beyond.Views and
Beyond and Agile agree emphatically on the following point: If information isn’t needed,
don’t spend the resources to document it. All documentation should have an intended use
and audience in mind, and be produced in a way that serves both
● One of our fundamental principles of technical documentation is “Write for the reader.”
That means understanding who will read the documentation and how they will use it. If
there is no audience, there is no need to produce the documentation. This principle is so
important in Agile methods that it has been given its own name: YAGNI. YAGNI means
“you aren’t gonna need it,” and it refers to the idea that you should only implement or
document something when you actually have the need for it.

● The Views and Beyond approach uses the architectural view as the “unit”
of documentation to be produced. Selecting the views to document is an
example of applying this principle. The Views and Beyond approach
prescribes producing a view if and only if it addresses substantial
concerns of an important stakeholder Community
● We document the portions of the architecture that we need to teach to
newcomers, that embody significant potential risks if not properly
managed, and that we need to change frequently. We document what we
need to convey to readers so they can do their job.

2.Architecture Evaluation
● Our approach to architecture evaluation is exemplified by the
Architecture Tradeoff Analysis Method (ATAM)
● The Architecture Tradeoff Analysis Method (ATAM) is a method for
evaluating software architectures relative to quality attribute goals.
● ATAM evaluations expose architectural risks that potentially inhibit the
achievement of an organization's business goals.
● The ATAM is the leading method in the area of software architecture
evaluation.
● An evaluation using the ATAM typically takes three to four days and
gathers together a trained evaluation team, architects, and
representatives of the architecture's various stakeholders.

Participants in ATAM :
The ATAM requires the participation of three groups as follows.
1. The evaluation team –
The evaluation team consists of the members who are external to the project. This
team consists of 3-5 members who play their specific roles in the team.
2. Project decision-makers –
Project decision-makers have the power to speak for the development of the project
and have the authority to mandate changes.
3. Architecture stakeholders –
Any individual, team, or organization who has an interest in the realization of the
architecture and is somehow related to the architecture is a stakeholder of that
architecture. Stakeholders include users, maintainers, performance engineers,
testers, integrators, developers.

Brief Example of Agile Architecting
● Our claim is that architecture and agility are quite compatible. Now
we will look at a brief case study of just that. This project, which one
of the authors worked on, involved the creation and evolution of a
web-conferencing system. Throughout this project we practiced
“agile architecting” Web-conferencing systems are complex and
demanding systems.
● They must provide real-time responsiveness, competitive features,
ease of installation and use, lightweight footprint, and much more

They must work on a wide variety of hardware and software platforms, the
details of which are not under the control of the architect.
● They must be reliable and provide low-latency response times,
particularly for real-time functionality such as voice over IP (VoIP) and
screen sharing.
● They must provide high security, but do so over an unknown network
topology and an unknown set of firewalls and firewall policies.
● They must be easily modified and easily integrated into a wide variety of
environments and applications.
● They must be highly usable and easily installed and learned by users with
widely varying IT skills.

In WebArrow web-conferencing system,To address the complexity,
WebArrow architect and developers found that they needed to think and
work in two different modes at the same time:
Top-down—designing and analyzing architectural structures to meet the
demanding quality attribute requirements and tradeoffs
Bottom-up—analyzing a wide array of implementation-specific and
environment-specific constraints and fashioning solutions to them

Here’s how it worked:
1.First, the WebArrow team quickly created and crudely analyzed an initial
software and system architecture concept, and then they implemented and
fleshed it out incrementally, starting with the most critical functionality that
could be shown to a customer.
2. They adapted the architecture and refactored the design and code whenever
new requirements popped up or a better understanding of the problem domain
emerged.
3. Continuous experimentation, empirical evaluation, and architecture analysis
were used to help determine architectural decisions as the product evolved.

For example, incremental improvement in the scalability and fault-tolerance
of WebArrow was guided by significant experimentation. The sorts of questions
that our experiments (spikes) were designed to answer were these:
■■ Would moving to a distributed database from local flat files negatively impact
feedback time (latency) for users?
■■ What (if any) scalability improvement would result from using mod_perl
versus standard Perl? How difficult would the development and quality assurance
effort be to convert to mod_perl?
■■ How many participants could be hosted by a single meeting server?
■■ What was the correct ratio between database servers and meeting servers?

The lesson here is that making architecture processes agile does not require a radical re-
invention of either Agile practices or architecture methods. The WebArrow team’s emphasis
on experimentation proved the key factor; it was our way of achieving an agile form of
architecture conception, implementation, and evaluation.
This approach meant that the WebArrow architecture development approach was in line with
many of the twelve principles, including:
■■ Principle 1, providing early and continuous delivery of working software
■■ Principle 2, welcoming changing requirements
■■ Principle 3, delivering working software frequently
■■ Principle 8, promoting sustainable development at a constant pace
■■ Principle 9, giving continuous attention to technical excellence and good design

Guidelines for the Agile Architect
Barry Boehm and colleagues have developed the Incremental Commitment
Model—a hybrid process model framework that attempts to find the balance
between agility and commitment. This model is based upon the following six
principles:
1. Commitment and accountability of success-critical stakeholders
2. Stakeholder “satisficing” (meeting an acceptability threshold) based on
success-based negotiations and tradeoffs
3. Incremental and evolutionary growth of system definition and stakeholder
commitment

4.Iterative system development and definition
5. Interleaved system definition and development allowing early fielding of
core capabilities, continual adaptation to change, and timely growth of
complex systems without waiting for every requirement and subsystem to
be defined
6. Risk management—risk-driven anchor point milestones, which are key to
synchronizing and stabilizing all of this concurrent activity

Architecture and Requirements
● An architecturally significant requirement (ASR) is a requirement that will have a
profound(deep) effect on the architecture—that is, the architecture might well be
dramatically different in the absence of such a requirement
● Architecturally significant requirements are those requirements that have a measurable
effect on a computer system's architecture. This can comprise both software and hardware
requirements.
● You cannot hope to design a successful architecture if you do not know the ASRs. ASRs often,
but not always, take the form of quality attribute requirements— the performance, security,
modifiability, availability, usability, and so forth, that the architecture must provide to the
system
● we introduced patterns and tactics to achieve quality attributes. Each time you select a
pattern or tactic to use in your architecture, you are changing the architecture as a result of
the need to meet quality attribute requirements. The more difficult and important the QA
requirement, the more likely it is to significantly affect the architecture, and hence to be an
ASR

● Gathering ASRs from Requirements Documents
● Gathering ASRs by Interviewing Stakeholders
● Gathering ASRs by Understanding the Business Goals
● Capturing ASRs in a Utility Tree
● Tying the Methods Together

1.Gathering ASRs from Requirements Documents
● An obvious location to look for candidate ASRs is in the requirements
documents or in user stories.
● After all, we are looking for requirements, and requirements should be in
requirements documents
Don’t Get Your Hopes Up
● Many projects don’t create or maintain the detailed and high quality
requirements document
● Standard requirements pay more attention to functionality than quality
attributes
● Most of what is in a requirements specification does not affect the
architecture

● No architect just sits and waits until the requirements are “finished”
before starting work. The architect must begin while the requirements
are still in flux
● Quality attributes, when captured at all, are often captured poorly.
○ “The system shall be modular”
○ “The system shall exhibit high usability”
○ “The system shall meet users’ performance expectations”
● Much of what is useful to an architect is not in even the best
requirements document.
○ ASRs often derive from business goals in the development organization itself;
○ Developmental qualities(such as teaming) are also out of scope

Sniffing Out ASRs from a Requirements Document
● Although requirements documents won’t tell an architect the whole story,
they are an important source of ASRs.
● Table 16.1 summarizes each category of architectural design decision,
and it gives a list of requirements to look for that might affect that kind
of decision. If a requirement affects the making of a critical
architectural design decision, it is by definition an ASR.

2.Gathering ASRs by Interviewing Stakeholders
● Say your project wont have the QAs nailed down by the time you need to
start your design work
● What do you do?
● Stakeholders often have no idea what QAs they want in a system
○ If you insist on quantitative QA requirements, you’re likely to get numbers that are
arbitrary
○ at least some of those requirements will be very difficult to satisfy
● Architects often have very good ideas about what QAs are reasonable to
provide
● Interviewing the relevant stakeholders is the surest way to learn what
they know and need

● The results of stakeholder interviews should include
○ list of architectural drivers
○ a set of QA scenarios that the stakeholders (as a group) prioritized
● This information can be used to do the following:
○ Refine system and software requirements
○ Understand and clarify the system’s architectural drivers
○ Provide rationale for why the architect subsequently made certain design
decisions
○ Guide the development of prototypes and simulations
○ Influence the order in which the architecture is developed

Quality Attribute Workshop
● The QAW is a facilitated, stakeholder-focused method to generate, prioritize, and
refine quality attribute scenarios before the software architecture is completed.
● The QAW is focused on system-level concerns and specifically the role that software
will play in the system
Step 1: QAW Presentation and Introductions
● QAW facilitators describe the motivation for the QAW and explain each step of the
method
● Everyone introduces themselves, briefly stating their background, their role in the
organization, and their relationship to the system being built.

Step 2: Business/Mission Presentation.
● The stakeholder representing the business concerns behind the system spends about one hour
presenting the system’s business context, broad functional requirements, constraints, and
known quality attribute requirements.
Step 3: Architectural Plan Presentation
● The architect will present the system architectural plans as they stand.
● This lets stakeholders know the current architectural thinking, to the extent that it exist
Step 4: Identification of Architectural Drivers
● The facilitators will share their list of key architectural drivers that they assembled during
steps 2 and 3, and ask the stakeholders for clarifications, additions, deletions, and
corrections.
● The idea is to reach a consensus on a distilled list of architectural drivers that includes overall
requirements, business drivers, constraints,and quality attributes

Step 5: Scenario Brainstorming
● Each stakeholder expresses a scenario representing his or her concerns with respect to the
system.
● Facilitators ensure that each scenario has an explicit stimulus and response.
● The facilitators ensure that at least one representative scenario exists for each architectural
driver listed in step 4.
Step 6: Scenario Consolidation
● After the scenario brainstorming, similar scenarios are consolidated where reasonable.
● Facilitators ask stakeholders to identify those scenarios that are very similar in content.
● Scenarios that are similar are merged, as long as the people who proposed them agree and feel
that their scenarios will not be diluted in the process.
● Consolidation helps to prevent votes from being spread across several scenarios that are
expressing the same concern.

Step 7: Scenario Prioritization
● Stakeholders can allocate any number of their votes to any scenario or
combination of scenarios. The votes are counted, and the scenarios are
prioritized accordingly.
Step 8: Scenario Refinement
● After the prioritization, the top scenarios are refined and elaborated.
● Facilitators help the stakeholders put the scenarios in the six-part scenario form
of source-stimulus-artifact-environment- response-response measure

Gathering ASRs by Understanding the Business Goals
There are three possible relationships between business goals and an
architecture:
● Business goals often lead to quality attribute requirements
● Business goals may directly affect the architecture without precipitating
a quality attribute requirement at all
● No influence at all. Not all business goals lead to quality attributes

A Categorization of Business Goals
1.Contributing to the growth and continuity of the organization
How does the system being developed contribute to the growth and continuity of the
organization?In one experience using this business goal category, the system being developed
was the sole reason for the existence of the organization.
2. Meeting financial objectives
This category is the cost of development, deployment, and operation of the system
3. Meeting personal objectives
Individuals have various goals associated with the construction of a system
4. Meeting responsibility to employees
In this category, the employees in question are usually those employees involved in
development or those involved in operation. Responsibility to employees involved in development
might include ensuring that certain types of employees have a role in the development of this
system
5. Meeting responsibility to society
All organizations must discharge a responsibility to society by obeying relevant laws and
regulations.

6.Meeting responsibility to state
Government systems, almost by definition, are intended to meet responsibility to a state or
country. Other topics that might come up in this category deal with export controls, regulatory
conformance, or supporting government initiatives.
7. Meeting responsibility to shareholders
liability protection and certain types of regulatory conformance such as, in the United States,
adherence to the Sarbanes-Oxley Act.
8. Managing market position
This category are the strategy used to increase or hold market share, various types of
intellectual property protection, or the time to market.
9. Improving business processes
It may be that improved business processes enable new markets, new products, or better
customer support.
10. Managing the quality and reputation of products
This category include branding, recalls, types of potential users, quality of existing products, and
testing support and strategies.
11. Managing change in environmental factors
business context for a system might change. This item is intended to encourage the stakeholders to

Expressing Business Goals
Our business goal scenario template has seven parts
1.Goal-source.
● These are the people or written artifacts providing the goal.
2. Goal-subject
● These are the stakeholders who own the goal and wish it to be true.
● Each stakeholder might be an individual the organization itself.
3. Goal-object
● These are the entities to which the goal applies. “Object” is used in the
sense of the object of a verb in a sentence. All goals have goal-objects
4.Environment.
● This is the context for this goal. For example, there are social, legal,
competitive, customer, and technological environments.

5. Goal.
● This is any business goal articulated by the goal-source.
6. Goal-measure.
● This is a testable measurement to determine how one would know if the goal has
been achieved. The goal-measure should usually include a time component, stating
the time by which the goal should be achieved.
7.Pedigree and value.
● The pedigree of the goal tells us the degree of confidence the person who stated
the goal has in it, and the goal’s volatility and value. The value of a goal can be
expressed by how much its owner is willing to spend to achieve it or its relative
importance compared to other goals. Relative importance may be given by a ranking
from 1 (most important) to n (least important), or by assigning each goal a value on
a fixed scale such as 1 to 10 or high-medium-low.

A General Scenario for Business Goals
● A general scenario is a template for constructing specific or “concrete”
scenarios.
● It uses the generic structure of a scenario to supply a list of possible
values for each non-boilerplate part of a scenario.
● See Table 16.4 for a general scenario for business goals.
● Note:boilerplate, is any written text (copy) that can be reused in
trademark

Capturing Business Goals
● One method for eliciting and documenting business goals is the Pedigreed
Attribute eLicitation Method, or PALM. The word “pedigree” means that
the business goal has a clear derivation or background.
● PALM uses the standard list of business goals and the business goal
scenario format.
● PALM can be used to sniff out missing requirements early in the life
cycle.
● PALM can also be used to discover and carry along additional information
about existing requirements.
● Finally, PALM can be used to examine particularly difficult quality
attribute requirements to see if they can be relaxed.

A Method for Capturing Business Goals
PALM is a seven-step method, nominally carried out over a day and a half in a workshop
attended by architects and stakeholders who can speak to the business goals of the
organizations involved. The steps are these:
1.PALM overview presentation. Overview of PALM, the problem it solves, its steps, and its
expected outcomes.
2. Business drivers presentation. Briefing of business drivers by project management. What
are the goals of the customer organization for this system? What are the goals of the
development organization? This is normally a lengthy discussion that allows participants to
ask questions about the business goals as presented by project management.
3. Architecture drivers presentation. Briefing by the architect on the driving business and
quality attribute requirements: the ASRs.

4. Business goals elicitation. Using the standard business goal categories to guide discussion,
we capture the set of important business goals for this system. Business goals are elaborated
and expressed as scenarios. We consolidate almost-alike business goals to eliminate
duplication. Participants the5. Identification of potential quality attributes from business
goals.
5. Identification of potential quality attributes from business goals. For each important
business goal scenario, participants describe a quality attribute that (if architected into the
system) would help achieve it. If the QA is not already a requirement, this is recorded as a
finding.
6. Assignment of pedigree to existing quality attribute drivers. For each architectural
driver named in step 3, we identify which business goals it is there to support. If none, that’s
recorded as a finding.
7. Exercise conclusion. Review of results, next steps, and participant feedback.

Capturing ASRs in a Utility Tree
● ASRs can be extracted from a requirements document, captured from
stakeholders in a workshop such as a QAW, or derived from business goals.
● It is helpful to record them in one place so that the list can be reviewed,
referenced, used to justify design decisions, and revisited over time or in the
case of major system changes.
To recap, an ASR must have the following characteristics:
● A profound impact on the architecture. Including this requirement will very
likely result in a different architecture than if it were not included.
● A high business or mission value. If the architecture is going to satisfy this
requirement—potentially at the expense of not satisfying others—it must be
of high value to important stakeholders.

● Architects can use a construct called a utility tree for all of these
purposes.
● A utility tree begins with the word “utility” as the root node. Utility is
an expression of the overall “goodness” of the system. We then elaborate
this root node by listing the major quality attributes that the system is
required to exhibit
● Under each quality attribute, record a specific refinement of that QA.
● For example, performance might be decomposed into “data latency” and
“transaction throughput.” Or it might be decomposed into “user wait
time” and “time to refresh web page.” The refinements that you choose
should be the ones that are relevant to your system. Under each
refinement, record the appropriate ASRs

● Some ASRs might express more than one quality attribute and so might appear in
more than one place in the tree.
● Once the ASRs are recorded and placed in the tree, you can now evaluate them
against the two criteria we listed above:
○ the business value of the candidate ASR and
○ the architectural impact of including it.
○ You can use any scale you like, but we find that a simple “H” (high), “M”
(medium), and “L” (low) suffice for each criterion.
● For business value,
○ High designates a must-have requirement,
○ Medium is for a requirement that is important but would not lead to project
failure were it omitted.
○ Low describes a nice requirement to have but not something worth much
effort.

● For architectural impact,
○ High means that meeting this ASR will profoundly affect the
architecture.
○ Medium means that meeting this ASR will somewhat affect the
architecture.
○ Low means that meeting this candidate ASR will have little effect on
the architecture.
● Table 16.5 shows a portion of a sample utility tree drawn from a
health care application called Nightingale.
○ Each ASR is labeled with a pair of “H,” “M,” and “L” values indicating (a) the ASR’s
business value and (b) its effect on the architecture.

Once you have a utility tree filled out, you can use it to make important
checks. For instance:
● A QA or QA refinement without any ASR is not necessarily an error or
omission that needs to be rectified, but it is an indication that attention
should be paid to finding out for sure if there are unrecorded ASRs in
that area.
● ASRs that rate a (H,H) rating are obviously the ones that deserve the
most attention from you; these are the most significant of the
significant requirements. A very large number of these might be a cause
for concern about whether the system is achievable.
● Stakeholders can review the utility tree to make sure their concerns are
addressed.

Tying the Methods Together
How should you employ requirements documents, stakeholder interviews, Quality Attribute
Workshops, PALM, and utility trees in concert with each other?
● If you have a requirements process that gathers, identifies, and prioritizes ASRs, then
use that and consider yourself lucky.
● Otherwise use one or more of the other approaches
● if nobody has captured the business goals behind the system you’re building, then a
PALM exercise would be a good way to ensure that those goals are represented in the
system’s ASRs.
● If you feel that important stakeholders have been overlooked in the requirements-
gathering process, use interviews or a QAW
● Building a utility tree is a good way to capture ASRs along with their prioritization

Finally, you can blend all the methods together:
● PALM makes an excellent “subroutine call” from a Quality Attribute
Workshop for the step that asks about business goals,
● Quality attribute utility tree makes an excellent repository for the
scenarios that are the workshop’s output.
Better to pick the approach that fills in the biggest gap in your existing
requirements: stakeholder representation, business goal manifestation, or
ASR prioritization.

Designing an Architecture
Design Strategy
● We present three ideas that are key to architecture design methods:
○ Decomposition,
○ Designing to architecturally significant requirements,
○ Generate and test.
1.Decomposition
● Architecture determines the quality attributes
● Important quality attributes are the characteristics of the whole system
● Design must begin with the whole system
○ The whole system is decomposed into parts
○ Each part may inherit all the part of the quality attribute requirements from
the whole system

Design does not mean green field
● If you are given components to be used in the final design, then the
decomposition must accommodate those components

2.Designing to architecturally significant requirements
● Remember architecturally significant requirements(ASRs)
● These are the requirements that you must satisfy with the design
○ There are a small number
○ They are most important
● If you are in experienced in design then design for ASRs one at a time
beginning with the most important
● As you gain experience, you will be able to design for multiple ASRs
simultaneously

What about the non-ASR requirements?
● The choice of ASRs implies a prioritization of the requirements.
● Once you have produced a design that satisfies the ASRs, you know that you
are in good shape. However, in the real world, there are other requirements
that, while not ASRs, you would like to be able to satisfy.
You have three options with respect to meeting these other requirements:
(a) You can still meet the other requirements.
(b) You can meet the other requirements with a slight adjustment of the existing
design, and this slight adjustment does not keep the higher priority requirements
from being met.
(c) You cannot meet the other requirements under the current design.

● In case (a) or (b), there is nothing more to be done. You are happy.
● In case (c), you now have three options:
(i) If you are close to meeting the requirement, you can see if the
requirement can be relaxed.
(ii) You can reprioritize the requirements and revisit the design.
(iii) You can report that you cannot meet the requirement. All of these
latter three options involve adjusting either the requirement or its
priority. Doing so may have a business impact, and it should be reported
up the management chain.

Design for all of the ASRs or one at a time?
● The answer to this question is a matter of experience.
● when you are designing to satisfy ASRs. Left to their own devices, novice
architects will likely focus on one ASR at a time.
● But you can do better than that.
● Eventually, through experience and education, you will develop an
intuition for designing, and you will employ patterns to aid you in designing
for multiple ASRs.

3.Generate and Test
● One way of viewing design is as a process of “generate and test.”
● This generate- and-test approach views a particular design as a
hypothesis: namely, the design satisfies the requirements.
● Testing is the process of determining whether the design hypothesis
is correct.
● If it is not, then another design hypothesis must be generated.

● For this process to be effective, the generation of the next design
hypothesis must build on the results of the tests.
● That is, the things wrong with the current design hypothesis are fixed in
the next design hypothesis, and the things that are right are kept.
● If there is no coupling between the testing and the generation of the
next design hypothesis, then this process becomes “guess and test”

Generate and test as a design strategy leads to the following
questions:
1. Where does the initial hypothesis come from?
2. What are the tests that are applied?
3. How is the next hypothesis generated?
4. When are you done?

Creating the Initial Hypothesis
● Design solutions are created using “collateral” that is available to the project.
● Collateral can include existing systems, frameworks available to the project, known
architecture patterns, design checklists, or a domain decomposition.
i.Existing system
● Existing system Very few systems are completely unprecedented, even within a single
organization. Organizations are in a particular business, their business leads to specialization,
and specialization leads to the development of variations on a theme.
● It is likely that systems already exist that are similar to the system being constructed in
your company.
● Existing systems are likely to provide the most powerful collateral, because the business
context and requirements for the existing system are likely to be similar to the business
context and requirements for the new system, and many of the problems that occur have
already been solved in the existing design.

A common special case
The existing design serves as the initial design hypothesis. The “test” part of this
process will reveal the parts that don’t work under the current (presumably
changed) set of requirements and will therefore pinpoint the parts of the
system’s design that need to change.
Another special case
when you have to combine existing legacy systems into a single system. In this
case, the collection of legacy systems can be mined to determine the initial design
hypothesis

ii.Frameworks:
● A framework is a partial design (accompanied by code) that provides
services that are common in particular domains.
● Frameworks exist in a great many domains, ranging from web applications
to middleware systems to decision support systems.
● The design of the framework provides the initial design hypothesis.
● For example, a design framework might constrain all communication to be
via a broker, or via a publish-subscribe bus, or via callbacks. In each case
this design framework has constrained your initial design hypothesis

iii.Patterns and tactics
A pattern is a known solution to a common problem in a given context.
Cataloged architectural patterns, possibly augmented with tactics, should be
considered as candidates for the design hypothesis you’re building.
iv.Domain decomposition
Another option for the initial design hypothesis comes from performing a
domain decomposition. For example, most object- oriented analysis and design
processes begin this way, identifying actors and entities in the domain. This
decomposition will divide the responsibilities to make certain modifications
easier, but by itself it does not speak to many other quality attribute
requirements.

v.Design checklists
The design checklists that can guide an architect to making quality-attribute-
targeted design choices.
The point of using a checklist is to ensure completeness
The checklist will provide guidance and confidence to an architect.

Choosing the Tests
1.The analysis techniques can be used
2. The design checklists for the quality attributes that can also be used to test the design
decisions already made, from the sources listed above. For the important quality attribute
requirements, use the design checklists to assess whether the decisions you’ve made so far
are sound and complete. For example, if testability is important for your system, the
checklist says to ensure that the coordination model supports capturing the activity that led
to a fault.
3. The architecturally significant requirements. If the hypothesis does not provide a solution
for the ASRs, then it must be improved.

Generating the Next Hypothesis
After applying the tests, you might be done—everything looks good. On the other
hand, you might still have some concerns; specifically, you might have a list of
quality attribute problems associated with your analysis of the current
hypothesis.
This is the problem that tactics are intended to solve: to improve a design with
respect to a particular quality attribute. Use the sets of tactics to help you to
choose the ones that will improve your design so that you can satisfy these
outstanding quality attribute requirements.

Terminating the Process
● You are done with the generate-and-test process when you either have a design that
satisfies the ASRs or when you exhaust your budget for producing the design.
● If you do not produce such a design within budget, then you have two options
depending on the set of ASRs that are satisfied.
○ Your first option is to proceed to implementation with the best hypothesis you
were able to produce, with the realization that some ASRs may not be met and may
need to be relaxed or eliminated. This is the most common case.
○ Your second option is to argue for more budget for design and analysis, potentially
revisiting some of the major early design decisions and resuming generate and test
from that point. If all else fails, you could suggest that the project be terminated.

The Attribute-Driven Design Method
The Attribute-Driven Design (ADD) method is a packaging of the strategies
and is an iterative method that, at each iteration, helps the architect to do
the following:
● Choose a part of the system to design.
● Marshal all the architecturally significant requirements for that part.
● Create and test a design for that part.

Inputs to ADD
● Before beginning a design process, the requirements—functional, quality, and
constraints—should be known.
● In reality, waiting for all of the requirements to be known means the project
will never be finished, because requirements are continually arriving to a
project as a result of increased knowledge on the part of the stakeholders
and changes in the environment (technical, social, legal, financial, or political)
over time.
● ADD can begin when a set of architecturally significant requirements is
known
● This increases the importance of having the correct set of ASRs.
● If the set of ASRs changes after design has begun, then the design may well
need to be reworked

In addition to the ASRs, input to ADD should include a context description. The
context description gives you two vital pieces of information as a designer:
● What are the boundaries of the system being designed?
○ What is inside the system and what is outside the system must be known in
order to constrain the problem and establish the scope of the architecture
you are designing.
● What are the external systems, devices, users, and environmental conditions
with which the system being designed must interact?
○ By “environmental conditions” here we are referring to the system’s
runtime environment.

○ The system’s environmental conditions are an enumeration of factors
such as where the input comes from, where the output goes, what forms
they take, what quality attributes they have, and what forces may affect
the operation of the system.
○ It is possible that not all of the external systems are known at design
time. In this case, the system must have some discovery mechanisms, but
the context description should enumerate the assumptions that can be
made about the external systems even if their specifics are not yet
known

Output of ADD
● The output of ADD is a set of sketches of architectural views. The views together will
identify a collection of architectural elements and their relationships or interactions.
● One of the views produced will be a module decomposition view, and in that view each
element will have an enumeration of its responsibilities listed
● Other views will be produced according to the design solutions chosen along the way. For
example, if at one point in executing the method, you choose the service-oriented
architecture (SOA) pattern for part of the system, then you will capture this in an SOA
view
● The interactions of the elements are described in terms of the information being
passed between the elements. For example, we might specify protocol names,
synchronous, asynchronous, level of encryption, and so forth

● ADD does identify the information that passes through the interfaces
and important characteristics of the information.
● If any aspects of an interface have quality attribute implications, those
are captured as annotations. When the method reaches the end, you will
have a full-fledged architecture that is roughly documented as a set of
views.
● You can then polish this collection, perhaps merging some of the views as
appropriate, to the extent required by your project.
● In an Agile project, this set of rough sketches may be all you need for
quite a while, or for the life of the project.

The Steps of ADD
ADD is a five-step method:
1. Choose an element of the system to design.
2. Identify the ASRs for the chosen element.
3. Generate a design solution for the chosen element.
4. Inventory remaining requirements and select the input for the
next iteration.
5. Repeat steps 1–4 until all the ASRs have been satisfied.

Step 1: Choose an Element of the System to Design
● For green-field designs, the “element” to begin with is simply the entire
system.
● The first trip through the ADD steps will yield a broad, shallow design
that will produce a set of newly identified architectural elements and
their interactions.
● These elements will almost certainly require more design decisions to
flesh out what they do and how they satisfy the ASRs allocated to them;
● During the next iteration of ADD, those elements become candidates
for the “choose an element” step

● So, nominally, the first iteration of ADD will create a collection
of elements that together constitute the entire system.
● The second iteration will take one of these elements—what we
call the “chosen element”—and design it, resulting in still finer-
grained elements.
● The third iteration will take another element—either one of the
children of the whole system or one of the children that was
created from the design of one of the children of the whole
system—and so forth

● For example, if you choose an SOA pattern in the first iteration, you
might choose child elements such as service clients, service providers,
and the SOA infrastructure components.
● In the next iteration through the loop, you would refine one of these
child elements, perhaps the infrastructure components.
● In the next iteration you now have a choice: refine another child of the
SOA pattern, such as a service provider, or refine one of the child
elements of the infrastructure components.
● Figure 17.2 shows these choices as a decomposition tree, annotated with
the ADD iteration that applies to each node

● At the first time through the steps of ADD you won’t pick “whole system” as the
starting point. Nevertheless, step 1 still holds: All it requires is that at least one
of the elements you know about needs further design.
● There are two main refinement strategies to pursue with ADD:
○ breadth first and depth first.
○ Breadth first means that all of the second-level elements are designed
before any of the third-level elements, and so forth.
○ Depth first means that one downward chain is completed before beginning a
second downward chain.

Some of the important factors include the following:
Personnel availability may dictate a refinement strategy.
● If an important group or team has a window of availability that will
close soon and will work on a particular part of the system, then it
behooves the architect to design that part of the system to the
point where it can be handed off for implementation—depth first.
● But if the team is not currently available but will be available at some
definite time in the future, then you can defer their part of the
design until later

Risk mitigation may dictate a refinement strategy
● The idea is to design the risky parts of the system to enough depth so that
problems can be identified and solved early.
● For example, if an unfamiliar technology is being introduced on the project,
prototypes using that technology will likely be developed to gain understanding of
its implications.
● These prototypes are most useful if they reflect the design of the actual system.
● A depth-first strategy can provide a context for technology prototyping. Using
this context you can build the prototype in a fashion that allows for its eventual
integration into the architecture.
● On the other hand, if the risk is in how elements at the same level of the design
interact with each other to meet critical quality attributes, then a breadth-first
strategy is in order.

Deferral of some functionality or quality attribute concerns may dictate a
mixed approach
● For example, suppose the system being constructed has a medium-
priority availability requirement. In this case you might adopt a strategy
of employing redundancy for availability but defer detailed
consideration of this redundancy strategy to allow for the rapid
generation of the high-priority functionality in an intermediate release.
● You might therefore apply a breadth-first approach for everything but
availability, and then in subsequent design iterations you revisit some of
the elements to enable the addition of the responsibilities to support
availability

Step 2: Identify the ASRs for This Element
● we described a number of methods for discovering the ASRs for a system.
One of those methods involved building a utility tree.
● To support the design process, the utility tree has an advantage over the
other methods: it guides the stakeholders in prioritizing the QA
requirements.
● The two factors used to prioritize the ASRs in a utility tree are business
value and architectural impact.
● The business value of an ASR typically will not change throughout the design
process and does not need to be reconsidered.

● If the chosen element for design in step 1 is the whole system, then a
utility tree can be a good source for the ASRs. Otherwise, construct a
utility tree specifically focused on this chosen element, using the quality
attribute requirements that apply to this element (you’ll see how to assign
those in step 4).
● Those that are labeled (High, High) are the ASRs for this element. As an
architect you will also need to pay attention to the (High, Medium) and
(Medium, High) utility tree leaves as well. These will almost certainly also
be ASRs for this element

Step 3: Generate a Design Solution for the Chosen Element
● This step is the heart of the ADD. It is the application of the generate-and-test
strategy. Upon entry to this step, we have a chosen element for design and a list of
ASRs that apply to it. For each ASR, we develop a solution by choosing a candidate
design approach.
● Your initial candidate design will likely be inspired by a pattern, possibly augmented
by one or more tactics. You may then refine this candidate design by considering
the design checklists that we gave for the quality attributes
● For ASRs that correspond to quality attributes, you can invoke those checklists to
help you instantiate or refine the major design approach (such as a pattern) that
you’ve chosen.
● For example, the layered pattern is helpful for building systems in which
modifiability is important, but the pattern does not tell you how many layers you
should have or what each one’s responsibility should be. But the checklist for the
“allocation of responsibilities” design decision category for modifiability

● Although this step is performed for each ASR in turn, the sources of design
candidates outlined above—patterns, tactics, and checklists—will usually do
much better than that.
● That is, you’re likely to find design candidates that address several of your
ASRs at once. This is because to the extent that the system you’re building is
similar to others you know about, or to the extent that the problem you are
solving is similar to the problems solved by patterns, it is likely that the
solutions you choose will be solving a whole collection of ASRs simultaneously.
● If you can bring a solution to bear that solves more than one of your ASRs at
once, so much the better.
● The design decisions made in this step now become constraints on all future
steps of the method.

Step 4: Verify and Refine Requirements and Generate Input for the
Next Iteration
● It’s possible that the design solution you came up with in the prior step won’t satisfy all
the ASRs.
● Step 4 of ADD is a test step that is applied to your design for the element you chose to
elaborate in step 1 of this iteration.
● One of the possible outcomes of step 4 is “backtrack,” meaning that an important
requirement was not satisfied and cannot be satisfied by further elaborating this design.
In this case, the design needs to be reconsidered.
● The ASRs you have not yet satisfied could be related to the following:
1. A quality attribute requirement allocated to the parent element
2. A functional responsibility of the parent element
3. One or more constraints on the parent element

● Step 4 is about taking stock and seeing what requirements are left that still have not
been satisfied by our design so far.
● At this point you should sequence through the quality attribute requirements,
responsibilities, and constraints for the element just designed.
For each one there are four possibilities:
The quality attribute requirement, functional requirement, or constraint has been satisfied.
● In this case, the design with respect to that requirement is complete; the next time
around, when you further refine the design, this requirement will not be considered.
● For example, if a constraint is to use a particular middleware and the system is
decomposed into elements that all use this middleware, the constraint has been
satisfied and can be removed from consideration.
● An example of a quality attribute requirement being satisfied is a requirement to make
it easy to modify elements and their interactions.
● If a publish-subscribe pattern can be shown to have been employed throughout the
system, then this QA requirement can be said to be satisfied.

The quality attribute requirement, functional requirement, or constraint is
delegated to one of the children.
● For example, if a constraint is to use a particular middleware and the
decomposition has a child element that acts as the infrastructure, then
delegating that constraint to that child will retain the constraint and
have it be reconsidered when the infrastructure element is chosen for
subsequent design.
● Similarly, with the example we gave earlier about providing extensibility,
if there is as yet no identifiable plug-in manager, then this requirement is
delegated to the child where the plug-in manager is likely to appear.

The quality attribute requirement, functional requirement, or constraint is
distributed among the children
● For example, a constraint might be to use .NET. In this case, .NET
Remoting might become a constraint on one child and ASP.NET on
another.
● Or a quality attribute requirement that constrains end-to-end latency of
a certain operation to 2 seconds could be distributed among the
element’s three children so that the latency requirement for one element
is 0.8 seconds, the latency for a second element is 0.9 seconds, and the
latency for a third is 0.3 seconds.
● When those elements are subsequently chosen for further design, those
times will serve as constraints on them individually.

The quality attribute requirement, functional requirement, or constraint
cannot be satisfied with the current design
● In this case there are the same two options we discussed previously: you
can either backtrack—revisit the design to see if the constraint or
quality attribute requirement can be satisfied some other way—or push
back on the requirement.
● This will almost certainly involve the stakeholders who care about that
requirement, and you should have convincing arguments as to why the
dropping of the requirement is necessary.

Step 5: Repeat Steps 1–4 Until Done
● After the prior steps, each element has a set of responsibilities, a set of
quality attribute requirements, and a set of constraints assigned to it. If
it’s clear that all of the requirements are satisfied, then this
unequivocally ends the ADD process.
● In projects in which there is a high degree of trust between you and the
implementation teams, the ADD process can be terminated when only a
sketch of the architecture is available
● On the other hand, if there is a contractual arrangement between your
organization and the implementation organization, then the specification
of the portion of the system that the implementers are providing must
be legally enforceable.
● This means that the ADD process must continue until that level of
specificity has been achieved.

● Finally, another condition for terminating ADD is when the project’s
design budget has been exhausted. This happens more often than you
might think. Choosing when to terminate ADD and when to start releasing
the architecture that you’ve sketched out are not the same decision.

Unit iii-Architecture in the lifecycle

More Related Content

Unit iii-Architecture in the lifecycle