Software Design Methodology

272 Chapter 9. Analysis and Evaluation of Modifiability: The SAAM Method

10.3.6 Overall evaluation

Similar to the example of the KWIC problem, we assigned weights to the scenarios

according to our expectation on how probable the scenario will happen. The metric

for the evaluation of a particular architecture on a given scenario is the number of

components needing modification over the total number of components. The result

of the evaluation is therefore an estimation of the expected cost of modifications on

the architecture.

Table 10.7 Evaluation of KFV architectures

Scenarios Architectures

No. Weight

Shared

data

Abstract

data type

Implicit

invocation

Pipe-and-

filter

1 20 5/7 2/12 0 0

2 5 0 0 0 0

3 15 1/7 1/12 0 1/7

4 5 4/7 3/12 4/14 2/7

5 5 4/7 2/12 2/14 2/7

6 5 4/7 3/12 4/14 2/7

7 10 3/7 4/12 4/14 1/7

8 15 1/7 1/12 1/14 1/7

9 20 7/7 4/12 0 7/7

Overall 51.43 19.15 7.49 30.00

The result of comparison shows that shared data architecture is the most

expensive design to modify, while abstract data type and implicit invocation are the

best with respect to modifiability. Notice that, the overall result of comparison

heavily depends on two factors: the set of scenarios and the weights assigned to

each scenario.

Software Design Methodology 273

SUMMARY

SAAM is a scenario-based software architectural analysis method suitable for

evaluation and analysis of modifiability. There are two types of input to the

analysis: the architectural designs and the quality requirements. The process of

SAAM analysis consists of the following activities:

(1) Development of scenarios. Scenarios describe the interactions between

stakeholders and the system. Quality requirements can be represented in a

more detailed context by a set of scenarios.

(2) Description of candidate architectures. Software architecture to be evaluated

and compared are represented in a form understood by all stakeholders

involved in the analysis.

(3) Classification of scenarios into two types: direct scenarios and indirect

scenarios. Direct scenarios are those that the architecture supports directly

without need of any modification to the system. Indirect scenarios are those

that the architecture does not support and requires modifications to support the

scenario.

(4) Individual evaluation of indirect scenarios. Each indirect scenario is further

analysed to identify the required modifications of the components and the

costs of such modifications.

(5) Assessment of scenario interaction. A component may need modifications in a

number of scenarios. To support all these scenarios, the component needs to

be modified to satisfy all the requirements imposed by these scenarios. Such

situations are complicated and difficult to find a solution. The assessment of

scenario interaction identifies such scenario interactions.

(6) Overall evaluation. Weights are assigned to scenarios according to their

importance and costs of the modifications on the components are estimated so

that numerical comparison between architectural designs can be made with

minimum subjectivity.

In this chapter, we demonstrated how to analyse each individual architectural

design as well as the comparison of a collection of designs by using SAAM. Such

analysis and comparison does not simply tell us whether an architectural design is

good or bad, but also tells us where the problems are and in what scenarios the

problem may occur. This provides detailed information for software designers to

improve their designs so that the problems are solved, or to take other technical

and/or management actions to prevent the problem occurring or to reduce the

consequences when the problem does occur.