Understanding Software Architecture Analysis Method (SAAM)

undefined
 
SAAM
 
SOFTWARE ARCHITECTURE ANALYSIS METHOD
 
http://slashnode.wikidot.com/seng4420-lect07
 
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
 
A
s
s
e
s
s
m
e
n
t
s
 
a
n
d
 
S
c
e
n
a
r
i
o
s
 
 
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
 
Steps
 
 
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)
 
Steps - continued
 
 
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.
 
Finally …
 
 
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
 
A
n
 
a
p
p
l
i
c
a
t
i
o
n
 
o
f
 
S
A
A
M
A
n
a
l
y
s
e
 
t
h
e
 
s
h
a
r
e
d
-
m
e
m
o
r
y
 
a
r
c
h
i
t
e
c
t
u
r
e
 
f
o
r
 
t
h
e
K
e
y
w
o
r
d
 
i
n
 
C
o
n
t
e
x
t
 
s
y
s
t
e
m
 
 
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.
 
D
e
v
e
l
o
p
i
n
g
 
s
c
e
n
a
r
i
o
s
 
 
KWICS has two stakeholders. The 
end user
 and the 
developer
.
Scenarios (all indirect):
 
Scenario: 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)
 
Scenario: Make KWICS eliminate entries beginning with 
noise words
 (articles, pronouns,
prepositions and conjunctions)
 
Scenario: Change the 
internal representation
 of the sentences (ie: compressed or
uncompressed)
3 Examples
 
 
Scenario 1: 
incremental rather than batch
 
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.
 
3 Examples
 
 
Scenario 2: 
eliminate entries beginning with 
noise words
 
Probably will require modification of:
 
CircularShift
 : to delete those sentences beginning with 'noise' words.
3 Examples
 
 
Scenario 3: 
: Change the 
internal representation
 of the sentences (ie: compressed or
uncompressed)
 
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.
Slide Note
Embed
Share

Software Architecture Analysis Method (SAAM) is a method used to assess how well an architecture meets its goals. It involves developing scenarios, classifying scenarios, performing evaluations, revealing scenario interactions, and overall evaluation. Scenarios help test quality attributes like modifiability, security, and performance. SAAM assists in validation during development, serves as a benchmark for software acquisition, and aids in comparing architectures.


Uploaded on Jul 22, 2024 | 1 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. SAAM SOFTWARE ARCHITECTURE ANALYSIS METHOD http://slashnode.wikidot.com/seng4420-lect07

  2. 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

  3. Assessments and Scenarios 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?

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

  5. Steps 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)

  6. Steps - continued 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.

  7. Finally 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

  8. An application of SAAM Analyse Analyse the shared the shared- -memory architecture for the memory architecture for the Keyword in Context system 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.

  9. Developing scenarios Developing scenarios KWICS has two stakeholders. The end user and the developer. Scenarios (all indirect): Scenario: 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) Scenario: Make KWICS eliminate entries beginning with noise words (articles, pronouns, prepositions and conjunctions) Scenario: Change the internal representation of the sentences (ie: compressed or uncompressed)

  10. 3 Examples Scenario 1: incremental rather than batch 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.

  11. 3 Examples Scenario 2: eliminate entries beginning with noise words Probably will require modification of: CircularShift : to delete those sentences beginning with 'noise' words.

  12. 3 Examples Scenario 3: : Change the internal representation of the sentences (ie: compressed or uncompressed) 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.

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#