System Architecture and Testing

Contents
1.0 File Sharing and Synchronizing System....................................................................................3
1.1 Introduction............................................................................................................................3
1.2 Reason for Chosen System....................................................................................................4
1.3 Evaluation Criteria.................................................................................................................5
2.0 Stakeholder Consensus Realization Analysis Method (SCRAM).............................................7
Presentation..................................................................................................................................7
Investigation and Analysis...........................................................................................................9
Testing........................................................................................................................................14
Reporting...................................................................................................................................15
Software Architecture Analysis Method (SAAM).........................................................................16
Overview of SAAM...................................................................................................................16
Input of SAAM Evaluation........................................................................................................17
Output of SAAM Evaluation.....................................................................................................18
Step of SAAM Evaluation.........................................................................................................19
Step 1 Develop Scenarios.......................................................................................................20
Step 2 Describe Candidate Architecture.................................................................................21
Step 3 Classify and Prioritize Scenarios.................................................................................22
Step 4 Individually Evaluate Indirect Scenarios.....................................................................23
Step 5 Assess Scenario Interaction.........................................................................................24
Step 6 Create the Overall Evaluation......................................................................................24
References......................................................................................................................................26

System Architecture and Testing

System Architecture and Testing

1.0 File Sharing and Synchronizing System

1.1 Introduction
The system that has been chosen is the file sharing and synchronizing system. File
sharing and synchronizing system is an online storage based system that allow the user store
their data and information just like using the hard disk to store data. The difference between file
sharing and synchronizing system and other standard storage is the store and retrieve method.
The stored data by using fie sharing and synchronizing system usually will store to the online
storage such as Dropbox and Google Drive. This kind of system will auto synchronizing the files
that contain in the folder which link to the system and the files able to download from any
location with users devices. It supported many type of platform like Windows based system and
Linux based system. Additional, this system also support many type of files such as audio, video,
image, document and more. This system is implemented for two types of users with different
functionality and different volume of the storage.
There are few function of file sharing and synchronizing system that for the users. This
system usually will have the generate link function for the users to share their file to others.
Other than that, the purpose of using this system not only for storing but also for making a
backup for file that own by the users.
The volume of the storage of file sharing and synchronizing system for both personal
users and business users is also different. Usually the system provided less than 50 gigabyte
volume for the free users or personal users but for the business users that will be larger than
personal users. The volume for the business users is depending on the price and the organization
needed.

System Architecture and Testing

1.2 Reason for Chosen System
Based on the introduction, the system have many benefits for the users but also some
weakness when using the file sharing and synchronizing system. There are some security issues
appear in this system and that cause so of the users data have been stole. The generated link can
be share to others by other users without the owner knowing, so that the original data inside the
system can be download by others.
Furthermore, the data that store by using this system can also be overwrite when the users
upload something to the storage or put inside the folder of the system. It will be the weakness of
the system also because of the overwriting function. If a user using the system offline and move
some new file into the folder, whenever the device is connecting to internet and the new file will
be remove because the system will synchronizing the online storage file to the device.
The reason for choosing file sharing and synchronizing system is try to eliminate the
weakness of the system by using the architecture evaluation. There possible some missing
component in the existing architecture diagram so that affected the system performance and
security.
Furthermore, to ensure the system can be modify easily will be the reason as well. If a
system is planned wrongly, it is possible affect the system difficult to modify or might cause
some impact to others function in the system when modified.

System Architecture and Testing

1.3 Evaluation Criteria
Based on the reason for chosen system above, the system is ready for an architecture
evaluation. Currently, the system already have exist architecture diagram but the diagram had
just showing casually and it shall do the architecture evaluation again. Redo the architecture
evaluation can reduce the security issues that mentioned at the previous part. Additional, the
architecture evaluation not only reduce the issues but also improving the system functional and
performance.
The architecture evaluation can be do as soon as possible so that the issues able to reduce
early and the system will cause less issues in the future. The architecture evaluation can also
clearly state out the quality of the system to the user and owner and make a better understanding
to them.
After the architecture evaluation, the system will meet its quality goal. The system will
run with a better performance and always available. Additional, the system will also able to
support by any platform and devices without bug or problems. The security issues can be reduce
or eliminate, the system can be modify easily without spending much time and cost.

