Architectural Analysis

Dr. Awais Majeed

[email protected]

Architectural Analysis

CSE-861 Software System Design & Architecture

Reasons for Architecture Evaluation Why?

Architectural decisions have downstream effects on the system being developed

These effects are known and predictable. So much is on stake, and it is economical to do it

before it becomes reality When?

It is cost-effective to evaluate software quality as early as possible in the life cycle

Evaluation can also be done to choose between two or more competing architectural solutions

The ATAM

It is a comprehensive method for architectural evaluation

Architecture Tradeoff Analysis Method (ATAM)

It reveals how well an architecture satisfies particular quality goals

It provides insight into how quality goals interact—that is, how they trade off

Evaluating an architecture for a large system is a complicated undertaking.

The ATAM …

computer system tends to support some specific business goals

the evaluation must interrelate these goals with the technical decisions

A large system has different stakeholders with different perspectives

Management of these stakeholders and their perspectives in a limited time is also difficult

Participant in the ATAM The evaluation team

External to the project 3-5 people Can be from the same organisation or some outside

consultants For roles of ATAM evaluation team refer to table 11.1

Project decision makers People who can make the decisions about the project Project manager, architect (must), or the customer

Architecture stakeholders They have their interests in the architecture performing as it

is advertised developers, testers, integrators, maintainers etc.

ATAM Evaluation Team Roles

Role: Evaluation Leader

Responsibilities:

Runs evaluation; facilitates elicitation of scenarios; administers scenario selection/prioritization process;

Desirable Characteristics:

Comfortable in front of audience; excellent facilitation skills; practiced in architecture evaluations; able to tell when prolonged discussion is leading to a valuable discovery or when it is pointless and should be re-directed

(Abstracted fromTable 11.1)

Outputs of the ATAM

1. A concise presentation of the architecture2. Articulation of the business goals3. Quality requirements in terms of a collection

of scenarios4. Mapping of architectural decisions to quality

requirements5. A set of identified sensitivity and tradeoff

points6. A set of risks and non-risks7. A set of risk themes

ATAM Phases

Phase Activity Participants Typical Duration

0 Partnership and preparation

Evaluation team leadership and key project decision makers

Proceeds informally as required, perhaps over a few weeks

1 Evaluation Evaluation team and project decision makers

1 day followed by a gap of 2 to 3 weeks

2 Evaluation (continued)

Evaluation team, project decision makers, and stakeholders

2 days

3 Follow-up Evaluation team and evaluation client

1 week

Steps in ATAM

Total 9 steps are involved in the evaluation/analysis phase

Steps 1-6 are performed in the first evaluation phase

In phase 2, with all stakeholders present, those steps are summarized and steps 7 through 9 are carried out.

ATAM Steps Step 1—Present the ATAM

Evaluation leader presents the ATAM process to the reps.

Step 2—Present Business Drivers A project decision maker (ideally the project manager or

the system's customer) presents a system overview from a business perspective The system's most important functions Any relevant technical, managerial, economic, or political

constraints The business goals and context as they relate to the project The major stakeholders The architectural drivers (that is, the major quality attribute

goals that shape the architecture)

ATAM Steps

Step 3—Present Architecture the lead architect (or architecture team) presents

the architecture at an appropriate level of detail The architect should convey the essence of the

architecture to make the most of limited time Show any technical constraints Present the architectural approaches used (in

terms of patterns, styles etc.)

[Refer to the Figure 11.1 to see what aspects can be covered in the presentation]

Important Architectural Information (4–8 slides) Context diagram Module or layer view Component-and-connector view Deployment viewArchitectural approaches, patterns, or tactics

employed (COTS) products and their integration use case scenarios change scenarios Architectural issues/risks

ATAM Steps

Step 4—Identify Architectural Approaches Main focus of the ATAM is to understand the

architectural approaches Architectural patterns are useful for the known

ways in which each one affects particular quality attributes.

the architect is asked to explicitly name the patterns and approaches used

The list is noted down and is displayed so that everyone can see it.

ATAM Steps

Step 5—Generate Quality Attribute Utility Tree High level quality attributes with respect to the

business goals were listed in step 2 However, their analysis is difficult with some

concrete context Modifiability; Modifiable in what way? Which aspect?

Quality attributes are articulated as utility trees. Most important quality attributes are expressed as

scenarios.

ATAM Steps - Step 5

Utility Tree A utility tree begins with utility as the root node. Utility is an expression of the overall "goodness"

of the system Quality attributes form the second level because

these are the components of utility Under each of these quality attributes are specific

quality attribute refinements performance might be decomposed into "data latency"

and "transaction throughput.“ Scenarios are the mechanism by which broad

(and ambiguous) statements of desired qualities are made specific and testable.

ATAM Steps - Step 5

the decision makers assign a priority to each scenario to short list or have a focused discussion

The high priority or most difficult scenarios will be analysed in detail ( most of the time will be spent on analysis)

Utility TreeQuality

AttribAttribute

Refin. Scenarios

Performance Transaction response time

A user updates a patient's account in response to a change-of-address notification while the system is under peak load, and the transaction completes in less than 0.75 second. (H,M)

    A user updates a patient's account in response to a change-of-address notification while the system is under twice the current peak load, and the transaction completes in less than 4 seconds. (L,M)

  Throughput At peak load, the system is able to complete 150 normalized transactions per second. (M,M)

  Generating reports

No scenarios suggested.

ATAM Steps

Step 6—Analyze Architectural Approaches highest-ranked scenarios evaluated one at a

time Questioners ask for the architectural approaches

that the architect used to carry out the scenario the team documents the relevant architectural

decisions and identifies and Catalogue their risks, nonrisks, and tradeoffs

ATAM Steps

Break and Start of Phase 2 First, step 1 is repeated so that the stakeholders

understand the method

Evaluation leader recaps the results of steps 2 through 6, and shares the current list of risks, non-risks, sensitivity points, and trade off points.

ATAM – Phase 2

Step 7—Brainstorm and Prioritize Scenarios Scenario brainstorming works well in larger

groups, creating an atmosphere in which the ideas and thoughts of one person stimulate others' ideas.

The prioritized list of brainstormed scenarios is compared with the utility tree exercise

Once the scenarios have been collected, they must be prioritized

ATAM Steps

Step 8—Analyze Architectural Approaches The highest ranked scenarios from step 7 are

chosen for analysis The architect presents the architectural decisions

taken to realise particular quality attributes Activities of step 6 are repeated by the evaluation

team

ATAM Steps

Step 9—Present Results The architectural approaches documented The set of scenarios and their prioritization from

the brainstorming The utility tree The risks discovered The non-risks documented The sensitivity points and tradeoff points found

[Table 11.3 Steps and ATAM Outputs, Correlated]

References and Further Reading

Chapter 11 of Software Architecture in Practice

Go through the case study given in the book to see how this approach can be applied [The Nightingale System]