taken from Software Architecture in Practice, Bass, Clements, Kazman, Addison
Wesley 1998
Chapter 9 : Software Architecture Analysis Method (SAAM)
Techniques for evaluating the architecture
Quality attributes
dont have a meaning in isolation but only within a particular context. Therefore
context based evaluation is very effective and can be done by developing so-called scenarios.
Each scenario is a brief description of a single interaction of a
stakeholder with a system. A very simple example would be this request from an end-user:
"I want to
change background colour on all windows to blue"
The evaluation process revolves around characterising an architecture in terms of how
well it supports those scenarios that represent the stakeholders overriding
concerns. The total number of scenarios must be manageable, so they must be chosen
carefully.
Scenarios have been used by us to arrive at the requirements for the architecture. The
same technique can be used to asses the quality of the design except that in this case the
reviewers are thinking up scenarios to test whether the architecture stands up to specific
needs.
In the following we give outline to the basic steps involved
in using scenarios to analyse architectures. This is followed by some general guidelines for reviewers and some warning signs of problems.
Basic Steps in Use of Scenarios
The basic steps in making a scenario analysis are given in the following. Step 1 should
be prepared before the review. The following steps are performed during the review itself.
Step 1 : Develop set of scenarios
Try to be as complete as
possible in order to test all aspects of the architecture. Scenarios should be chosen in
order to :
- illustrate kind of functions
system must support
- illustrate kinds of changes
you anticipate will be made to system
- capture all important uses
of system
- capture all important users
of system
- users include developers, end-users, maintainers
- capture all important qualities
system must satisfy
- qualities include correctness, flexibility, interoperability, maintainability,
usability, verifiability, expandability, efficiency, manageability,..
- Is each design module correlated
with a scenario?
- Is each major requirement
correlated with a scenario?
Step 2 : Classify scenarios
During review scenarios should be classified according to how the architecture
supports them. There are essentially two possibilities either it does or it doesn't i.e.
suuport is said to be either
- direct - architecture directly supports scenario
- indirect - change to system needed that can be represented architecturally
N.B. degree of modification must be captured when evaluating a systems response
to an indirect scenario.
Step 3 : Perform scenario
evaluations
For each scenario, the changes to the architecture required to support it must be
listed, and the cost of making change estimated. For example does it involve
- addition of a new component
- change in specification of existing component
Finally a summary table should be produced so that for each scenario the impact on the
architecture is described and given an appropriate weight (major/minor or whatever..)
General Guidelines
- Understand essential functions of system and see if each function is unambiguously
defined in architecture design documents. "How is X
done?" should ellicit a clear answer.
- Make sure that there are written requirements in all key areas.
- Check that system acceptance criteria exist.
- Specific information must be analysed when checking specific quality requirements e.g.
To evaluate modifiability best done with questioning
techniques to reveal how vulnerable architecture is to specific modifications.
To evaluate performance related and other goals might need to
know:
- workload information
number
of concurrent users, request rates etc.
- execution paths, expectation of execution of each component, repetitions,...
- environmental information
This can then be used to evaluate resource utilisation i.e. cpu utilisation, i/o activity,
database accesses, memory usage
Warning signs
of problems
The following are considered to be early warning signals of problems with an architecture:
- architecture forced to match
current organisation
- top level components number more
than 25
- one requirement drives rest of
design
- architecture depends on
alternatives in OS
- proprietary components are being
used where standard components would do
- component definition comes from
hardware builder
- redundancy not needed for
relaibility (e.g. 2 databases, 2 error handling components)
- design is exception driven i.e.
emphasis on extensibility and not core commonalities
- no architect for the system
|