System Architecture and Testing

The Entity Relationship Diagram above clearly shown the relation between the entities. The
user can has one or more devices to connect to one storage that they brought and the storage can
store up to 5 gigabyte files with different data type. The user can also share one or more file and
folder link that contain all the stuff the owner have.

System Architecture and Testing

2.0 Stakeholder Consensus Realization Analysis Method (SCRAM)

Presentation
In the presentation phase there will contain 2 steps. Present the business driver and
present the architecture. In order to avoid the issues will appear during implement or maintain
the system and reduce the stakeholders misunderstanding of the system and business process, the
presenting phases will be present the functional requirement and quality attribute.
Step 1: Present the Business Drivers
In this step, all the participants in the evaluation must understood how the file sharing and
synchronizing system going to be evaluated. The business perspective have to be present by the
project manager and the system must be presented itself. Commonly the system itself must
describe the most important functional requirements, technical, managerial, economic, or
political constraints, major stakeholders, architecture drivers, business goals and context.
For the file sharing and synchronizing system, the stakeholders will be the users, system
owner, and evaluate team. The functional requirements will be the services of the system and it
included:
a. Synchronize the files
The files that upload or move inside to the system folder will be synchronize to the online
storage. The files can be automatically synchronize not only in computer but also the
mobile devices.
b. Share files by link
The files able to share by generate a link and others users able to download the files by
click the link.

System Architecture and Testing

The quality attribute requirement will be the constraint of the system. The quality attribute
requirement included:
a.
b.
c.
d.
e.

Security The ability to provide different levels of secure access.

Modifiability The system can be modify without giving an impact to other function.
Portability The system able to run in different type of platform and devices.
Availability The time to recover the system when technical error is appear.
Reliability The average downtime per month or year.

Step 2: Present the Architecture

In the present architecture step, the amount of information, the time needed and the risk
of the system faces will be important. In this step should also cover the technical constraint,
interact and architectural approaches used to meet quality attribute requirements.
In high level architectural views, functions, the decomposition functionality, thread and
hardware can be present.

System Architecture and Testing

Investigation and Analysis
Step 3: Identify the Architectural Approaches

The diagram show the user can upload, view and share their files from the or to the online
storage. This system is combination of web application, service management, data access and
storage on desktop and mobile operating system. So the user can manage their files such as
upload new file, modify the files or remove the files and the system automatically synchronize
the new file or the overwritten files.
9

System Architecture and Testing

The system owner able to see the report and view the access log of the users. Whenever a
user login to the system or logout, the report of the owner will automatically write a new line of
log that store the login and logout date of users. Additional, the upload files that own by users
also will be record to the log.

10

System Architecture and Testing

Step 4: Generate the Quality Attribute Utility Tree
In this step, utility tree will be build and it is use to prioritize and identify the systems
most important quality attribute goal. This quality attribute requirement are getting from service
owner and the users that involved in this project.

11

System Architecture and Testing

Scenario of file sharing and synchronizing system:Reliability
1. The system minimum failure per month can only be once.

Availability
1. The database must be backup by using the extra hardware and during the main database
corrupted or damaged, the system able to switch to the backup database in maximum 2
minutes.

Security
1. The system must restrict the authorized users to access to the system.
2. The system must identify the users before the users are going access to the database.

Modifiability
1. The system can be update easily whenever the service owner needed and the update will
not giving the impact to the function of the system.

Portability
1. The system must be able to running in multiple platform such as Windows OS, Linux OS,
Apple OS, and Android OS.

12

System Architecture and Testing

