3.

Software Architecture Analysis Method (SAAM)

3.1 Introduction
Software Architecture Analysis Method (SAAM) is a methodology that is used to
determine the attainment of specific system quality attributes and the effect of
potential modifications on the quality attributes through theoretical cases studies.
People typically make for their architecture. Elaborate a software architecture
evaluation strategy using SAAM on your chosen system. Clearly identify and assess
the steps involved. Furthermore, SAAM also an evaluation method that primary using
scenario based architecture analysis to specifies qualities with context and evaluate
simple architecture to compare different analysis design help to development of user
interface with interactive system and its functionalities (Klein, 2001).
As follow, we are going to use SAAM method to analysis Fast food Online Order
System.
3.2 Input to SAAM Evaluation
To begin with the SAAM evaluation, some few inputs are required so that the
evaluation of the system architecture can be achieved. The inputs that are required
include a description of system architectural design, the quality attributes that the
system needs to achieve, and a list of scenarios.
3.3 Output of SAAM Evaluation
Through the SAAM evaluation, every stakeholders can clearly understand the
functionality of the system and the scenario which is a representation of potential
changes in the future through the system architecture. Which will clearly evaluate the
effect of each potential changes in terms of effort, time and cost. Therefore,
stakeholders will be able to easily comprehend the overall system architecture with its
current functionalities and further enhancements.

3.4 Steps of SAAM Evaluation

The main steps of Software Architecture Analysis Method (SAAM) can be depicted
into 6 activities to evaluating an architecture, which include:
1.
2.
3.
4.
5.
6.

Develop Scenarios
Describe Architecture
Classify/Prioritize Scenarios
Individually Evaluate Indirect Scenarios
Assess Scenario Interaction
Create Overall Evaluation

In the SAAM evaluation process, step 1 interacts with step 2 iteratively to map the
scenarios given to the correct architecture in the system. After that, step 3 indicates
that the scenarios are classified and prioritized into direct and indirect scenarios, then
step 4 will evaluate the indirect scenarios individually. After assessing the scenario
interaction with component in step 5, the SAAM evaluation ends with creating an
overall evaluation as step 6.
3.4.1 Step 1: Develop Scenarios
The first step of using SAAM evaluation method is to develop a set of scenarios that
represent all activities that the system must provide and record the changes which
stakeholders anticipated will be supported to the system to evaluation the future
development of the system (Maurya, 2016) the development of scenarios will indicate
all of the major system functionalities and anticipated changes to the system through
the achievement of quality attributes. During this step, the identification of the
stakeholders is finalized and each stakeholder will have at least one scenario

developed which represents a task relevant to them. For Fast food Online Order
System, the 4 stakeholders are manager, consumer, maintainer and marketing. In the
development of scenarios, each stakeholder will have their functionalities constructed
based on the quality attributes to be achieved. Among the quality attributes of a
system, there are 4 types of quality attributes which the system requires to achieve,
which includes modifiability, robustness, portability and extensibility.
Stakeholders
Manager

Interest
Stakeholder who update package information and prices, as

Consumer
Maintainer

well as handling consumer orders.

Stakeholder who use the system to select the packages.
Stakeholder who update and maintain security and usability of

Marketing

the system
Stakeholder who design an promotion and advertisement
strategy on user interface of the system

Scenario No. Scenario Description

Modifiability
1
System should be able to accommodate updates of menu.
2
System should be able to support addition of new languages.
3
System should be able to include food tracking system.
Robustness
4
System should prompt user to try again if internet connection is bad.
5
System should be able to notify user when the server is down.
6
System should be able to provide notification for wrong data input.
Portability
7
System should be able to support different web browsers.
8
System should be able to run on different operating systems.
9
System should have different sizing of user interface on different
devices.
10
11

Extensibility
System should be able to notify user when the delivery has reached.
System should be able to provide promotional coupon code for

12

users.
System should be able to accumulate points for users.

3.4.2 Step2Describe the Architecture

Architecture is the product of planning, designing and constructing physical structures
and it shows the relationship of each structural element. By illustrate a static
representation of architecture to represent the description of the data connections for

architecture which components send/response what information and connections

which explicitly show what dependencies from one component is used by the other
components.

The above diagram is a Fast food Online Order System. Data source of the ordinary
operation of the system users, registered users and manager are three first according to
the different needs of users by the system administrator to save certain information to
the database, and then publish. Different users can read information on these libraries,
and other search and ordering process. All users can query information. Through
analysis of the demand for this system, the basic functions of the system have been
identified. The console and mobile can use the system to browse the menu, which will
allow users to choose foods, beverages and desserts to add into the cart. When the
user checks out the cart, the system will prompt the user to save the order list as
favourites. The system will prompt the user to choose payment by cash or credit. The
system will generate an order tracking interface for the user to track order status.

3.4.3 step 3Classify and Prioritize Scenarios

Scenario No.

Scenario

Direct/

System should be able to accommodate updates of

Indirect
Direct

menu.
System should be able to include food tracking

Direct

system.
System should be able to provide notification for

Direct

wrong data input.

System should be able to support different web

Direct

browsers.
System should be able to run on different operating

Direct

systems.
System should have different sizing of user

Direct

interface on different devices.

