1.0.

Software Architecture Analysis Method

1.1.

Introduction

Software Architecture Analysis Method or just simply, SAAM is methodology used to

evaluate system architectures. It is the first documented software architecture analysis method
and it wasnt until the 1990s that it has being fully developed. It has being widely used in
todays world. It can be used either on analyzing a single architecture or to compare systems
with different architecture but with the same functions. If it is implemented in a single
architecture, it can be used to find the strengths and weakness in an architecture. There are 6
steps to fully implement SAAM into a system. The method is useful in evaluating many of
the attributes of the architecture such as modifiability, flexibility and maintainability.

Steps involved in SAAM (SAT

Lecture Slide)

1.2.

Implementation of SAAM
1.2.1. Step 1 - Develop Scenarios

In this step, the activities of the systems, or also knows as scenarios, are identified. This is
where most of the brain storm is needed to find out the scenarios. There are three key areas
needed to document in this stage. Firstly, the main users of this system are identified, together
with their activities and interaction with the system. The main functions and purpose of the
systems are also identified. Lastly, the changes needed in this system are classified.
The number of scenarios depends on the iterations and architectural information. The more
the iterations and architectural information is, the more scenarios there will be. The two
following tables show the scenarios and stakeholders identified for the TGV ticketing system.

Stakeholder
Customer
Admin
Box Office

Interest
Buy tickets online, view show times.
Change the information of the movies.
Get update of which seats left.

Attendant
Manager

Get statistic reports on the sales.

Scenario
1
2
3
4

Description
Sell advance movie tickets
Update movie information
Ability to port to other operating systems
Display information about movies, show times, cinema and

5
6
7

promotions
E-Ticket Support
Movie Review
Support different type of payment methods

1.2.2. Step 2 - Describe Architecture

This step is used for presenting the architecture of the TGV ticketing system. The architecture
notations must be universal in this step so that all parties involved in the evaluation, both
technical and non-technical users can understand. The architecture must indicate system
computation and data component as well as relevant connectors. The main components and
their objective in the system components are being clarified here. The diagram below shows a
simplified version of the TGV ticketing systems architecture.

The important components in this architecture are input, movie, payment and output.
Input:
-

The user logs into the system to gain access.

The customers are also able to view the movie information and promotions on the

menu page.
They will also be able to view the show times for the system.

Movie
-

The customers can choose the seat, show time and desired cinema to watch the movie.
A total price of the tickets will be displayed on the right side of the screen.
The administrators can update the information of these movies here. For example,
number of seats left for a movie section.

Payment

The user can decide on the type of payment they wanted to proceed with.
A summary of their chosen movie ticket will be displayed.

Output
-

The user can log out of the system.

The summary transaction is printed here on the screen for future reference.

1.2.3. Step 3 - Classify and prioritize scenarios

In this third step, the scenarios are analyzed in this step and grouped into two subgroups of
scenarios, indirect and direct. The direct scenarios are the functions currently supported by
the system because it have met the requirements. The indirect scenarios are activities of the
system that needs to go some or a major change before being accepted into the system. The
importance of each scenarios are being voted in this stage.

Scenario
1
2
3
4

Description
Sell advance movie tickets
Update movie information
Ability to port to other operating systems
Display information about movies, show times,

Indirect/Direct
Direct
Direct
Indirect
Direct

5
6
7

cinema and promotions

E-Ticket Support
Movie Reviews
Support different type of payment methods

Indirect
Indirect
Direct

1.2.4. Step 4 - Individually evaluate indirect scenarios

After the scenarios has being classified into indirect and direct, each of the indirect scenarios
are being listed and evaluated. This step shows the changes needed in architecture.
Stakeholders will have a better understanding with the changes needed. At the end of this
level, a summary table is being documented. Cost and number of days taken for the changes
to occur is compulsory to be included.

Scenari

Description

Direct/Indirect Number of

Changes

Number

components to

Needed

of days

change
All

Change in

(Est.)
4

to other

coding and

months

operating

optimization

o
3

Ability to port

systems
E-Ticket

Indirect

Indirect

Support

.
Add E-

Ticket

months

feature in the
output
6

Movie Reviews

Indirect

component
Add review

into the

months

movie
information
in the Movie
component.

1.2.5. Step 5 - Access Scenario Interaction

In some cases, changes in the same component of the same architecture are required to be
made by two or more scenarios. It is said that these two scenarios have an interact. The
interactions and the components and scenarios they effect are identified in this stage. The
following table identifies a summary of the identified components and interactions of the
TGV ticketing system.

Component

Description of

Interactive

Component
Input

The input is where

Number of
components to

change
1

3, 6

3, 5

3, 5

the customer logs in

to gain access to the
systems booking
Movie

system
This is where the
user chooses the
cinema, movie, seat

Payment

and show time.

This is where the
user chooses the
type of payment they
wanted to pay

Output

through.
Log out happens in
this component.

1.2.6. Step 6 - Create an Overall evaluation

In this step, scenarios are evaluated and assigned a weight respectively. This weight ties back
to business goals, and other fields, such as costs, time to market, risks, etc. Because this
assignment of weights is subjective by all the stakeholders, a universal style of weights needs
to be attached. The motive of the weights, their importance and the quality changes it might
bring to the architecture are being discussed here and are being debated. A summary like the
table below is being developed at the end of this stage.

Scenario

Description of

Number of

Scenario

components to

Ability to port

change
All

to other

Changes Needed

Level of
importance

Change in coding and

optimization

operating
5

systems
E-Ticket

Support
Movie Reviews

Display E-Ticket after

Payment.
Add review into the

movie information in
the Movie component.

1.3.

Conclusion

The System Architecture Analysis Method gives analyzing and evaluation in depth.
Implementing this method helps to produce a better documentation in software architecture.
It also helps to identify the time taken, cost and other necessary factors needed in applying a
certain change in the architecture.

1.4.

Reference

Architectures, S. (2015). SAAM: A Method for Analyzing the Properties of Software

Architectures. [online] Resources.sei.cmu.edu. Available at:
http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=29288 [Accessed 2 Jul. 2015].

Java.dzone.com, (2015). Software Architecture Analysis Method (SAAM) | Javalobby.

[online] Available at: http://java.dzone.com/articles/software-architecture-analysis [Accessed
2 Jul. 2015].