Difference between revisions of "Architecture Evaluation"

From Suhrid.net Wiki
Jump to navigationJump to search
(Created page with "= Intro = * Design decisions, patterns are used because of the effects they have on the system. * Hence, these choices are analysable. * Design must be evaluated continuously du...")
 
Line 14: Line 14:
 
* Propose scenarios against a quality attribute.
 
* Propose scenarios against a quality attribute.
 
* For e.g. against performance - give usage profiles that stretch the system.
 
* For e.g. against performance - give usage profiles that stretch the system.
 +
 +
= SAAM =
 +
 +
* Software Architecture Analysis Method.
 +
* Steps:
 +
# Develop scenarios
 +
# Describe candidate architecture
 +
# Classify scenarios - direct (arch directly support) or indirect.
 +
# Perform scenario evaluations - For each indirect scenario, changes to the architecture that are necessary for it to support the scenario.
 +
# Reveal scenario interaction - When 2 or more indirect scenarios require change to a single component - they are said to interact in that component. Areas of high scenario interaction
 +
can indicate poor separation of concerns in a system component.
 +
# Overall evaluation : Tabulation, weighting of scenarios, rating architecture support. To compare candidate architectures.
  
 
= ATAM =
 
= ATAM =

Revision as of 04:45, 8 April 2012

Intro

  • Design decisions, patterns are used because of the effects they have on the system.
  • Hence, these choices are analysable.
  • Design must be evaluated continuously during the life cycle, especially early on.
  • There are many benefits to evaluation:
    • Financial.
    • Early detection of problems.
    • Captured rationale - Documented design rationale is important so that implications of modifications can be assessed.
    • Validation of requirements - opens up the requirements themselves for discussion. e.g. conflicting requirements.
    • Improved architectures.
  • Use scenarios as vehicles for asking probing questions about how the arch. responds to various situations.
  • Propose scenarios against a quality attribute.
  • For e.g. against performance - give usage profiles that stretch the system.

SAAM

  • Software Architecture Analysis Method.
  • Steps:
  1. Develop scenarios
  2. Describe candidate architecture
  3. Classify scenarios - direct (arch directly support) or indirect.
  4. Perform scenario evaluations - For each indirect scenario, changes to the architecture that are necessary for it to support the scenario.
  5. Reveal scenario interaction - When 2 or more indirect scenarios require change to a single component - they are said to interact in that component. Areas of high scenario interaction

can indicate poor separation of concerns in a system component.

  1. Overall evaluation : Tabulation, weighting of scenarios, rating architecture support. To compare candidate architectures.

ATAM