Software Architecture And

Testing
CT059-3-2

Using the Software

Architecture Analysis
Method (SAAM)
 Topic & Structure of the lesson

• Overview of the SAAM

• Steps of a SAAM evaluation
• A sample SAAM agenda

Module Code & Module Title Slide Title SLIDE 2

Slide 2Slide
(out of222)
 Learning Outcomes

• By the end of this lecture, YOU should be able to :

– Apply SAAM for evaluating an architecture
– Understand the steps in SAAM

Module Code & Module Title Slide Title SLIDE 3

Slide 3Slide
(out of322)
 Key Terms you must be able to use

• If you have mastered this topic, you should be able to use the following
terms correctly in your assignments and exams:
– Software Architecture Analysis Method (SAAM)
– Scenario
– Evaluation
– Direct
– Indirect

Module Code & Module Title Slide Title SLIDE 4

Slide 4Slide
(out of422)
 Software Architecture Analysis
Method (SAAM)
• First promulgated architecture analysis methods
• Uses quality attributes with the usage of scenarios
• Can also be used for heuristic evaluation of other system qualities
• Good start for first time users

Module Code & Module Title Slide Title SLIDE 5

Slide 5Slide
(out of522)
 SAAM’S TASK

• So creators of the SAAM set out to operationalize the testing of such

claims by replacing claims of quality attributes (word like maintainability,
modifiability, robustness….and so forth)
• SAAM originally created to analyze an architecture for modifiability
which is changing a body of software
• The SAAM has proven useful for quickly assessing many quality attributes
such as modifiability, portability, extensibility…)as well as
functional coverage.
• However, ATAM far supersedes evaluation of other qualities such as
performance or reliability.

Module Code & Module Title Slide Title SLIDE 6

Slide 6Slide
(out of622)
 SAAM IN GENERAL

• A simple method
• Easy to learn
• Easy to carry out with little training and preparation
• Good to start if one has no experience in architecture evaluation
• Respect to modifiability and functionality more

Module Code & Module Title Slide Title SLIDE 7

Slide 7
 Overview SAAM

• SAAM starts with requesting stakeholders to list known scenarios that

are likely to change
• Scenarios will analyzed, prioritized and mapped onto the representation
of the architecture and analyze where:-
– the problem area where architecture overly complex
– key design details are not encapsulated but rather are
distributed throughout the architecture
– Also indicate areas where architectural documentation is not
correctly presented and forces the architect to detail the
documentation
• Has social benefit, it facilitates people to come to gather and allows group
work
• Requires many inputs and produces number of outputs

Module Code & Module Title Slide Title SLIDE 8

Slide 8
 Inputs to a SAAM Evaluation

• To start with SAAM inputs are:-

- Description of the architecture
- A good representation of the architecture
- It is essential to enumerate a number of scenarios(a short statement
describing an interactions of one of the stakeholders with the system)

Module Code & Module Title Slide Title SLIDE 9

Slide 9
 Output of SAAM Evaluation

• Benefits
- Comparing with competing architecture
- To gain more in-depth understanding of an architecture
- Better documented software architecture

• The main benefits

- A mapping onto the architecture of scenarios that represent possible
future changes
- An understanding of the functionality of the system
- A comparison of multiple architectures with the respect to the amount of the
functionality that each supports without modification

Module Code & Module Title Slide Title SLIDE 10

Slide 10
 Steps of a SAAM Evaluation

• Activities and Dependencies in a SAAM Analysis

Module Code & Module Title Slide Title SLIDE 11

Slide 11
 Example –website

Module Code & Module Title Slide Title SLIDE 12

Slide 12
 Steps 1 – Develop Scenario

• Illustrate the kinds of activities(uses) that the system

must support(represent task relevant to different stakeholders)
• Illustrate the kind of changes that the client anticipates (in the foreseeable
future)
• Capture all major uses of a system
• Users of a system
• Anticipated changes to the system
• Qualities that the system must satisfy

• “must represent tasks relevant to all stakeholder”

Module Code & Module Title Slide Title SLIDE 13

Slide 13
 Step 2 – Describe the Architecture

• Should use the architectural notation that understand by all parties

involved in the analysis stage.
• Must indicate the system computation and data components as well as
all relevant connections.
• Accompany the static representation of the architecture is a description
of how the system behaves overtime and more dynamic description-
express in natural language description of a overall behavior or more
formal specifications.
• Development of scenarios and architectural description drive each other
and are done in an interleave manner, iteratively

