Table of Contents

Introduction .................................................................................................................................................. 3
Literature review........................................................................................................................................... 4
Quality attributes ...................................................................................................................................... 4
Step 1: Present the ATAM ............................................................................................................................. 6
Techniques ................................................................................................................................................ 7
Utility Trees ........................................................................................................................................... 7
Step 2: Present Business Drivers................................................................................................................... 7
Functional Requirements .......................................................................................................................... 8
Important Quality Attributes .................................................................................................................... 8
Step 3: Present Architecture ......................................................................................................................... 8
Architecture .............................................................................................................................................. 8
Three-tier Architecture ......................................................................................................................... 9
Step 4: Identify Architectural Approaches .................................................................................................. 10
Step 5: Generate Utility Tree ...................................................................................................................... 11
Step 6: Analyze Architectural Approaches.................................................................................................. 11
Step 7: Brainstorm and Prioritize Scenarios ............................................................................................... 13
Step 8: Analyze Architecture Approaches................................................................................................... 13
Step 9: Analyze Architecture Approaches................................................................................................... 14
Software Architecture Evaluation ............................................................................................................... 14
What is SAAM?........................................................................................................................................ 15
Input to SAAM evaluation ....................................................................................................................... 15
Output of SAAM evaluation .................................................................................................................... 15
Steps and activities of SAAM .................................................................................................................. 15
1. Develop the scenarios ................................................................................................................. 15
2. Describe the architecture ........................................................................................................... 16
3. Classify scenarios ........................................................................................................................ 16
4. Individually evaluate indirect scenarios...................................................................................... 18
5. Assess Scenario interaction ........................................................................................................ 18
6. Create overall evaluation ............................................................................................................ 18
Active Reviews for Intermediate Design (ARID).......................................................................................... 20

1
 Logical View and Process View (Al Absi Osayd Nabil Ameen TP043584) ............................................... 20
Introduction ........................................................................................................................................ 20
Nine Steps of ARID .............................................................................................................................. 20
References ..................................................................................................... Error! Bookmark not defined.

2
Introduction

In the constantly rising global economy, e-commerce has become a major component
and catalyst for the world’s economic development. Organizations have revolutionized
relationships between customers and organization with the integration information and
communications technology. The organizations who have incorporated such in their
business process has acquired an invaluable advantage over their rivals. E-commerce is
defined as the buying, selling and exchanging of products, services and information via
the computer network, primarily the Internet.

E-commerce introduces huge opportunities despite the challenges, but an e-commerce

business is as successful as its business
model, system development process and its operations. Therefore, developing a high
quality software system is a success factor for an online business. Web Engineering is a
systematic and disciplined use of methods and tools for developing and evaluating web-
based systems.

To evaluate the quality of the product, a set of quality characteristics that describe the
product and form the
basis for the evaluation is required.
The paradox of quality assurance is that, although “quality” is a key value for every
organization, the actions taken to ensure it are often left until late in the software
development lifecycle when budgets are scarce, time is short and there is high pressure to
deliver to the market. (Wan Ab.Rahman, et al., 2015)

3
Literature review

Functionality
Functionality of a system is basically the ability of the system to work as it is intended to
work. A system is supposed to be easy on the eyes, user friendly and easy to navigate
through. Since our system is a Web based system it should also be compatible with
devices across multiple platforms and browsers. An online shopping system relies on
ease of access which is not found on traditional shopping outlets. Ease of access features
such as a shopping cart system which allows users to bookmark their favorite items while
they browse for further items to buy is a must needed feature both from the users and also
a business point of view. User should be able to add or remove items from their cart as
needed as well. Another neat feature is the item tracking system which allows users to
track any items they have purchased, and the delivery time as estimated. A search
function is the most needed feature - online shopping systems are moot without it as the
catalogs are usually vast and it is almost impossible to find any desired item if the user
must go through each item. (Wan Ab.Rahman, et al., 2015)

Quality attributes

Since our online shopping system is a Web-based system, it will be used by a plethora of
users who expect a certain level of quality and convenience. This can be defined using
various defining quality attributes such as