Step 5: Analyze the Architectural Approaches
After generate the utility tree, the quality attribute will be very important and the evaluate
team must identify the risk and sensitivity point. In this step also have to list out some question
for the quality attribute and the answer can be the important factor that cause the system success.
The question for the quality attribute for the file sharing and synchronizing system
included:
1. Reliability:
a. How often the system will be working without occurring system failure problem?
2. Availability:
a. Can the system be recover within 2 minutes during system failure?
b. How the system can be recover within 2 minutes during system failure?
3. Security:
a. Can the system identify the users before them access to the system?
b. Can the data be encrypt after it has been uploaded?
4. Modifiability:
a. Can the system update without giving impact the existing function?
5. Portability:
a. Can the system access by different operating system?

After providing the question for the quality attribute, this will give some idea and
information for the evaluate team to make decision without cause the system get into failure or
having high risk when implement.

13

System Architecture and Testing

Testing
Step 6: Brainstorm and Prioritize Scenarios
After the steps that generated the utility tree and analyze architectural the brainstorming
section will be needed. The participants can generate and suggest some idea for the system and
that is possible come out some new requirement to the evaluate team.
After providing some useful ideas, the scenario that provided from step 4 have to be
prioritize. The order of the scenario can be:
1.
2.
3.
4.
5.

Security
Availability
Reliability
Portability
Modifiability

Step 7: Analyze the Architectural Approaches

After the step prioritize, collected and analyzed the scenarios, the evaluate team can start
test the highest priority scenario. The evaluate team can present all the architectural description
to the stakeholders. The uncover information can also gain from this step and new or exist thing
need to be modify can also done in this step.

14

System Architecture and Testing

Reporting
Step 8: Present the Results
At the last phase and the last step, the collected information, utility tree, scenario and
quality attribute question will be document. The outputs will be:
1.
2.
3.
4.
5.

Non-risks documented
Utility tree
Set of scenario
Styles documented
Sensitivity points found

Those output will be information for the evaluate team to know how to implement or make
improvement of the system.

15

System Architecture and Testing

Software Architecture Analysis Method (SAAM)

Overview of SAAM
Software Architecture Analysis method (SAAM) is a relatively simple architecture
evaluation of method to define the change of the future will affect to the quality attributes or not
and how to achieved an application quality attributes base on the case study. Those quality
attributes can be modifiability, portability, scalability, reliability, performance and more. The
SAAM will request the stakeholder to enumerate a set of scenarios that represent the change that
the system will go through in the future. (Scenario-Based Software Architecture, 2013)
In addition to those technical benefits, SAAM evaluation also provides many important
social benefits the system developer. It can cause a wide group of stakeholders unite and gather
up together to discuss how to manage the architecture. Furthermore, those stakeholders who
participate in SAAM evaluation are the same as ATAM evaluation. Based on the File Sharing
system, the SAAM has been choosing as our software architecture evaluation and there will be
several steps that need to be evaluate the architecture.

16

System Architecture and Testing

Input of SAAM Evaluation
For SAAM evaluation to proceed, some form of description of the architecture should
require. The SAAM can be applied two different kinds of tasks which are analysis and
evaluation. Analysis task is to compare two or more candidate design justify which can satisfies
better to the quality requirement. (Zhu, 2005)
The input has two types of methods which are description of the architecture and
scenario-based. Description of the architecture is a set of design or the description of the
architectural design that are under part of analysis and evaluation. It provides a more detailed
description of the architectural design to let the people easier to understand about the progression
and steps. Another method is scenario-based evaluation which uses for analysis current
architecture able meet the quality requirement or not. Under this method that is a number of
scenarios can be described as the interaction of stakeholders with the system. (Scenario-Based
Software Architecture, 2013)
Therefore, SAAM is very serious to the quality requirements and the agreed to determine
the extent to which candidate architecture supports to each scenario. This means the input of
SAAM evaluation in this project is the scenario of file sharing and synchronizing system. The
system will able to let user store, sharing or sync data and these all will be the scenario of the
users integrate with the system.

