Architecture Evaluation
From Suhrid.net Wiki
Jump to navigationJump to searchIntro
- 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:
- 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
- Architectural Tradeoff Analysis Method.
- ATAM is a refinement of SAAM.
- ATAM reveals how well an architecture satisfies particular quality goals.
- Recognises that an arch decision tends to affect more than one quality attribute and provides insight into how quality goals trade-off against each other.