Performance
Performance is one of the most important quality attributes in online shopping platforms.
Customers like convenience and performance heavily impacts the convenience of a user’s
shopping experience. Users will care a lot about how long the menu takes to show up,
how long it takes to place the order, how quick the response time is. That is why
Performance is very important to an e-commerce web application.

4
Security
Security is a major quality attribute not only in online shopping platforms but almost
every existing platform out there. Since an online shopping system is a hub for multiple
and usually large transactions, it is absolutely necessary for features such as authorization
and authentication. Users of the shopping system must be identified in order to track
them and provide them a certain level of assurance and user satisfaction. Payments are
primarily done online, and if left unchecked could be the target of malicious attacks. A
secure platform must be utilized by the online shopping system that provides them with
features such as email or text notifications that notify users of their transactions.
Data collection and privacy is another need of a user. Users must have the ability to
control how much data is collected and the amount of privacy is provided by the system.
Breaches are not to be tolerated and everybody's right to privacy is to be respected. (Wan
Ab.Rahman, et al., 2015)

Availability
Availability is part of reliability and is expressed as the ratio of the available system time
to the total working time. It is quite an important quality attribute for an online shopping
system. Customers can unexpectedly decide to purchase a product. The system is always
expected to be there for them. (Korkishko, 2018)

5
Step 1: Present the ATAM

The first step calls for the evaluation leader to present the ATAM to the assembled project
representatives. This time is used to explain the process that everyone will be following, to
answer questions, and to set the context and expectations for the remainder of the activities.
Using a standard presentation, the leader will describe the ATAM steps in brief and the outputs
of the evaluation. (Bass, Clements, & Kazman, 2003)

The ATAM is based upon a set of attribute-specific measures of the system

 Analytic (performance & availability)

 Qualitative (modifiability, safety, security)

The ATAM workshops typically takes three days and the involvement of 10-20 people

 Evaluators
 Architects
 And other system stakeholders

Benefits:

 Clarified quality attribute requirements

 Improved architecture documentation
 Documented basis for architectural decisions
 Identified risks early in the life-cycle
 Increased communication among stakeholders

Outputs:

 Architectural approaches
 Utility tree
 Scenarios
 Risks and “non-risks”
 Sensitivity points and tradeoffs

6
Figure 1: Architectural Decisions

Techniques

Utility Trees
Utility trees are a way to organize these quality attributes. Regarding ATAM they serve to
prioritize quality attributes and later to evaluate the suitability of a candidate architecture vs. the
requirements.

Step 2: Present Business Drivers