17

System Architecture and Testing

Output of SAAM Evaluation
The main output is provide an evaluation report to list out which point from the
architecture has not meet the quality requirement and indicate which candidate meets the
scenarios best or show obvious alternative design under which situation that could work more
better than last time. It also has the capability to figure out the potential unsuitable design due
complicate or difficult decomposition. (Qin, 2008) As we can see that after choosing SAAM as
architecture evaluation the documentation and the relation among the stakeholders with users has
improve.
The output can be two methods. The first method is a mapping onto the architecture of
scenarios that represent possible future changes to the system, indicating areas of high potential
future complexity, plus estimates of the anticipated amount of work associated with each of those
changes. And the second method is to understanding the functionality of the system or make a
comparison of multiple architectures with respect to the amount of functionality that each
supports without modification. (Clements, 2002)
As the result after using SAAM evaluation, it has estimate the cost and performance of
the system possible to be change in future. Furthermore, the documentation of file sharing and
synchronizing system could be enhanced and functionality of system can state more clearly.

18

System Architecture and Testing

Step of SAAM Evaluation

The diagram on above is showing the several steps of activities and dependencies in SAAM
Analysis. SAAM has 6 main steps which are:
1.
2.
3.
4.
5.
6.

19

Develop Scenarios
Describe Candidate Architecture
Classify and Prioritize Scenarios
Individually evaluate Indirect Scenarios
Assess Scenario Interactions
Create the Overall Evaluation

System Architecture and Testing

Step 1 Develop Scenarios
Develop Scenarios is the first step to illustrate the scope of identifying the type of
activities that the system should support and illustrate the changes that the client anticipates will
be made to the system. During developing scenarios, there is very important to capture all major
uses and the users in the system, anticipated changes to the system, all quality attributes that a
system must satisfy now, how user integrates with the system and all foreseeable future changes
to the system. (Scenario-Based Software Architecture, 2013)
Therefore, scenarios represent task relevant to different kind of roles such as customer,
end user, marketing manager, system administrator, system developer and technician. The
develop scenarios step will usually performed two times because more iteration and architectural
has been shared and there will be more scenarios participate. Thus, perform in parallel these
activities can let them share out the idea and opinion to discuss and solve together.
File Sharing and Synchronizing system developer or stakeholders have to come out with
the scenario of this system such as the scenario with the users. Furthermore, system developer
should illustrate what kind of activities that the system should able be support and what changes
that made by client such as what platform can be support on user devices, what requirement to
uses this application, how users use this application and more.

20

System Architecture and Testing

Step 2 Describe Candidate Architecture
The second step which is the candidate architecture should be described in a syntactic
architectural notation that used to be well understood by the participants that involved in the
analysis. The architectural description should be indicating the data components, system
computation and interconnections with the environments as well as all relevant connections.
(Scenario-Based Analaysis of SA, 1996) By static representation of the architecture is a
description of how the system behaves representation over time or more dynamic representation.
The file sharing and synchronizing system presenter need to indicate clearly about how to
use architecture to communicate with the business environment and what components has to use
such as metadata can provides information about a certain item details. Using natural language or
some other more formal specification will able to let user more clearly understood about the
system. Furthermore, the developer should provide an architectural description forces the
stakeholders to think about scenarios that address specific characteristic of the architecture under
consideration.

21

System Architecture and Testing

Step 3 Classify and Prioritize Scenarios
Classify and prioritize scenarios is the third step of the scenarios analysis and it can be
classified in direct & indirect scenarios. Direct scenario can be defined as direct supported by the
architecture based on the system requirements which the system has been evolved from. This
would usually be determined by demonstrating how the existing architecture would behave in
performing the scenario.
If a scenario is not directly supported, there should be some change to the architecture
that can represent by us and this we call indirect scenarios. It can be a change to one or more
components performs an assigned activity, the addition of a component to perform some activity,
removal of a relation or component, a change of the interface and more. The prioritization of the
can base on voting of the participants.
Based on the case study of File sharing and synchronizing system, those scenarios have
to category into two groups which is direct and indirect scenario so that can more clearly to
indicate out what can be support and what cannot be support. Besides that, the developer should
organize a voting to determine the group of scenarios.

