ATAMATAMArchitecture Tradeoff Architecture Tradeoff

Analysis MethodAnalysis Method

Arnon Rotem-Gal-OzArnon Rotem-Gal-Oz

AgendaAgenda

Software architectureSoftware architecture

ATAM overviewATAM overview

ATAM stepsATAM steps

What’s ArchitectureWhat’s Architecture

“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”. (IEEE 1471)

Software ArchitectureSoftware Architecture

Architecture is importantArchitecture is important– it should be analyzedit should be analyzed

Architecture can be prescribedArchitecture can be prescribed– decisions should be analyzeddecisions should be analyzed

Architecture is central for communicating Architecture is central for communicating – it should be documentedit should be documented

Architecture is expensive to changeArchitecture is expensive to change– it is cheaper to analyze earlyit is cheaper to analyze early

Architecture affects the entire projectArchitecture affects the entire project– many stakeholders should be involvedmany stakeholders should be involved

Requirements can be understood earlyRequirements can be understood early– architecture should be designed to meet themarchitecture should be designed to meet them

ATAM - VocabularyATAM - Vocabulary

ScenarioScenario – A scenario is a short statement describing an – A scenario is a short statement describing an interaction of one of the stakeholders with the system interaction of one of the stakeholders with the system StakeholderStakeholder – An individual, team, or organization (or – An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, classes thereof) with interests in, or concerns relative to, a systema systemArchitectural viewArchitectural view – A representation of a whole system – A representation of a whole system from the perspective of a related set of concerns from the perspective of a related set of concerns Functional requirementsFunctional requirements - specify what software has to - specify what software has to do. do. Non-functional requirementsNon-functional requirements specify how well it should specify how well it should be done.be done.

What’s ATAMWhat’s ATAM

Purpose: To assess the consequences of Purpose: To assess the consequences of architectural decisions in light of quality architectural decisions in light of quality attribute* requirements.attribute* requirements.Primarily a risk identification mechanismPrimarily a risk identification mechanismNot a predictor of quality achievementNot a predictor of quality achievement

*Quality attribute = “ilities”*Quality attribute = “ilities”

System Quality AttributeSystem Quality Attribute

PerformancePerformance

AvailabilityAvailability

UsabilityUsability

SecuritySecurity

MaintainabilityMaintainability

PortabilityPortability

ReusabilityReusability

TestabilityTestability

End User’s view

Developer’s view

Time To MarketTime To MarketCost and BenefitsCost and BenefitsProjected life timeProjected life timeTargeted MarketTargeted MarketIntegration with Integration with Legacy SystemLegacy SystemRoll back ScheduleRoll back Schedule

BusinessCommunityview

ATAM – Cost/BenefitATAM – Cost/Benefit

CostCost– 1 – 2 weeks of time for 8 – 10 highly paid people, 2 days for 1 – 2 weeks of time for 8 – 10 highly paid people, 2 days for

another 10-12 people (for full formal process!)another 10-12 people (for full formal process!)– Delays project startDelays project start– Forces development of architecture up frontForces development of architecture up front

BenefitBenefit– Financial – saves moneyFinancial – saves money– Forces preparation / documentation / understandingForces preparation / documentation / understanding– Captures rationaleCaptures rationale– Catch architectural errors before builtCatch architectural errors before built– Make sure architecture meets scenariosMake sure architecture meets scenarios– More general, flexible architectureMore general, flexible architecture– Reduces riskReduces risk

ATAM StepsATAM StepsPhase 1 – evaluators and decision makers Phase 1 – evaluators and decision makers – Present Present

ATAMATAMBusiness driversBusiness driversArchitectureArchitecture

– Identify architectural approachesIdentify architectural approaches– Generate quality attribute utility treeGenerate quality attribute utility tree– Analyze architectural approachesAnalyze architectural approaches

Phase 2 – add stakeholders Phase 2 – add stakeholders – Brainstorm and prioritize scenariosBrainstorm and prioritize scenarios– Analyze architectural approachesAnalyze architectural approaches– Present resultsPresent results

Phase 3Phase 3– Analyze cost / benefit of ATAMAnalyze cost / benefit of ATAM

Repeat the last steps of phase 1 In a broader forum…

Step 1: Present ATAMStep 1: Present ATAM

Evaluation Team presents an overview of theEvaluation Team presents an overview of theATAM ATAM

• • ATAM steps in briefATAM steps in brief• • TechniquesTechniques

- utility tree generation- utility tree generation- architecture elicitation and analysis- architecture elicitation and analysis- scenario brainstorming/mapping- scenario brainstorming/mapping

• • OutputsOutputs- architectural approaches- architectural approaches- utility tree- utility tree- scenarios- scenarios- risks and “non-risks”- risks and “non-risks”- sensitivity points and tradeoffs- sensitivity points and tradeoffs

Step 2: Present Business DriversStep 2: Present Business Drivers

ATAM customer representative describes the system’s business drivers including:

– Business context for the system– High-level functional requirements– High-level quality attribute requirements

– Architectural drivers: quality attributes that “shape” the architecture

– Critical requirements: quality attributes most central to the system’s success

Step 3: Present the ArchitectureStep 3: Present the Architecture

Architect presents an overview of the architecture including (for example):

– Technical constraints such as an OS, hardware, or middle-ware prescribed for use

– Other systems with which the system must interact

– Architectural approaches/styles used to address quality attribute requirements

Evaluation team begins probing for and capturing risks.

Step 4: Identify Architectural Step 4: Identify Architectural ApproachesApproaches

