lhcblogo.gif (8544 bytes)

Architecture Review
Guidelines for Reviewers


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 don’t 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 system’s 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