Module Code & Module Title Slide Title SLIDE 14

Slide 14
 Step 3 – Classify and Prioritize the
Scenarios
• Recap- scenario is brief description of anticipated or desired use
of the system
• Use direct scenario- where the architecture may directly support that
scenario and no modification required
• If a scenario does not directly supported, some changes to the architecture
is required(How one or more components perform an activity, the addition
of a relation between existing components, the removal of component or
relation, a change to an interface or a combination of these) is classified
as indirect scenario and are the measurement of the degree of
modifiability, ie evolutionary changes in the lifetime of the system.
• Prioritization of scenarios addresses most important scenarios and should
use limited time to evaluate, which focuses on quality attributes. (Voted
by stakeholders)
• Define entire stakeholder and their concerns
Module Code & Module Title Slide Title SLIDE 15
Slide 15
 Step 4 – Individually evaluate Indirect
Scenarios
• Once the scenario is selected, map to the architectural description, direct
scenarios will map onto the architecture
• Indirect scenarios, the architect describes what would need to
be changed to accommodate the scenario
• This will allow the stakeholders to have in-depth understanding.
• Mapping illustrates weaknesses in architecture and its documentation.
• For each indirect scenario the changes to the architecture must be listed
and the costs of performing the change must be estimated
• End of this task a summary table should be produced that lists
all scenarios (direct and indirect) and for each indirect scenario, the set of
changes required should be described and recorded by the
scribe (including estimation of needed effort for changing debugging
and testing time).
Module Code & Module Title Slide Title SLIDE 16
Slide 16
 Example of SAAM Scenario
Evaluation

Module Code & Module Title Slide Title SLIDE 17

Slide 17
 Step 5 – Assess Scenario
Interactions
• Two or more indirect scenarios require changes to a single component, it
said to have interaction and is important to highlight.

Module Code & Module Title Slide Title SLIDE 18

Slide 18
 Step 5 – Assess Scenario
Interactions
• It is important to highlight for reasons below:-
1. It will exposes the allocation of functionality to the product’s design.
• The interaction of unrelated functionality to the product design from the
meaning aspect shows which components are computing unrelated
functions.
• Areas of high scenario interaction reveal potentially poor separation of
concerns in the component.
• It leads to structural complexity (coupling and cohesion). It is highly
correlated with number of defects in the final product.

Module Code & Module Title Slide Title SLIDE 19

Slide 19
 Step 5 – Assess Scenario
Interactions
• It is important to highlight for reasons below:-
• 2. It reveal that the architecture is not documented to the right level of
structural decomposition.
– When scenarios interact within a component but that component
can actually be decomposed into smaller sub-components that do not
exhibit the scenario interaction. In this case Step 2 “describing
the architecture” with need to be revisited.

Module Code & Module Title Slide Title SLIDE 20

Slide 20
 Step 6 – Create the Overall
Evaluation

• For example scenarios might be weighted by their anticipated cost, risk,

time to market or other criteria.
• If you have multiple architecture, the number of direct scenarios
supported by each one affects the evaluation.
• A tabular summary is useful for showing comparison.

Module Code & Module Title Slide Title SLIDE 21

Slide 21
 Comparing Scenario – Architecture compliance

Scenario Atchitecture-1 Arc-2 Arc-3

(Scenario descript Supported 70% 60% 40%
ion) 1
….2
…. 3

Total 300% 500% 400%

Conclusion – Arc-2 seems to support more of the scenarios​

Module Code & Module Title Slide Title SLIDE 22

Slide 22
 Summary of Main Teaching
Points
• Overview of the SAAM
• Steps of a SAAM evaluation
• A sample SAAM agenda

Module Code & Module Title Slide Title SLIDE 23

Slide 23
 Question and Answer Session

Q&A

Module Code & Module Title Slide Title SLIDE 24

Slide 24Slide
(out of24
25)
 Tutorial

• Use the web Architecture to produce 3 new scenarios and fill-up the
below table
Scenario Quality Direct / Indirect Stakeholder Suggested
Description Attributes(s) Improvement to
complied architecture
1

Module Code & Module Title Slide Title SLIDE 25

Slide 25
 What To Expect Next Week

In Class Preparation for Class

• Active Reviews for Intermediate • Download the slide and study

Design (ARID) – An evaluation for the next chapter.
method for partial architecture

Module Code & Module Title Slide Title SLIDE 26

Slide 26