Software Architecture Analysis Method (SAAM)

SAAM is a method to determine the degree to which an architecture meets its goals. It is used for:

  • Validation during development / testing
  • A benchmark when acquiring software
  • Comparing architectures

Assessments and Scenarios

A assessment is completed using scenarios. A scenario is a brief description of a single interaction of a stakeholder with a system.

  • A sequence of steps involving the use or modification of the system
  • Not necessarily a run-time interaction

Scenarios test quality attributes, for example:

  • By proposing specific changes to be made to a system - modifiability
  • By proposing specific threat actions - security
  • By proposing usage profiles that tax resources - performance

These quality attributes do not exist in isolation; the context of them is important. For example - a UI is careful designed so that a novice user can use the system with minimal training, but what if experienced users find it tedious?


SAAM Steps

  1. Develop scenarios
  2. Classify scenarios
  3. Perform scenario evaluations
  4. Reveal scenario interaction
  5. Overall evaluation

1. Develop scenarios

We do this by capturing the system's expected qualities, uses and users. Because scenarios represent tasks relevant to different stakeholders, we must:

  • Involve all stakeholders
  • Involve experts

2. Classify scenarios

Scenarios can be divided into two groups:

  • Direct scenarios - can be "walked through" the architecture
  • Indirect scenarios - require modification to the system (ie: extra components & connectors)

3. Perform scenario evaluations

For each scenario list which components and/or connections need to be altered, along with:

  • A weighting of the difficulty of the change(s)
  • Estimated cost of the changes
  • A description of the set of changes required

4. Reveal scenario interaction

When different indirect scenarios require the same component to be changed, these scenarios are said to interact with the component. This exposes the allocation of functionality to components (especially if the scenarios are semantically unrelated).
High interaction between semantically unrelated scenarios indicates:

  • Low cohesion
  • High structural complexity

High interaction between semantically related scenarios indicates high cohesion.

5. Overall evaluation

If we are comparing architectures:…

  • A "importance-weight" should be assigned to each scenario and the scenario interactions. This is a subject process involving all of the stakeholders of the system.
  • The weighting is used to determine an overall ranking of candidate architectures

An application of SAAM

Analyse the shared-memory architecture for the Keyword in Context system

The Keyword In Context System (or KWICS) takes a set of text lines as input. It then produces all circular shifts of these lines and alphabetizes the results.
kwics_01.png

Developing scenarios

KWICS has two stakeholders. The end user and the developer.
Scenarios (all indirect):

  1. Make KWICS operate in an incremental rather than batch fashion (accept one sentence at a time and produce the keyword index for all sentences given to date)
  2. Make KWICS eliminate entries beginning with noise words (articles, pronouns, prepositions and conjunctions)
  3. Change the internal representation of the sentences (ie: compressed or uncompressed)
Scenario 1

This will most likely require modification of:

  • Input: to yield control to MasterControl after each sentence.
  • MasterControl: to loop over subordinate modules for each sentence.
  • Alphabetizer: to use incremental sorting rather than sorting all at once.
Scenario 2

Probably will require modification of:

  • CircularShift : to delete those sentences beginning with 'noise' words.
Scenario 3

Will require modification of:

  • Characters: needs to be changed to handle compressed data

Note: as all modules use Characters all modules (other than MasterControl) may need modifying.


A Revision Control System (WRCS)

WRCS helps with configuration management (keeping track of files as they evolve). It allows users to create archives, compare files, check-in / check-out files and create releases & reports.

wrcs_01.png

Scenarios

  1. Compare binary file representations: the changes should be shown in a human-readable form
  2. Configure the product's toolbar: change icons associated with a button
  3. Change access permissions for a project
  4. Make minor modifications to the user interface: add a menu item or change the look of a dialog box
  5. Port to another operating system
Scenario 1

This is an indirect scenario with the end-user as the stakeholder. It will require modifications to:

  • diff: to make the comparision.
  • visdiff: to display the results of the comparison to the user.
Scenario 2

This is a direct scenario with the end-user as the stakeholder. As it is a direct scenario no changes need to be made to the system to facilitate this behaviour.

Scenario 3

This is a direct scenario with the administrator as the stakeholder. As it is a direct scenario no changes need to be made to the system to facilitate this behaviour.

Scenario 4

This is a indirect scenario with the maintainer as the stakeholder. It will involve modifications to the user interface, so any modules that call the Win31 API will need to be modified (ie: Main, visdiff, ctrls).

Scenario 5

This is an indirect scenario with the maintainer as the stakeholder. This will involve:

  • Modifications to all components that call win31 (Main, visdiff, ctrls)
  • If the target OS does not support OWL, OWL or all components that call OWL (main, hook) will need to be modified
  • If the target OS is not supported by Novell's software, wrcs must be modified to work with new networking software.

Ranking system changes

Module Number of changes
main 4
wrcs 7
diff 1
-
nwcalls 1
hook 4
report 1
visdiff 3
ctrls 2

Now these can be ranked by priority order to arrive at an evaluation of the architecture. Influential modules should be studied to gauge coupling, cohesion and complexity.
If the architecture is modified as a result of analysis it should be ensured that other scenarios are not adversely affected.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License