Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman http://salmosa.kaist.ac.kr/~cbse/pptfiles/survey_on_SAAM.ppt http://www.iese.fhg.de/lectures/knauber/WS2000/Slides2411_ATAM.PDF - PowerPoint PPT Presentation

Loading...

PPT – Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman http://salmosa.kaist.ac.kr/~cbse/pptfiles/survey_on_SAAM.ppt http://www.iese.fhg.de/lectures/knauber/WS2000/Slides2411_ATAM.PDF PowerPoint presentation | free to download - id: 5cd68e-ZTI0N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman http://salmosa.kaist.ac.kr/~cbse/pptfiles/survey_on_SAAM.ppt http://www.iese.fhg.de/lectures/knauber/WS2000/Slides2411_ATAM.PDF

Description:

Title: A Survey on Software Architecture Analysis Methods Last modified by: KENDRA COOPER Document presentation format: On-screen Show Company – PowerPoint PPT presentation

Number of Views:45
Avg rating:3.0/5.0

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Architecture Tradeoff Analysis Method Based on presentations by Kim and Kazman http://salmosa.kaist.ac.kr/~cbse/pptfiles/survey_on_SAAM.ppt http://www.iese.fhg.de/lectures/knauber/WS2000/Slides2411_ATAM.PDF


1
Architecture Tradeoff Analysis Method Based on
presentations by Kim and Kazman
http//salmosa.kaist.ac.kr/cbse/pptfiles/survey
_on_SAAM.ppthttp//www.iese.fhg.de/lectures/knau
ber/WS2000/Slides2411_ATAM.PDF
2
Introduction
  • S/W Quality
  • 1972, Parnas modularization, information hiding
    as a means of high-level system decomposition to
    improve flexibility and comprehensibility
  • 1974, Stevens et al. notion of coupling
    cohesion to evaluate alternatives for program
    decomposition
  • Recent years specification, architecture, and
    design with respect to S/W qualities
  • Why Early Phases?
  • Identify potential risks, Verify the quality
    before building
  • All design involves tradeoffs
  • A software architecture is the earliest
    life-cycle artifact that embodies significant
    design decisions choices and tradeoffs.

3
Definitions
  • Quality
  • Nonfunctional characteristics
  • Desired combination of attributes
  • Maintainability
  • corrections, improvements, adaptation
  • Modifiability
  • change quickly and cost effectively
  • (Extensibility, portability, restructuring)
  • Flexibility
  • ease of modification for case NOT designed
  • paper by Keller 1990 is a very good starting
    place for quality attributes

4
Overview of Architecture Trade-off Analysis
Method (ATAM)
  • Proposed by Kazman as a technique for
    understanding the tradeoffs points or
    dependencies among the attributes, inherent to
  • architecture evaluation.
  • The purpose of the ATAM is to assess the
    consequences of
  • architectural decision alternatives in light
    of quality
  • attribute requirements Kazman.
  • Provides a way to evaluate software
    architectures fitness with
  • respect to multiple competing quality
    attributes.
  • Since these attributes interact, the method helps
    to reason about
  • architectural decisions that affect quality
    attribute interactions.
  • Follows a spiral model of design, postulating
    candidate architectures followed by analysis and
    risk mitigation, leading to refined
  • architectures.

5
Overview of Architecture Trade-off Analysis
Method (ATAM)
  • We need a method in which the right questions are
    asked early to
  • Discover risks -- alternatives that might create
    future problems in some quality attribute
  • Discover sensitivity points -- alternatives for
    which a slight
  • change makes a significant difference in some
    quality attribute
  • Discover tradeoffs -- decisions affecting more
    than one quality attribute

6
Overview of Architecture Trade-off Analysis
Method (ATAM)
  • The purpose of an ATAM is NOT to provide precise
    analyses . . . the purpose IS to discover risks
    created by architectural
  • decisions.
  • We want to find trends correlation between
    architectural decisions and predictions
    of system properties.
  • Discovered risks can then be made the focus of
    mitigation activities e.g. further
    design, further analysis, prototyping.

7
Overview of Architecture Trade-off Analysis
Method (ATAM)
  • Benefits from performing ATAM analyses
  • Clarified quality attribute requirements
  • Improved architecture documentation
  • Documented basis for architectural decisions
  • Identified risks early in the life-cycle
  • Increased communication among stakeholders
  • The most important benefit is improved
    architectures.

8
Overview of ATAM
  • Identify, prioritize and refine the most
    important quality attribute goals by
    building a utility tree
  • a utility tree is a model of the driving
    attribute-specific requirements
  • typically performance, modifiability, security,
    and availability are the high-level nodes
  • intermediate nodes have specific quality goals
  • scenarios are the leaves of the utility tree
  • Output a prioritization of specific quality
    attribute requirements

9
Overview of ATAM
  • ATAM Phases

10
Overview of ATAM
  • Evaluate trade-off among multiple S/W quality
    attributes
  • Scenario based

11
Overview of ATAM
12
Overview of ATAM
13
ATAM
  • Motivated by the high priority leaves of the
    utility tree, the Evaluation Team probes the
    architecture
  • approaches
  • Identify the approaches which 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

14
ATAM
  • Quality attribute questions probe
    approaches/styles to elicit architectural
    decisions which bear on quality attribute
    requirements.
  • Performance
  • How are priorities assigned to processes?
  • What are the message arrival rates?
  • Modifiability
  • Are there any places where layers/facades are
  • circumvented?
  • What components rely on detailed knowledge
  • of message formats?

15
ATAM Example
  • A distributed battlefield management system
  • (BMS)
  • One mobile central commander node
  • A set of mobile fighter nodes under
    commander
  • Information from many sources/sensors
  • Messages of different types (maps, orders)
  • Stakeholders wanted to understand how the
  • system would perform and adapt to changes.

16
ATAM Example
17
ATAM Example
Scenarios identify need for Backup nodes
18
ATAM Example
  • For availability, a backup commander scheme was
    described
  • Need a backup for the backup (otherwise two hits
    or failures
  • would disable the system)
  • For performance, an client-server style was
    described
  • Through analysis
  • Increasing the number of backups increases
    availability, but also increases average latency
    (because these backups must be kept
    up-to-date by the commander).
  • Hence, the number of active and passive backups
    is a tradeoff point in the BMS
    architecture.
  • The designers had not been aware of the tradeoff
    inherent in their design.

19
ATAM Summary
  • The ATAM is a method for evaluating an
    architecture
  • with respect to multiple quality attributes.
  • effective strategy for discovering the
    consequences of architectural
    decisions.
  • The ATAM
  • can be done early can be done on legacy systems
  • is inexpensive
  • builds stakeholder confidence and buy-in
  • The key to the method is looking for trends, not
    in
  • making precise analyses.

20
ATAM Summary
  • The ATAM relies critically on
  • Appropriate preparation by the customer
  • Clearly-articulated quality attribute
    requirements
  • Active stakeholder participation
  • Active participation by the architect
  • Familiarity with architectural approaches, styles
    and analytic models

21
References
  • Kazman R., Klein M., Barbacci M., Longstaff T.,
    Lipson H.,Carriere J.,The Architecture Tradeoff
    Analysis Method,CMU/SEI-98-TR-008,
    ESC-TR-98-008, July 1998.
  • Keller, S. E., Kahn, L. G. and Panara, R. B.
    (1990). "Specifying Software Quality
    Requirements with Metrics", in Thayer, R. H. and
    Dorfman, M. (eds.), System and Software
    Requirements Engineering, IEEE Computer
    Society Press Tutorial, pp. 145-163.
About PowerShow.com