Start to identify places in the architecture that are key for realizing quality attribute goals.

Identify any predominant architectural approaches – for example:– client-server– 3-tier– proxy– publish-subscribe– redundant hardware

Step 5: Generate Utility TreeStep 5: Generate Utility Tree

Identify, prioritize, and refine the most important quality attribute goals by building a utility tree.

– A utility tree is a top-down vehicle for characterizing the “driving” attribute-specific requirements

– Select the most important quality goals to be the high-level nodes (typically performance, modifiability, security, and availability)

– Scenarios are the leaves of the utility tree Output: a characterization and a prioritization of specific quality attribute requirements.

Step 5: Utility Tree /cont.Step 5: Utility Tree /cont.

Step 5- ScenariosStep 5- Scenarios

Scenarios are used to– Represent stakeholders’ interests– Understand quality attribute requirements

Scenarios should cover a range of– Anticipated uses of (use case scenarios),– Anticipated changes to (growth scenarios), or– Unanticipated stresses (exploratory scenarios) to the system.

A good scenario makes clear what the stimulus is that causes it and what responses are of interest.

Step 5 – Scenario examplesStep 5 – Scenario examples

Use case scenario– Remote user requests a database report via the Web during

peak period and receives it within 5 seconds.

Growth scenario– Add a new data server to reduce latency in scenario 1 to 2.5

seconds within 1 person-week.

Exploratory scenario– Half of the servers go down during normal operation without

affecting overall system availability.

Scenarios should be as specific as possible.

Step 6: Analyze Architectural Step 6: Analyze Architectural ApproachesApproaches

ScenariosScenarios

Vs. Vs.

ArchitectureArchitecture

Step 6: Analysis /cont.Step 6: Analysis /cont.

Evaluation Team probes architectural approaches from the point of view of specific quality attributes to identify risks.

– Identify the approaches that pertain to the highest priority quality attribute requirements

– Generate quality-attribute specific questions for highest priority quality attribute requirement

– Ask quality-attribute specific questions

– Identify and record risks and non-risks, sensitivity points and tradeoffs

Step 6: Analysis /cont.Step 6: Analysis /cont.

Quality attribute questions probe styles to elicit architectural decisions which bear on quality attribute requirements.

Examples– Performance

How are priorities assigned to processes? What are the message arrival rates? What are transaction processing times?

– ModifiabilityAre there any places where layers/facades are circumvented ?What components rely on detailed knowledge of message formats? What components are connected asynchronously?

Step 6: Sensitivity & TradeoffsStep 6: Sensitivity & Tradeoffs

Sensitivity – A property of a component that is critical to Sensitivity – A property of a component that is critical to success of system.success of system.– The number of simultaneous database clients will affect the number of The number of simultaneous database clients will affect the number of

transaction a database can process per second. This assignment is a transaction a database can process per second. This assignment is a sensitivity point for thesensitivity point for the performance performance

– Keeping a backup database affects Keeping a backup database affects reliabilityreliability– Power of encryption (Power of encryption (SecuritySecurity) sensitive to number of bits of the ) sensitive to number of bits of the

keykey

Tradeoff point- A property that affects more than one Tradeoff point- A property that affects more than one attribute or sensitivity point.attribute or sensitivity point.– In order to achieve the required level of In order to achieve the required level of performanceperformance in the discrete in the discrete

event generation component, assembly language had to be used event generation component, assembly language had to be used thereby reducing the thereby reducing the portabilityportability of this component. of this component.

– Keeping the backup database affects performance also so it’s a trade-Keeping the backup database affects performance also so it’s a trade-off between off between reliabilityreliability and and performanceperformance

Steps 6: Risks & Non-RisksSteps 6: Risks & Non-Risks

RiskRisk– The decision to keep backup is a risk if the The decision to keep backup is a risk if the performanceperformance cost is cost is

excessiveexcessive– Rules for writing business logic modules in the second tier of Rules for writing business logic modules in the second tier of

your 3-tier style are not clearly articulated. This could result in your 3-tier style are not clearly articulated. This could result in replication of functionality thereby compromising replication of functionality thereby compromising modifiabilitymodifiability of of the third tier.the third tier.

Non RiskNon Risk– The decision to keep backup is a non-risk if the The decision to keep backup is a non-risk if the performanceperformance

cost is not excessivecost is not excessive– Assuming message arrival rates of once per second, a Assuming message arrival rates of once per second, a

processing time of less than 30 ms, and the existence of one processing time of less than 30 ms, and the existence of one higher priority process, a 1 second soft deadline seems higher priority process, a 1 second soft deadline seems reasonable reasonable PerformancePerformance..

Step 7: Brainstorm & Prioritize Step 7: Brainstorm & Prioritize ScenariosScenarios

Stakeholders generate scenarios using a facilitated brainstorming process.

– Scenarios at the leaves of the utility tree serve as examples to facilitate the step.

– The new scenarios are added to the utility tree

Each stakeholder is allocated a number of votes roughly equal to 0.3 x #scenarios.

Step 8: Analyze Architectural Step 8: Analyze Architectural ApproachesApproaches

Identify the architectural approaches impacted by the scenarios generated in the previous step. This step continues the analysis started in step 6 using the new scenarios. Continue identifying risks and non-risks. Continue annotating architectural information.

Step 9: Present ATAM resultsStep 9: Present ATAM results

Architectural approachesArchitectural approaches

Utility treeUtility tree

ScenariosScenarios

Risks and “non-risks”Risks and “non-risks”

Sensitivity points and tradeoffsSensitivity points and tradeoffs