Everyone involved in the evaluation-the project representatives as well as the evaluation team
members-needs to understand the context for the system and the primary business drivers
motivating its development. In this step, a project decision maker (ideally the project manager or
the system's customer) presents a system overview from a business perspective. The presentation
should describe the following:

7
  The system's most important functions
 Any relevant technical, managerial, economic, or political constraints
 The business goals and context as they relate to the project
 The major stakeholders
 The architectural drivers (that is, the major quality attribute goals that shape the
architecture) (Bass, Clements, & Kazman, 2003)

Functional Requirements

 User can see the product, their prices and quantity available.
 Users can buy products
 Users can write feedbacks of products and services
 Administrators can add, edit and delete products
 User can add items to cart
 System can store feedback given by the customer

Important Quality Attributes

1. Performance
2. Security
3. Availability

Step 3: Present Architecture

Here, the lead architect (or architecture team) makes a presentation describing the architecture at
an appropriate level of detail. The "appropriate level" depends on several factors: how much of
the architecture has been designed and documented; how much time is available; and the nature
of the behavioral and quality requirements.

In this presentation the architect covers technical constraints such as operating system, hardware,
or middleware prescribed for use, and other systems with which the system must interact. Most
important, the architect describes the architectural approaches (or patterns, if the architect is
fluent in that vocabulary) used to meet the requirements.

To make the most of limited time, the architect's presentation should have a high signal-to-noise
ratio. That is, it should convey the essence of the architecture and not stray into ancillary areas or
delve too deeply into the details of just a few aspects. Thus, it is extremely helpful to brief the
architect beforehand about the information the evaluation team requires. (Bass, Clements, &
Kazman, 2003)

Architecture

8
Three-tier Architecture
Three-tier (layer) is a client-server architecture in which the user interface, business process
(business rules) and data storage and data access are developed and maintained as independent
modules or most often on separate platforms. The Architecture of an Online Shopping system is
based on three-tier architecture. The three logical tiers are
• Presentation tier
• Middle tier
• Data tier
The main reason for considering three-tier architecture for the Online Shopping System is as
follows.
Flexibility:
 Management of data is independent from the physical storage support
 Maintenance of the business logic is easier
 Migration to new graphical environments is faster
 If there is a minor change in the business logic, we don’t have to install the entire system
in individual user’s PCs.
Reusability:
 Reusability of business logic is greater for the presentation layer. As this component is
developed and tested, we can use it in any other project and would be helpful for future
use.

Security:
 More secured architecture since the client cannot access the database directly.
(Mummaneni)

9
Figure 2: Three Tier Architecture

Step 4: Identify Architectural Approaches

In this step the architectural approaches are being identified by the architect. It then will be
handed to the analysis team, but it will not be analyzed yet. The architectural approaches
determine the structure of the system. Other than that, it also describes the ways in which the
system can grow, change.

10
Step 5: Generate Utility Tree

Figure 3: Utility Tree

Step 6: Analyze Architectural Approaches

Scenario: Detect and Recover from hardware failure of main switch

Attribute Availability
Environment Normal Operations
Stimulus One of the CPUs fails
Response 0.9999 availability of switch

11
 Architectural Sensitivity Tradeoff Risk No
decisions risk
Backup CPU(s) S2 R8
No backup data S3 T3 R9
channel
Watchdog S4 N12
Heartbeat S5 N13
Failover routing S6 N14
Reasoning Ensures no common mode failure by using different
hardware and operating system(R8)

Guaranteed to detect failure within 2 seconds based on

rates of heartbeat and watchdog

Watchdog is simple and has proved reliable

Architecture
Diagram

Figure 4:Scenario Table(Bass, Clements, & Kazman, 2003)

Scenario: Detect unauthorized access

Attribute Security
Environment Normal Operations
Stimulus Wrong username or password credentials
Response Access Denied
Architectural Sensitivity Tradeoff Risk No
decisions risk

12
 Backup
CPU(s)
No backup
data channel
Watchdog
Heartbeat
Failover
routing
Reasoning Ensure there is no unauthorized access
Architecture
Diagram

Figure 5: Scenario Table 2

Step 7: Brainstorm and Prioritize Scenarios

The function of scenario brainstorming is to take the opinion of the bigger stakeholder
community.
This functions admirably in bigger gatherings, empowering a situation where the thoughts and
musings of
one individual is utilized to animate the thoughts and considerations of others. This advances
correspondence and imagination, which thus communicates the aggregate personality of the
individuals in question. The
organized rundown of conceptualized situations is then contrasted and those created by means of
the utility
tree. This prioritization should be possible dependent on a democratic strategy, as demonstrated
as follows, based on the e-commerce web application.

Step 8: Analyze Architecture Approaches

Once all the scenarios have been prioritized, the evaluation team probes architectural approaches
from the point of view of specific quality attributes to look for potential risks, non-risks,
sensitivity points and tradeoffs. The architect explains how relevant architectural decisions

13
contribute to realizing each one. Ideally this activity will generate quality attribute specific
questions for highest priority quality attribute requirement

Step 9: Present Results

After that, the collected information from the ATAM is summarized and presented once again to
stakeholders. In this presentation all the steps of the ATAM and all the information collected in
the steps of the method, including the business context, driving requirements, constraints, and
architecture are summarized and shown. Then the following outputs are
presented:
 The architectural approaches documented
 The set of scenarios and their prioritization from the brainstorming
 The utility tree
 The risks discovered
 The non-risks documented
 The sensitivity points and tradeoff points found
These outputs are then all uncovered, publicly captured, and cataloged during the entire
evaluation.

Software Architecture Evaluation

Software architecture is the fundamental organization of a system, embodied in its components, their
relationships to each other and the environment, and the principles governing its design and evolution
[IEEE 1471]. Simply said, the software architecture of a system is a high-level design or a depiction of the
software’s structure – a framework, which provides an explanation on how the system behaves in terms
of the software components, its relationships and their properties. This acts as a foundation on which
software can be built. The software architecture of a system is responsible for all of its quality attributes
such as maintainability, portability, modifiability, reliability and flexibility amongst many others

14
The foundation for any software is its architecture - it can make or break the system. Predictably, this is
vital to the success of a system. One method of software architecture evaluation is SAAM – Software
Architecture Analysis Method and we are going to discuss how to implement this method in greater
detail -

What is SAAM?
SAAM is a scenario-based software architecture evaluation method. It determines how specific quality
attributes are achieved using the proposed architecture and how any modifications to the architecture
affects said quality attributes.

Input to SAAM evaluation

Our inputs in the SAAM evaluation are the major quality attributes that we are focusing towards. These
are broken down into certain scenarios that correspond to a certain quality attribute. Inputs may also
refer to the system’s architectural design, the system stakeholders and their relevance to the scenario

Output of SAAM evaluation

SAAM is a software architecture evaluation method that is used to fine tune the edges and streamline
our proposed system architecture. SAAM helps stakeholders get a clearer concept of what the system is
supposed to be doing. It further helps in revealing the quirks in the system with the help of scenarios
and provides a solution to this problem. Cost and effort estimates are also considered making
architectural analysis a lot easier, which is vital to the development of the system.

Steps and activities of SAAM

SAAM consists of six main steps -

1. Develop the scenarios

Our first step in SAAM is to identify the activities the system must carry out and support. We should also
note any kind of modification or variations that is to be expected from these activities. These activities
are called system scenarios. Scenarios must be developed keeping the system users/stakeholder in
mind, what tasks are relevant to these stakeholders and what quality attributes are required but most
importantly, we must anticipate for any changes to the system and how our system can support
evolution in terms of functionalities or change in activities. It is recommended to perform this activity
more than once in order to fine tune our list of scenarios.

Our stakeholders must be recognized, and they are listed in the following

STAKEHOLDERS DESCRIPTION
CUSTOMERS Stakeholders who browse and buy goods listed in the system
SUPPLIERS Stakeholders who sell their goods via the system

15
 MARKETING Stakeholders who promote the system and the goods within
DEVELOPERS Stakeholders who develop the system and maintain it

Our scenarios will be as follows

SCENARIO NUMBER DESCRIPTION

1 System must be able to recognize wrong username and password
2 System should allow customers to order goods from system
3 System should allow suppliers to update their item stocks
4 System should allow suppliers to add new items to marketplace
5 System should allow customers to change their payment method
6 System should notify customers upon successful or failed delivery
7 System must allow marketing to change banner advertisements
8 System should be ported to a different operating system
9 System must accommodate a bigger database over time
10 System must notify users when servers are down
11 System must be open to future design changes
12 System must be open to future optimization changes
13 System should recommend items of interest to customers

2. Describe the architecture

In our second step of SAAM, we are required to document and present our architecture. Our
architecture must be cleanly displayed with easy, well understood notations that our participants can
easily grasp. All important aspects of our architecture must be covered such as the system computation,
the data components as well as all relevant connections – all the static and dynamic behaviors of the
system must be covered. All sets of metadata should also be provided for given information. Our
documented data must be suitable for our audience and must take care to address our specific scenarios
as well

3. Classify scenarios
In the third step, we must classify our scenarios. There are two classes of scenarios

 Direct scenarios - Scenarios that can be handled by the system without any sort of modification
Our direct scenarios were sorted as

SCENARIO
DESCRIPTION CLASSIFICATION
NUMBER
System must be able to recognize wrong username and
1 Direct
password
2 System should allow customers to order goods from system Direct

16
 3 System should allow suppliers to update their item stocks Direct
System should allow suppliers to add new items to Direct
4
marketplace
System should allow customers to change their payment Direct
5
method
System should notify customers upon successful or failed Direct
6
delivery
System must allow marketing to change banner Direct
7
advertisements

 Indirect scenarios – Scenarios that are not directly/explicitly supported. These scenarios require
some amount of change to the system such as addition of components, or a connection between
components etc.
The following are the indirect scenarios from our list of total scenarios

SCENARIO CLASSIFICATION
DESCRIPTION
NUMBER
8 System should be ported to a different operating system Indirect
9 System must accommodate a bigger database over time Indirect
10 System must notify users when servers are down Indirect
11 System must be open to future design changes Indirect
12 System must be open to future optimization changes Indirect
13 System should recommend items of interest to customers Indirect

17
 4. Individually evaluate indirect scenarios
Indirect scenarios require some amount of change to the system such as addition of components, or a
connection between components etc. In this step, we need to identify the changes that must be done to
our architecture, in order to accommodate the scenarios. Every indirect scenario must be evaluated, and
all the architecture modifications must be listed, along with the estimated cost and effort required to
implement the modification. Finally, a summary table should be produced that lists all the indirect
scenarios along with the anticipated changes to support these changes.

SCENARIO REQUIRED COST AND

DESCRIPTION
NUMBER CHANGES EFFORT
RM
System should be ported to a different
8 Changes to code 1000/week for
operating system
2 weeks
RM
System must accommodate a bigger Changes to code
9 1000/week for
database over time and database
1 week
System must notify users when servers are RM 500/week
10 Changes to code
down for 1 week
System must be open to future design Changes to code RM 500/week
11
changes and database for 1 week
RM
System must be open to future optimization
12 Changes to code 1000/week for
changes
1 week
System should recommend items of interest Changes to code RM 500/week
13
to customers and database for 1 week

5. Assess Scenario interaction

In the fifth step we need to access how scenario interaction. When multiple scenarios require a change
over the same component in an architecture, the scenarios are said to interact. This exposes the poor
allocation of functionality to the product’s design. Areas of high scenario interaction can lead to
structural complexity of architecture. Architectural integrity comes to question when unrelated
scenarios affect the same component. Nevertheless, the affected components can be modified or
decomposed into smaller sub-components, which in turn will avoid interaction of the different
scenarios.

6. Create overall evaluation

This is the final step of SAAM. Each and every scenario is evaluated, and a weight is assigned, in terms of
the business goals the scenario can accomplish and the general contribution of the scenario in terms of
the overall success of the system. This is also tabulated with the estimates in regard to cost and risks of
the changes to architecture. This process may be a subjective process but regardless it still needs to
maintain proper procedure and is done in a structured fashion. Finally, the most suitable architecture is

18
proposed, which will specify which scenarios are the most important and the organization must decide
whether the current design is acceptable or whether they should move forward with the proposed
changes in architecture.

SCENARIO
DESCRIPTION WEIGHTAGE
NUMBER
System must be able to recognize wrong username
1 High
and password
System should allow customers to order goods
2 High
from system
System should allow suppliers to update their item
3 High
stocks
System should allow suppliers to add new items to
4 High
marketplace
System should allow customers to change their
5 High
payment method
System should notify customers upon successful or
6 Low
failed delivery
System must allow marketing to change banner
7 Medium
advertisements
System should be ported to a different operating
8 High
system
System must accommodate a bigger database over
9 High
time
10 System must notify users when servers are down Low
11 System must be open to future design changes Medium
System must be open to future optimization
12 Medium
changes
System should recommend items of interest to
13 High
customers

19
Active Reviews for Intermediate Design (ARID)
Logical View and Process View (Al Absi Osayd Nabil Ameen TP043584)
Introduction
ARID merges the ADR aspect of reviewing in-progress architecture with a main emphasis on a
set of issues, and the ATAM and SAAM way of scenario-based review focused on quality
attributes (Microsoft, 2010). In this case, the logical view model is chosen from the 4+1
Architecture Model to provide the ARID exercise to walk through.
The logical view describes, for example, objects and their interactions; the process view
describes system activities, their concurrency and synchronization; the physical view describes
the mapping of the software onto the hardware, server, and network configuration; and the
development view describes the software's static structure within a given development
environment.
The process view focuses on the dynamic aspects of the system, i.e., its execution time behavior.
This view is also derived from logical view. This view is an abstraction of processes or threads
dealing with process synchronization and concurrency. It contributes to many non-functional
requirements and quality attributes such as scalability and performance requirements.
Nine Steps of ARID
Phase 1: Rehearsal Step 1: Identify reviewers
Step 2: Prepare design presentation
Step 3: Prepare seed scenarios
Step 4: Prepare for the review meeting
Phase 2: Review Step 5: Present ARID method
Step 6: Present design
Step 7: Brainstorm and prioritize scenarios
Step 8: Apply the scenarios
Step 9: Summarize
Figure 6: Steps of ARID

This assignment will follow the steps from the table above and will be used to evaluate the e-
commerce web application.

20
Step 1: Identify Reviewers
The first step in ARID is to identify who are the reviewers such as
 Web Developers: In charge of developing the website’s functionalities
 Web Designer: In charge of the website’s layout and look.
 Database Administrators: In charge of the database system.
 System Analysts: In charge of gathering requirements and designing the flow of the
system
 Managers: In charge of overlooking the whole system’s functionalities
Step 2: Prepare Design Presentation
In this step, the system analyst is the one who prepares a general explanation of the e-commerce
web application to all the reviewers and gathers all the information of the system and creates a
use case diagram of the e-commerce web application to make the other reviewers clearly
understand the system. After the system analyst presents the use case and activity diagram they
have created. The other reviewers will be able to ask questions. The reason they must ask the
questions is to find areas that could be enhanced. (Techopedia, n.d.)

Figure 7: Use Case Diagram E-Commerce Website

21
Figure 8: Activity Diagram E-Commerce Website

Step 3: Prepare seed scenarios

In this step a scenario is designed to display the concepts of a part of system. From the scenarios
so that the stakeholder or reviewer will get a better understanding of how the system works.

Scenario:

Users are using the system to purchase an order online. Every time users finish purchasing,
system will show the estimated time for the product to be delivered. If the delivery duration is
not convenient for the user, system will prompt a window for user to either select advance order
or not, so that the user has the option not to order if the estimated delivery time isn’t convenient.

22
Step 4: Prepare for the review meeting

Prepare all the information relate to the presentation such as agenda of meeting, seed scenarios,
and system details. Below will show the example of participants list and agenda of meeting.

Participants:
No. Position Responsibilities

1. Web Developers In charge of developing the website’s

functionalities
2. Web Designers In charge of the website’s layout and
look.
3. Software Engineer Prepares solution and determine system
specification.
4. Database Administrator In charge of the database system.
5. System Architecture Manage risk identification and risk
mitigation.
6. System Analyst In charge of gathering requirements and
designing the flow of the system
7. System Administrators In charge of overlooking the whole
system’s functionalities

23
Agenda of Meeting:
Time Activities
10.00 am Introduction of reviewers and meeting agendas
10.15 am A brief explanation on step of ARID
10.45 am Explain the Fast Food online ordering system
architecture with justification and changes
11.00 am Q&A session
11.30 am Discussion session
– Suggesting and evaluate the scenarios
12.00 pm Review today meeting session
12.30 pm End of meeting

Step 5: Present ARID method

This is the latter phase of the ARID method; it fully explains the steps of ARID to those
participating in the meeting. The system analyst will explain how the e-commerce web
application evaluation process works step by step using the ARID methods. The purpose of this
is to let the participants understand how the flow of the meeting is.

Step 6: Present Design

The role of the presenter is to presents the details of the distribution system that had prepared
earlier to the participants and it had to explain to the participants. Ground rule is no questions or
suggestion regarding the alternate design. The goal is to see if the design is suitable, not to find
why were done a certain way. In this step a summary of information should be carried out to
point out the potential problems that the system analyst should discuss before the design is ready
for a development.

24
Figure 9: Highlighted Part of Use Case Diagram

In the figure above it shows an emphasis on the authorized access.

Figure 10 : Highlighted Part of Activity Diagram

In the figure above it displays that purchasing a product is one of the main business drivers.

25
Step 7: Brainstorm and prioritize scenarios

 Users are using the system for purchasing a product. Every time users finish ordering; an
email must be sent to them with the order details and an estimate delivery time.
 Detect and Recover from hardware failure from main switch
 Detect Unauthorized Access

Step 8: Apply the scenarios

In this step, the stakeholders will choose from the most voted scenarios by the participants. After
that a pseudo code will be created to solve the problem that was brought up by the scenario.

Finally, the basic rule is that the system analyst is not allowed to help in this step but when
something goes wrong the architect can stop the proceeding and provide whatever necessary
information.

Step 9: Summarize

In the last step, the reviewers gather the list of issues they found from using the ARID evaluation
method. This step also requires gathering the opinions of the reviewers about this review
exercise

26
Active Reviews for Intermediate Design (ARID)
Mohammed Tanveer Hossain – TP041598
Logical and process view
Active Reviews for Intermediate Design (ARID) is an architecture evaluation method that utilises the
scenario-based methods like SAAM and ATAM and combines them with Aspect Design Reviews (ADR)
aspect of reviewing quality attributes of a system architecture. ARID provides insight into the viability of
software architecture, merging architecture evaluation and specification review. For my individual
assessment, I have chosen to go with the Logical and Process view model from the 4+1 architecture
model.

A logical view indicates the functional requirements of a system. The logical view is focused on the
functionalities, the system can provide to the end-user. UML diagrams represent the objects in the
system and how they interact with other.

On the other hand, the process view focuses on the dynamic system processes – it describes the
system’s activities and how they communicate. Process view addresses concurrency, distribution,
integrators etc.

ARID Phases
ARID is divided into 2 phases and a total combined of 9 steps in their evaluation technique. The phases
and steps are as follows.

Step 1 : Identify reviewers

Step 2 : Prepare design presentation
Phase 1 : Rehearsal
Step 3 : Prepare seed scenarios
Step 4 : Prepare for the review meeting
Step 5 : Present ARID method
Step 6 : Present design
Phase 2 : Review Step 7 : Brainstorm and prioritize scenarios
Step 8 : Apply the scenarios
Step 9 : Summarize

Step 1 : Identify Reviewers

In the first step, we must identify the stakeholders/reviewers of our system are. Since our system is an
e-commerce website, we have to identify them accordingly

REVIEWER DESCRIPTION
People who oversee the development of the website and its
WEB DEVELOPERS
functionalities
People who are in charge of the design of the website such as
WEB DESIGNERS
its layout and looks

27
 People in charge of the website and its day to day
SYSTEM ADMINISTRATOR
functionalities
People in charge of gathering requirements prior to the
SYSTEM ANALYSTS
development of our system/website

Step 2 : Prepare Design Presentation

In this step, we have to present the design in detail. System analysts prepare a report which is then
presented to all the stakeholder and reviewers of the system. This acts as a trial run to the stakeholders
who can voice their opinions based on what they see. Reviewers are presented the reports prepared by
the analyst and they can ask questions which are referred to as ‘First Order Questions’. Reviewers can
identify weak spots and suggest improvements to the system. UML diagrams based on logical and
process view are created

Figure : UML Use case diagram

28
 Figure : Activity Diagram for login in swimlane

Step 3 : Prepare Seed Scenarios

Scenarios are created to illustrate the functionalities of the system. Scenarios are developed keeping the
stakeholders of the system in mind, and what tasks are relevant to the stakeholders. This scenario is
created to illustrate the concepts of the scenario to reviewers. For the purpose of our assignment, we
will take a scenario for reference.

 Customers of our system will order for goods via our system. After the customer has viewed their
desired items, they can opt to buy it and choose the number of items they want to buy. If the
desired number of items are not in stock, system will prompt a message which will allow him to
set the delivery date for a later time.

Step 4 : Prepare for the review meeting

Copies of the seed scenarios and review agenda are produced for distribution to reviewers during the
review meeting. The meeting date is set, agenda is created, reviewers are sent invitations and all the
necessary measures are taken to conduct a meeting. A review facilitator is to be assigned

29
 Time Activities
Reviewers are introduced and agenda of meeting
12:00
is explained
12:15 ARID is explained and scenarios are presented
13:00 End of briefing
13:15 Q&A session
13:45 Discussion and review of meeting
14:15 End of meeting
Figure : Meeting Agenda

Step 5 : Present ARID method

We have now shifted to the second phase of ARID. The actual review meeting is being taken place at this
point. The reviewers must be addressed by the review facilitator, and our e-commerce system is
introduced to them. ARID is explained to them and how it is used to evaluate our system.

Step 6 : Present Design

The lead web designer is in charge of presenting the design of the system. The ground rule of this step is
the alternate design of the system – no questions or suggestions must be made. The point of the system
is not to see why things are done in a certain way, but to see if the design is suitable and meets our
goals. Questions can be made by reviewers regarding the design showed, if any information was
unclear.

A designated scribe will note down every question asked and instances mentioned. The questions will be
out on display for everyone to see for the reviewers to review and further analyse.

Step 7 : Brainstorm and prioritize scenarios

Stakeholders or reviewers will suggest scenarios if any problem is addressed. A brainstorming session is
held where reviewers suggest scenarios and prioritise them accordingly. The seed scenarios are is put
into the pool of scenarios with others. Prioritising of scenarios is carried out by a process of voting.

Step 8 : Apply the scenarios

We have to select the most voted and prioritised scenarios. Pseudo codes must be created that utilize
the design services that answer the problems which have been posed by the scenario. The designer is
not allowed to help the reviewers or give tips on how to solve the problem, but the review facilitator can
interfere if the problem gets too complicated and provide any necessary assistance or information

Step 9 : Summarize
At the end of ARID, the review facilitator recounts the list of issues that have been discovered by the
reviewers. The reviewers are also given a survey to get their opinions regarding the review exercise.

30
References
Bass, L., Clements, P., & Kazman, R. (2003). Software Architecture in Practice(2nd Edition). New Jersey:
Pearson Education (US). Retrieved from 11.3 Phases of ATAM.

Korkishko, I. (2018, May 3). 12 software architecture quality attributes. Retrieved from syndicode.com:
https://syndicode.com/2018/05/03/12-software-architecture-quality-attributes/

Microsoft. (2010, January 14). Chapter 4: A Technique for Architecture and Design. Retrieved from
docs.microsoft.com: https://docs.microsoft.com/en-us/previous-versions/msp-n-
p/ee658084(v=pandp.10)?redirectedfrom=MSDN

Mummaneni, V. K. (n.d.). Architecture Design Online Book Store Phase-II. 15.

Techopedia. (n.d.). Systems Analyst. Retrieved from Techopedia.com:

https://www.techopedia.com/definition/4816/systems-analyst

Wan Ab.Rahman, W. N., Kamal, A. B., Talha, H., Josiah, B., Adamu, L., Liming, W., & Rosli, N. M. (2015).
Software Quality Assurance – E-commerce Customers. International Journal of Software Engineering and
Its Applications, 70.

Aladdin, M. (2018). Software Architecture - The Difference Between Architecture and Design. [online]
Medium. Available at: https://codeburst.io/software-architecture-the-difference-between-architecture-
and-design-7936abdd5830 [Accessed 17 Oct. 2019].

Catalogue.pearsoned.co.uk. (n.d.). [online] Available at:

http://catalogue.pearsoned.co.uk/samplechapter/020170482X.pdf [Accessed 18 Oct. 2019].

Hora, H. (2013). Saam. [online] Slideshare.net. Available at:

https://www.slideshare.net/himanshuhora/saam-26639886 [Accessed 10 Oct. 2019].

Kazman, R., Bass, L., Abowd, G. and Webb, M. (2007). SAAM: A Method for Analyzing the Properties of
Software Architecture.

Resources.sei.cmu.edu. (2018). Active Reviews for Intermediate Design (ARID). [online] Available at:
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513472 [Accessed 18 Oct. 2019].

Sceweb.uhcl.edu. (2001). Concepts: Process View. [online] Available at:

https://sceweb.uhcl.edu/helm/RationalUnifiedProcess/process/workflow/ana_desi/co_pview.htm
[Accessed 18 Oct. 2019].

31