22

System Architecture and Testing

Step 4 Individually Evaluate Indirect Scenarios
Once a set of scenarios has been categorized to direct and indirect group, these scenarios
will map into the architectural description. For each scenario will determine in a table whether
the architecture can executed directly or a change would be required to executed it. For the
indirect scenario will list down the change to the architecture that supposed to be support the
scenarios and estimate the cost of the changes.
By the end of this step, there will be a summary table to list all scenarios in direct or
indirect. For the indirect scenario, the changes will required to record and describe out in the
table. The description should include the estimate of the effort for change that also include the
time and cost.

Below table will show the evaluation of File Sharing and Synchronizing system that
mapped into a table with direct and indirect.
Scenario

Scenario

Direct/Indirec

Require

Number

Number

Description

Changes

Changed

Change

the Direct

Stakeholders

programming
language
5

for

Changes
(estimate)
RM8000, 2
months

to

Python
Change

the Indirect

Stakeholders,

database

system

users & end

to

simple

users

recovery model
Change
the Indirect

Stakeholders,

application

users & end

multitasking

23

of Effort

to

users

RM5000,

weeks

RM7000,
months

System Architecture and Testing

Step 5 Assess Scenario Interaction
Assess Scenario Interaction can be define as different indirect scenarios require changes
to a single components or connection of an architecture. In such case, the affected components
require to be modified or decomposed into smaller sub-components so that can avoid the
interaction of the different scenarios.
If more than two scenarios has create is to change the single component of File Sharing
and Synchronizing system security, the interaction or some clash will occur between those
scenarios. Here is the explanation about the final change of scenario if an interaction occurs:
There will be two scenarios in charge in the File Sharing & Synchronizing security
system on the same time, one will request to use Northon as the security firewall and another will
request to use Kaspersky as the security firewall. In this case, we can see that two scenarios are
requesting to change the component in same time and this will bring the interaction or clash for
both scenarios.

Step 6 Create the Overall Evaluation

In the last step of the SAAM analysis, a weight may assign to every scenario in terms of
its relative importance and use the weighting to determine the overall ranking. The purpose of
assigning weights is to resolve the situation in which the first candidate architecture scores add
up the second candidate architecture scores. Assign weights is a process to involve all of the
stakeholders of the system.
For example of the File Sharing and Synchronizing system, the whole scenarios might be
weighted by their anticipated cost, time to market, risk or the importance of the quality factors of
the scenario. Briefly, that means this process will total up all the scenarios and determine which
scenario is the best or more importance for the chosen architecture of the system.

24

System Architecture and Testing

25

System Architecture and Testing

References
1. Anon., 1996. Scenario-Based Analaysis of SA. [Online]
Available at: http://www.sei.cmu.edu/library/assets/scenariobasedanalysis.pdf
2. Anon., 2013. Scenario-Based Software Architecture. [Online]
Available at: http://www.win.tue.nl/oas/architecting/aimes/papers/Scenario-Based
%20SWA%20Evaluation%20Methods.pdf
3. Anon., 2014. Software Architecture Analaysis Method (SAAM). [Online]
Available at: http://java.dzone.com/articles/software-architecture-analysis
4. Clement, P., 2000. ATAM: Method for Architecture Evaluation. U.S.: Software
Engineering Institute.
5. Clements, P., 2001. Evaluating Software Architectures Methods and case Studies.
America: Addison Wesley.
6. Clements, P., 2002. Evaluating Software Architectures Methods and Case Studies.
s.l.:Addison Wesley.
7. Qin, Z., 2008. Software Architecture. s.l.:Springer.
8. Zhu, H., 2005. Software Design Methodology. s.l.:Butterworth-Heinemann.

26