Scribd Logo
Upload

Welcome to Scribd!

  • 1K views

    Architecture Tradeoff Analysis Method

    Uploaded by

    Reddappa Gowd
    A very good document Architecture Evaluation Technique method. Very useful for Architecture practitioners as well as Software Architecture proponents

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPT, PDF, TXT or read online from Scribd

    Architecture Tradeoff Analysis Method

    Uploaded by

    Reddappa Gowd
    1K views25 pages
    A very good document Architecture Evaluation Technique method. Very useful for Architecture practitioners as well as Software Architecture proponents

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PPT, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    A very good document Architecture Evaluation Technique method. Very useful for Architecture practitioners as well as Software Architecture proponents

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPT, PDF, TXT or read online from Scribd
    Download as ppt, pdf, or txt
    1K views25 pages

    Architecture Tradeoff Analysis Method

    Uploaded by

    Reddappa Gowd
    A very good document Architecture Evaluation Technique method. Very useful for Architecture practitioners as well as Software Architecture proponents

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PPT, PDF, TXT or read online from Scribd
    Download as ppt, pdf, or txt
    of 25

    ATAM

    Architecture Tradeoff
    Analysis Method

    Arnon Rotem-Gal-Oz
    Agenda
    Software architecture
    ATAM overview
    ATAM steps
    What’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 Architecture
    Architecture is important
    – it should be analyzed
    Architecture can be prescribed
    – decisions should be analyzed
    Architecture is central for communicating
    – it should be documented
    Architecture is expensive to change
    – it is cheaper to analyze early
    Architecture affects the entire project
    – many stakeholders should be involved
    Requirements can be understood early
    – architecture should be designed to meet them
    ATAM - Vocabulary
    Scenario – A scenario is a short statement describing an
    interaction of one of the stakeholders with the system
    Stakeholder – An individual, team, or organization (or
    classes thereof) with interests in, or concerns relative to,
    a system
    Architectural view – A representation of a whole system
    from the perspective of a related set of concerns
    Functional requirements - specify what software has to
    do.
    Non-functional requirements specify how well it should
    be done.
    What’s ATAM
    Purpose: To assess the consequences of
    architectural decisions in light of quality
    attribute* requirements.
    Primarily a risk identification mechanism
    Not a predictor of quality achievement

    *Quality attribute = “ilities”


    System Quality Attribute
    Performance Time To Market
    Cost and Benefits
    Availability
    End User’s view Projected life time Business
    Usability Community
    Targeted Market
    Security view
    Integration with
    Legacy System
    Maintainability Roll back Schedule
    Portability
    Reusability Developer’s view
    Testability
    ATAM – Cost/Benefit
    Cost
    – 1 – 2 weeks of time for 8 – 10 highly paid people, 2 days for
    another 10-12 people (for full formal process!)
    – Delays project start
    – Forces development of architecture up front

    Benefit
    – Financial – saves money
    – Forces preparation / documentation / understanding
    – Captures rationale
    – Catch architectural errors before built
    – Make sure architecture meets scenarios
    – More general, flexible architecture
    – Reduces risk
    ATAM Steps
    Phase 1 – evaluators and decision makers
    – Present
    ATAM
    Business drivers
    Architecture
    – Identify architectural approaches
    – Generate quality attribute utility tree
    – Analyze architectural approaches

    Phase 2 – add stakeholders


    – Brainstorm and prioritize scenarios
    Repeat the last steps of phase 1
    – Analyze architectural approaches
    In a broader forum…
    – Present results

    Phase 3
    – Analyze cost / benefit of ATAM
    Step 1: Present ATAM
    Evaluation Team presents an overview of the
    ATAM

    • ATAM steps in brief


    • Techniques
    - utility tree generation
    - architecture elicitation and analysis
    - scenario brainstorming/mapping
    • Outputs
    - architectural approaches
    - utility tree
    - scenarios
    - risks and “non-risks”
    - sensitivity points and tradeoffs
    Step 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 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
    Approaches
    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 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- 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 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
    Approaches

    Scenarios
    Vs.
    Architecture
    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.
    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?

    – Modifiability
    Are 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 & Tradeoffs
    Sensitivity – A property of a component that is critical to
    success of system.
    – The number of simultaneous database clients will affect the number of
    transaction a database can process per second. This assignment is a
    sensitivity point for the performance
    – Keeping a backup database affects reliability
    – Power of encryption (Security) sensitive to number of bits of the
    key
    Tradeoff point- A property that affects more than one
    attribute or sensitivity point.
    – In order to achieve the required level of performance in the discrete
    event generation component, assembly language had to be used
    thereby reducing the portability of this component.
    – Keeping the backup database affects performance also so it’s a trade-
    off between reliability and performance
    Steps 6: Risks & Non-Risks
    Risk
    – The decision to keep backup is a risk if the performance cost is
    excessive
    – Rules for writing business logic modules in the second tier of
    your 3-tier style are not clearly articulated. This could result in
    replication of functionality thereby compromising modifiability of
    the third tier.
    Non Risk
    – The decision to keep backup is a non-risk if the performance
    cost is not excessive
    – Assuming message arrival rates of once per second, a
    processing time of less than 30 ms, and the existence of one
    higher priority process, a 1 second soft deadline seems
    reasonable Performance.
    Step 7: Brainstorm & Prioritize
    Scenarios
    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
    Approaches

    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 results
    Architectural approaches
    Utility tree
    Scenarios
    Risks and “non-risks”
    Sensitivity points and tradeoffs

    You might also like