In this step, SAAM method had categorise those scenarios into two types of scenarios
which are direct scenarios and indirect scenarios (Maurya, 2016). Aanalysis of the
scenarios given that needs to be achieved for quality attributes, the scenarios are
divided into two categories, which are direct scenario and indirect scenario. Direct
scenario is the scenario which is currently supported by the system, whereas indirect
scenario is the scenario which is currently not supported by the system, so the indirect
scenario can only be achieved through making modifications to the system.
The scenarios are classified into two categories:

Scenario No.
2

Scenario
System should be able to support addition of

Direct/ Indirect
Indirect

new languages.
System should be able to notify user when the

Indirect

server is down.

System should prompt user to try again if

Indirect

10

internet connection is bad.

System should be able to notify user when the

Indirect

11

delivery has reached.

System should be able to provide promotional

Indirect

12

coupon code for users.

System should be able to accumulate points for

Indirect

users.

3.4.4 Step 4: Individually Evaluate Indirect Scenarios

In this step, the indirect scenario is mapped into the architectural description. After
complete classify direct and indirect scenarios, each indirect scenario should illustrate
to represent which components affected by changes. For each of the indirect scenario
listed is step 3, the cost of change is required to be estimated in terms of money and
time.
The table below shows the SAAM Scenario Evaluation for each indirect scenario:

Scenario

Scenario

Direct/

Required

Number of

Effort for

Number

Description

Indirect

Changes

Changed

Changes

System

Indirect Add

should be able

language

to

support

addition

of

new
5

languages.
System
should be able

(estimate)
RM600/ 1

different
into

week

(1

the system such

week

per

as

language)

Mandarin

and Tamil
Indirect Display server
down message

RM200/ 1
1

week

to notify user

to users who try

when

the

to access the

server

is

down.
System

Indirect Display

should

11

try

again message

prompt

10

system

user

when the user

to try again if

cannot connect

internet

to the system

connection is

database

bad.
System

RM400/ 1
1

Indirect Alert the user

should be able

with

to notify user

ringtone

when

the

through

delivery

has

system

reached.
System

delivery

RM600/ 1
1

RM800/ 1

should be able

promotional

to

coupon code as
button

week

the

Indirect Display

provide

week

week

promotional

coupon code

users to select

for

for users
12

System

Indirect Add

point

should be able

system to the

to accumulate

user account for

points

point

users.

for

RM900/ 1
week
1

accumulation to
redeem items

3.4.5 Step 5: Assess Scenario Interactions

When two or more scenarios require changes to a single component, it is said that
interaction exists between them. In that case, the component that is affected needs to
be adjusted or further separated into sub-component so that the interaction between

different scenarios can be avoided. In the table from step 4, it shows that there are
some indirect scenarios that are requesting the changes for a same component, so the
assessment of scenario interaction is a vital step in dividing the components so that
the overall system architecture can have independent scenario that do not have any
interaction with each other
First, the addition of new language to the system will interact with the
accommodation of menu updates. The addition of new language will require the
component to further divide into the system locale, which will generally translate the
system into an entirely new language in Unicode. Furthermore, the accommodation of
menu updates will divide the component into the system database, where the database
will keep the record of every single menu items. Therefore, the two scenarios will not
interact with each other through the shared component.
Secondly, the system down and bad internet connection have a similar component.
The system down can be part of the maintenance, so the component can be further
divided into the system maintenance subcomponent, whereas bad internet connection
is a network connection problem, which do not relates to the system operability,
unless the system experienced a server failure, so this component will be divided into
the system failure subcomponent.
Lastly, the food tracking system coincides with the component of ringtone notification
when delivery reached. For the food tracking system and ringtone notification, the
system delivery service component can be further divided into the system tracking
and system notification, whereby the system tracking only functions to display the
status of the delivery at the moment, and system notification serves as an assistant for
informing the user that the delivery has arrived.
3.4.6 Step 6: Create Overall Evaluation
In the final step of the SAAM method is weight between scenarios by prioritize the
importance when conducting analysis of scenarios to achieve a complete system
architecture. The weightage is an indication of the scenarios relative importance
throughout the entire system architecture, whereby the weightage will be higher for
the most essential quality attributes that is needed to achieve in the system. For Fast
food Online Order System, the overall evaluation is made in accordance to involving
stakeholders, as follow like this:

Scenario
1
2

Scenario Description
System should be able to accommodate updates of menu.
System should be able to support addition of new

Weightage
High
Moderate

3
4

languages.
System should be able to include food tracking system.
System should prompt user to try again if internet

High
Moderate

connection is bad.
System should be able to notify user when the server is

Very High

down.
System should be able to provide notification for wrong

High

data input.
System should be able to support different web

Low

browsers.
System should be able to run on different operating

Moderate

systems.
System should have different sizing of user interface on

High

10

different devices.
System should be able to notify user when the delivery

High

11

has reached.
System should be able to provide promotional coupon

Moderate

12

code for users.

System should be able to accumulate points for users.

High

3.5 Conclusion
After analysis Fast food Online Order System. Throughout the SAAM evaluation, the
scenario generation and analysis process is essential to the stakeholders as this can be
used to identify indirect scenarios among all the scenarios that the system requires to
achieve quality attributes. It able to provide a better understanding of perspectives of
whole architecture to estimate the cost and effort about the system to all stakeholders
and improve software architecture documentation.