Software Architecture and Testing (CT059 - 3 - 2 - SAT)

Software Architecture and Testing (CT059 – 3 – 2 - SAT)
Contents
1.0 Workload Matrix .......................................................................................................................... 3
2.0 Question 1 ................................................................................................................................... 4
3.0 Question 2 ................................................................................................................................... 8
3.1 Introduction ............................................................................................................................. 8
3.2 Architecture Trade-Off Analysis Method (ATAM). ..................................................................... 9
3.2.1 Presenting the ATAM........................................................................................................ 9
3.2.2 Present business drivers .................................................................................................... 9
3.2.3 Present Architecture....................................................................................................... 11
3.2.4 Identifying Architectural Approaches .............................................................................. 12
3.2.5 Generate Quality Attribute Utility Tree ........................................................................... 13
3.2.6 Analyze Architectural Approaches .................................................................................. 15
3.2.7 Brainstorm and Prioritize Scenarios ................................................................................ 18
3.2.8 Analyze Architecture Approaches ................................................................................... 19
3.2.9 Present Result ................................................................................................................. 19
4.0 Question 3 ................................................................................................................................. 20
4.1 Introduction ........................................................................................................................... 20
4.2 Software Architecture Analysis Method (SAAM) ..................................................................... 21
4.2.1 Develop Scenarios .......................................................................................................... 21
4.2.2 Describe the Architecture ............................................................................................... 22
4.2.3 Classify / Prioritize Scenarios .......................................................................................... 23
4.2.4 Individually Evaluate Scenarios ....................................................................................... 24
4.2.5 Asses Scenario Interaction .............................................................................................. 24
4.2.6 Overall Evaluation .......................................................................................................... 25
5.0 Individual Component ..................................................................................................................... 26
5.1 Tasnim Osman – TP029986 .......................................................................................................... 26
5.2 Raymond Nathan – TP035647 ...................................................................................................... 32
5.2.1 Physical View ........................................................................................................................ 33
5.3 Inder Raj Singh – TP034595 .......................................................................................................... 39
5.3.1 Concurrency View ................................................................................................................ 39
5.4 Prethpal Singh Dhubb (TP032190) ................................................................................................ 44
1
References ............................................................................................................................................ 49
2
1.0 Workload Matrix
Task Tasnim Osman Raymond Prethpal Inder Total

Question 1 25% 25% 25% 25% 100%
Question 2 25% 25% 25% 25% 100%
Question 3 25% 25% 25% 25% 100%
Question 4 100% 100% 100% 100% 100%
Signature
3
2.0 Question 1 Commented [RN1]: NEED TO MODIFY ALL
For this assignment, the system chosen is the APU E-Bookstore System. This is a system
developed to provide access to a more generous selection of books and reading material online,
greatly allowing an expansion in the different types of genre available, as well as allowing them
to be purchased at any time. It also provides many other functionalities such as updating and
providing the latest versions of books available, facilitate purchases and allow user reviews. This
system is able to meet the needs of our customers, finding the needed books and reading
materials, and made available to more people. Making them faster and more convenient to find
books to read and order. APU E - Bookstore System is chosen as the researchers would like to
investigate how a large scale online system has been running successfully. Thus, the E -
Bookstore System has been chosen to study and investigate how their architecture has helped
them build a sustainable software. In Addition, at the end of the study, the researchers would like
to give some suggestions for better architecture design for the APU E - Bookstore System in the
future. The image below shows the current use case diagram for APU E - Bookstore System.
(Diagram 1: Use case diagram for APU E - Bookstore)
4
There are numerous reasons as to why this system’s architecture need to undergo evaluation.
First of all a suitable architecture for the system project was needed to be well defined. Without
proper architecture evaluation, the entire project faces the risk of being compromised.
Architectures that are poorly evaluated will lead to performance, security and reliability goals not
being met. This makes the entire system vulnerable to hackers or frequent failures.
Next, it is important to get the structure correct in the early developmental stages because
configuration, control libraries, schedules, budgets, performance goals, team structure,
documentation organization, testing and maintenance activities are all revolved around the
architecture (Rick Kazman, 2000). Lastly is to reduce risk and cost of changes. The cost to fix an
error during architecture evaluation is lesser than to fixing the same error found during testing.
Trying to fix or bring changes to the architecture during the development period due to certain
faults found later on, can bring about problems that could bring harm to the entire project.
Therefore it is a principle that the architecture is perfected in its beginning stages before locking
its design so no future hiccups will harm the project (Kazman, et al., 2000). Even though errors
can be fix during the development stages, the cost to bring about the changes are too high
compared as to when fixing the problems during software evaluation period. This can cause
initially planned schedules and budgets to go out of control. The maturation of any system is
dependent on the life cycle. It is of utmost importance that the architecture of the system provide
Recommended Software Architecture for APU E- Bookstore.
The Three – tier architecture which is a client – server architecture seemed the best fit when it
came to recommending an architecture for APU E – Bookstore. This architecture works on the
implementation of independent modules on separate platforms to conduct features like functional
process logic, data access, data storage and the online application interface itself. The three tier
model is a framework that is fundamental for the logical design model and it has three tiers
(levels) of services. These tiers do not relate to physical locations on the computer network, but
more of the logical layers in the application itself.
5
(Image from tutorials.jenkov.com/software-architecture/n-tier-architecture.html)
This system is made out of three layers which are:
- The presentation Layer – Which gives the clients and users access to the application.
- The Application Layer – Which houses the business protocols and data rules.
- The Data Layer – Which stores and retrieves data from the database or a permanent
storage.
Factors for choosing the software architecture
The three – tier approach provides benefits such as reusability, flexibility, manageability,
maintainability and scalability. These components are designed to be reused, and distributed
across the network of computers when needed. If the systems application base, data or
transaction volume begins to increase these components and services can be deployed onto new
servers.
6
In addition, having a separate but connected system, the system will be able to have a better
structure and load balance. The APU E – Bookstore will have a database where the book
information, customer account information and transaction history information are stored and
will not be affected if there is a need to modify the system, or a system breakdown.
Due to its design, the three – tiered application makes the client – server application thicker than
the client – side. Because it contains the service components, even though this causes more
network traffic for the system but it also has less overhead for the user.
Graphical View of Architecture
(Image taken from: help.sap.com/static/saphelp_utilities472)
This architecture is made of three tiers which are the presentation, application and data tiers. The
presentation or client layer displays the GUI and data but does not produce and results. The
application layer, plays the part of providing and using the business rules and access the data
from the database server. It also provide an extra protection layer for the database layer that is
the lower layer that contains the database servers.
7
3.0 Question 2
3.1 Introduction
Figuring out if the architecture selected is suitable for the purposed goal or not, is the longest and
most warrying part of creating a system. In particular, system architectures play a very important
role in projects of large scale that are to be developed, which means, a huge amount of money
will be required for the architecture. Therefore, any small trouble occurring may most probably
lead to the company’s downfall. As a result, it is very important to make sure the selected
architecture is a suitable one.
Architecture Trade-off Analysis Method (ATAM) satisfies the goal of understanding the
importance of architectural decisions with aspect to the quality attribute requirements of the
system. (Mario Barbacci, 2003)
The ATAM process consists of nine steps, and mostly, there must be continues adjustment to the
order of the steps to assist the availability of the architectural information. The importance of the
steps is to clearly present the activities involved in ATAM along with the outputs of these
activities.
Depending on the system, ATAMs are mostly under taken by executing the steps in three
constant days. However, it is also found that the most effective ATAMs have been those in
which the ATAM team and the customer establish a common understanding of the architecture
during an initial phase of the evaluation and then later assemble a larger group of stakeholders
for a more formal evaluation meeting.
8
3.2 Architecture Trade-Off Analysis Method (ATAM).
3.2.1 Presenting the ATAM

The first steps involves the evaluation team leader to present the ATAM to the assembled
stakeholders. The stakeholders of the APU E-bookstore would be their creditors, directors,
selected employees and shareholders. This time is used to explain the process that everyone will
be following (Klein K., 1998). This presentation is conducted so that the ATAM steps, and
techniques the will be used for elicitation and analysis. For example of these are the utility tree
generation, architectural approached-based elicitation/analysis and scenario
brainstorming/mapping. Finally the outputs from the evaluation are presented, this includes the
scenarios elicited and prioritized, the questions used to understand the architecture, a utility tree
describing and prioritizing the set of identified architectural approaches and styles, the set of
risks and non – risks discovered and the set of sensitivity points and trade-offs discovered. Once
the end of this step has been reached, everyone involved should be aware of what information
should be collected and how it will be analyzed and reported.
3.2.2 Present business drivers
All the participants in the evaluation needs to understand the system which is going to be
evaluated. In this step, the system overview from a business perspective will be presented by the
project manager. A sample outline for such a presentation is given in Figure 1. The system itself
must be presented, initially at a high level of abstraction, typically describing (Software
Architecture in Practice, Second Edition, n.d.)
• Its most important functional requirements
• Its technical, managerial, economic, or political constraints
• Its business goals and context
• Its major stakeholders
• The architectural drivers (major quality attribute goals that shape the architecture)
9
Business Context/Drivers Presentation (~ 12 slides; 45 minutes)
1. - Description of the business environment, history, market differentiators, driving

requirements,
stakeholders, current need and how the proposed system will meet those needs/
requirements (3-4 slides)
2. - Description of business constraints (e.g., time to market, customer demands, standards,
cost, etc.) (1-3 slides)
3. - Description of the technical constraints (e.g., COTS, interoperation with other systems,
required hardware or software platform, reuse of legacy code, etc.) (1-3 slides)
4. - Quality attributes desired (e.g., performance, availability, security, modifiability,
interoperability,
inerrability) and what business needs these are derived from (2-3 slides)
5. - Glossary (1 slide)
Table 1: Business Drivers Presentation Template
Based on the template above, the project manager presented the following table below in a slide
show format to the attending participants.
Business Context and Drivers APU E-Bookstore is an Online bookstore system where
users can view, order and purchase books.
High-level Functional When the system is running successfully, there are some
Requirement tasks that must be done.
For APU e-book store functional requirements, it is
specified with:
1. Customers are able to make orders.
2. Customers are able to update orders.
3. Customers are able to cancel orders.
4. Customers are able to make payment
5. Customers are able to evaluate a book.
6. Customers are able to print or save the receipts.
10
Constraints Business Technical

Users demands – user- Hardware
friendly interface requirements :
Run on current
Cost – to be as affordable as hardware
possible
Business Goals The goals of the system is to provide excellent service to
the customers and maximum profit to the company.
Quality Attributes Requirements Performance – must not have any break down.
Security – The personal and payment details must be
encrypted
Usability – It needs to have a user-friendly interface
Availability – Must be available 24 hour
3.2.3 Present Architecture
The lead architect of the team will present the architecture with proper level of detail. During this
stage the evaluation team begin deciding the architectural approach to follow. This is an
important step as the amount of architectural information available and documented will directly
affect the analysis that is possible and the quality of this analysis. For this presentation, the
architecture would cover the, technical constraints, other systems that would interact with the
system and the architectural approaches that is used to meet the quality attribute requirements.
One of the technical constraint would be the OS that it would be running on, example windows 7
or windows 10 operating system. (Maheshwari, 2005)
11
Commented [RN2]: NEED TO GIVE NAME “FIGURE 1” to

diagrams
Request most Displays data to
recently added user
books Presentation Layer
Gets latest book lists Returns book list Logical Layer
Database Data Layer
(Diagram 2: Three – tier layer representation)
3.2.4 Identifying Architectural Approaches
This step involves capturing the architectural approaches without having the need to
analyze them. We place efforts into identifying architectural approaches and styles because
these represent the architectures means of addressing the highest priority quality attributes.
One of the architectural approach that would suite the APU E – Bookstore system would be
the 3 – tier architecture. The three tier architecture is used when an effective distributed
client/server design is needed that provides increased performance, flexibility,
maintainability, reusability and scalability while hiding the complexity of distributed
processing from the user.
12
(Figure 1: Three – tier architecture model)
3.2.5 Generate Quality Attribute Utility Tree
At this stage, a utility tree is to be produced to evaluate the team work with the architecture team,
the manager and customer in order to define the most necessary quality attributes.
In every utility tree, the quality attributes of performance, modifiability, security, and availability
are the high-level nodes immediately under utility, yet, different stakeholder groups may add
their own quality attributes or may use different names for the same ideas (for example, some
stakeholders prefer to speak of maintainability). Under each of these quality factors are specific
sub-factors. For example, performance is broken down into “Data Latency” which handles the
storage of the database. This is a step toward refining the attribute goals to be concrete enough
for prioritization.
The output of utility tree creation provides a highlighted list of scenarios that serves as a plan for
the remainder of the ATAM. It tells the ATAM team where to spend its time, and in particular
where to check for architectural approaches and risks. The utility tree guides the evaluators to
look at the architectural approaches involved with satisfying the high priority scenarios at the
leaves of the utility tree (Maheshwari, 2005). Additionally, the utility tree serves to complete the
quality attribute requirements, allowing the evaluation team and the customer to define their
requirements accurately.
13
(Diagram 3: Utility Tree diagram for APU E – Bookstore)
14
3.2.6 Analyze Architectural Approaches

An architectural style includes a description of component types, a description of the pattern of
data and control interaction among the components, and an informal description of the benefits
and drawbacks of using that style. In this stage, we are required to search for architectural.
Since the scope of the evaluation has been determined by the development of the utility tree, the
next step would be to search for architectural methods which satisfy the main quality attributes.
Information must be gathered regarding every architectural approaches to carry out a basic
analysis (Maheshwari, 2005). These analysis is to ensure the usage of the architecture that is
being evaluated and has the ability to match the attributes and specific requirements. The
template for this particular step is as below.
Architectural Approaches Template:
Scenario <a scenario from the

utility tree of from
scenario
brainstorming>
Attribute <performance,
security, availability,
etc.>
Environment <relevant assumptions

about the environment
in which the system
resides >
Stimulus <a precise statement of

the quality attribute
stimulus (e.g., failure,
threat,
15
modification, …)
embodied by the
scenario>
Response <a precise statement of

the quality attribute
response (e.g.,
response time,
measure of difficulty
of modification)>
Architectural Risk Sensitivity Trade-off

Decision
Reasoning <qualitative and/or

quantitative rationale
for why the list of
architectural
decisions contribute to
meeting the quality
attribute response
requirement>
Architecture <diagram or diagrams

of architectural views
annotated with
architectural
diagram: Information to support
the above reasoning.
These may be
16
accompanied by
Explanatory text.>
Table 4:
Architectural
Approaches
Template
This template is called ABAS. The point in introducing then is that ABASs have proven to be
useful in architecture evaluations even if none of the classified styles have been clearly identified
in the architecture. All architectures have fixed patterns, since no large system is a random
collection of components and connection. But the patterns might not always be apparent; they
might not always be documented; they might not be “pure.” And the patterns might not always
be desirable. But nevertheless there are patterns. Calling out these patterns during an architecture
evaluation and explicitly reasoning about their behaviour by asking attribute-specific questions
and applying attribute-specific reasoning models is important to the evaluation. This is how we
understand the component of the architecture, without getting stuck in understanding individual
“trees.”
17
3.2.7 Brainstorm and Prioritize Scenarios
The function of scenario brainstorming is to take the pulse of the larger stakeholder community.
This works well in larger groups, enabling an environment in which the ideas and thoughts of
one person is used to stimulate the ideas and thoughts of others. This promotes communication
and creativity, which in turn helps to express the collective mind of the people involved. The
prioritized list of brainstormed scenarios is then compared with those generated via the utility
tree. This prioritization can be done based on a voting procedure, as shown below, based on the
E-Bookstore System. (Rick Kazman, 2000)
VOTES SCENARIOS QUALITY

ATTRIBUTE
13 • Publishers of books frequently send list of latest books and Performance
materials to the e-bookstore manager. The store manager compiles
a list of needed books and sends an order to the suppliers. The
supplier supplies the ordered books to the warehouse. The store
manager records the details of a new book, along with the number
of the books that have arrived in the warehouse. The store clerk
updated the website with and the information of new materials.
Invoice is sent to the accounts department to be processed and
payment made.
9 • Users can provide ‘feedback’ for a book, as a score (1-10 which Modifiability
is 0= terrible, 10= masterpiece) along with optional short text.
Users can also rate other users’ feedback as ‘useless’, ‘useful’,
‘very useful’. The bookstore’s staffs are also allowed to declare
other users as ‘trusted’ or ‘not-trusted’, based on customer’s track
records. No changes are allowed; only one feedback per user per
book is allowed.
10 • The system should manage information about books in the Manageability
bookstore, inventory, (registered) customers and books they have
ordered. It should also store information about user opinions and
book ratings.
(Table 2: Voting prioritizing template)
18
3.2.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
contribute to realizing each one. Ideally this activity will generate quality attribute specific
questions for highest priority quality attribute requirement. (Rami Bahsoon, n.d.)
3.2.9 Present Result
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 (A.Meiappane, 2013). 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 in Practice, Second Edition, n.d.)
19
4.0 Question 3
4.1 Introduction
Software architecture analysis method (SAAM) is a method that is used to evaluate a
system architecture. SAAM was initially created to allow for the comparison of competing
architectural solutions. Instead of developing a single architectural metric, SAAM produces a
number of small metrics. (Rick Kazman, 2007). We will discuss the application of SAAM to an
online E-Bookstore system, called APU E-Bookstore. The main activities that are involved in the
SAAM are explained below:
 Describe the distinctive nature of a functional partitioning for the domain.

 Plan the functional partitioning onto the architecture’s structural decomposition.
 Select a set of quality attributes with which to assess the architecture.
 Choose a set of concrete tasks which test the required quality attributes.
 Evaluate the degree to which each architecture provides support for each task.
(Rick Kazman, 2007)
20
4.2 Software Architecture Analysis Method (SAAM)
4.2.1 Develop Scenarios
The first step done is SAAM evaluation is the session of brainstorming, and it is conducted with
the stakeholders and the SAAM team to clarify the activities and tasks and the expected changes
to the system in the future. By developing the scenario we are able to capture all the important
uses of the system. However it is important to identify the stakeholder and their function that is
needed for the scenario creation.
Identifying Stakeholders and Task:
Stakeholders Tasks
System Administrators Run the system once it’s deployed and make
modification.
End User Define the system's functionality and make
use of it.
Maintainers Modify the software product after delivery to
correct faults, improve performance and
other attributes.
(Table 3: Stakeholder and task template)
21
4.2.2 Describe the Architecture
(Figure 2: Three tier architecture detailed model)
The APU E – Bookstore requires a high performance database, and therefore to

accommodate this, a configuration like this would be ideal for mid – market and enterprise
customers that would want to leverage on cloud scaling but have specific compliance needs,
legacy software or the performance of a dedicated environment. This architecture describes
and suits well towards APU E – Bookstore, in this step, the architecture chosen is explained
to the users. First an architectural notation that is simple to be understood is used to make
sure that all the parties involve understands the architecture of the system. The architectural
notation used will be explained thoroughly to enable the audience to comprehend the
architecture of the system and its behavior clearly. The system computation and data
components of system must be indicated during the describing of the system’s architecture.
All relevant connections of the system will be included to provide better view. Lastly, the
meta – data of the system is also provided for the system’s representations so that
information can be communicated across effectively, and natural language is used with no
gibberish to maximize the understand ability when describing the system’s architecture.
This will make sure that no users will be left out in comprehending the systems architecture.
22
4.2.3 Classify / Prioritize Scenarios

Once the scenarios have been created, we now need to classify them as direct or indirect. The
direct/indirect classification is a first indication of the strength of the architecture with respect to
satisfying a set of scenarios. Direct scenario is a behaviour currently supported by the system.
Which also means that it is supported by the candidate architecture based on the requirements of
the system. On the other hand, Indirect is the behaviour where the system is able to support after
some evolution. Indirect scenarios must be suffering from major or changes. The prioritization of
the scenarios is chosen through the voting’s done by different type of stakeholders. We indicate
the nature of the scenarios, and which of the Online Book Store’s modules they affect in Table
below.
Scenario Description Direct/Indirect Changes
Username/Password Direct Access and security

permission
Recovery modification
Bookmarks View Direct Able to see pervious

purchase record
Manipulate the system Direct The admin can add and

update new books
Content
Additional Security Indirect Adding 3-D Secure
Modification to better user Indirect Modify the CSS/HTML

interface
Table 4: Scenario Classification for APU Online Book Store
23
4.2.4 Individually Evaluate Scenarios
Based on the classification above there are couple of scenario which are indirect and some
modification are required. The table below is drawn to list down the changes to the indirect
group to estimate the required changes and the cost for each task.
Scenario No Description Direct / Required No. of Effort for

Indirect Changes Changed / Change
Added (estimate)
Components
16 Change the Indirect The Whole 1 2 Months
database System that
structure uses the
database
19 Additional Indirect Encrypted 2 1 month
Security for Transection,
Payment
4.2.5 Asses Scenario Interaction
Assess Scenario Interaction when two or more scenarios are requesting changes over the same
component(s) of the architecture, they are said to interact. In this case, the affected components
need to be modified or divided into sub-components in order to avoid of the interaction of the
different scenarios. In a very explicit way it is capable of showing which modules of the system
are involved in tasks of different nature. Table 1 shows the number of changes required in each
Component/Layer of the system.
24
Component / Layer No. of Changes
Client 2
Database 3
View 2
Source Code 2
(Table 5: Scenario interaction by APU E-Bookstore)
4.2.6 Overall Evaluation
Once the entire scenario has been identified and matched to the architecture, the final stage of
SAAM would be the overall evaluation. Weightage will be assigned to the scenario and an
estimated cost will show the importance and periodization of the scenario.
NO. SCENARIO PRIORITY CONSENSUS COST

1 Extra security High 70% 2 person / 4 weeks
2 Making payment High 90% 3 person / 3 weeks
3 Changing user interface Low 40% 1 person / 3 weeks
4 Updating price/book list Medium 75% 2 person / 2 weeks
25
5.0 Individual Component

5.1 Tasnim Osman – TP029986
Development View
Active Reviews for Intermediate Design (ARID) are an easy, lightweight evaluation approach
for software architecture. It is the combination of ADR with either SAAM or ATAM.
ARIM concentrates on suitability and does not require complete documentation, evaluating a
whole architecture, and not just a portion of it.
Phase 1 : Pre-meeting Step 1: Identifying reviewers
Step 2: Preparing design presentation
Step 3: Preparing seed scenarios
Step 4: Preparing for the review meeting
Phase 2: Review Step 5: Presenting ARID method
Step 6: Presenting design
Step 7: Brainstorming and prioritizing

scenarios
Step 8: Performing review
Step 9: Presenting conclusions
Phase 1 – Rehearsal
STEP 1: IDENTIFY THE REVIEWS
Category Stakeholder Responsibility
Developer Software Engineer Solve the problem and ensure

that the solution meets all
constrains of the system.
Software Architecture Design of the architecture of

both the hardware and
26
software environment
Client Administrator Run the system once it’s

deployed and make modification.
Maintainers Modify the software product after

delivery to correct faults, improve
performance and other attributes.
End User Define the system's functionality

and make use of it.
STEP 2: PREPARE THE DESIGN BRIEFING
In this step, designer will have to prepare a brief explanation of how the customer use the system
to order product, and make sure every member comprehends the system in general. This will be
followed by a Q&A session from the reviewers to clarify any misunderstandings and sort out all
discrepancies experienced by the members. Goal is to help the designer prepare a better
presentation by identifying areas where it could be improved.
STEP 3: PREPARE THE SEED SCENARIOS
Designer and facilitator prepare sample sets of scenarios and emphasis designs that has to be
discussed, tested, problem identified or suggestions. For example, the layers of the graphical user
interfaces, features and functions of the system, which programming languages and code
commands should be selected and etc. During the meeting there a few important quality
attributes that will be concerned by the stakeholders which are Conceptual Integrity,
Maintainability, Reusability, Availability and Interoperability. Below shows some important
scenarios that was prepared by the designer and facilitator to demonstrate the APU Online Book
Store system behaviour during the meeting.
27
Scenario 2: Maintainability
Make the future maintenance easier. Developing this system meets the new requirements and is
able to adapt to the changes of the technical and business environment. Including the ability to
fixing errors of features and interfaces.
Scenario 3: Reusability
Reusability of the functions in the system, identify the usage of the components and subsystems
to be suitable for use in other scenarios or other applications. This scenario can minimize the
implementation time and duplication of system components.
Scenario 4: Availability
Availability of the system under load, malicious attacks, infrastructure issues and system errors.
Which will avoid the problem of competing with other online book stores. If not, once the
system is down, customers will not be able to search or make orders from the system. In this case,
most customers will urgently select and order product from the competitor company such. That
will be causing a reduction of the company income.
Scenario 5: Interoperability
Interoperability of the system is communicating and exchanging information with Online

Banking System. While customer makes payment of the product, they have to access to the
Online Banking webpage, an interoperable system makes it easier to exchange and reuse
information internally as well as externally.
STEP 4: PREPARE THE MATERIALS
Copies of the seed scenarios and review agenda are produced for distribution. Prepare the
materials such as Microsoft PowerPoint Slides, Flash, Windows Media Player Presentation or
anything else to present the seed scenarios and discuss with reviewers. In additional, agenda of
28
the meeting, book venue for meeting and inform participants by notes or memos are very
important in the meeting stage.
Date Time Location Activities
20/5/2016 9.30 a.m. Auditorium 1 Introduction of reviews,

facilitator and
Introduction of meeting
process
20/5/2016 10.00 a.m. Auditorium 1 Present the ARID stages

and System
20/5/2016 11.0 a.m. Auditorium 1 Design Presentation

Evaluation and
Justification the APU
Online Book Store
System.
20/5/2016 12.00 a.m. Cafeteria Break, Lunch Time (Food

Prepared)
20/5/2016 12.30 a.m. Auditorium 1 Figure out the Seed

Scenarios and Q&A
20/5/2016 1.30 a.m. Auditorium 1 Discussing Brainstorm and

Voting
20/5/2016 3.00 p.m. Auditorium 1 Prioritise Scenarios Review

and sort out the
conclusion and outcomes
solutions that had
been discussed in the
meeting
20/5/2016 3.30 p.m. Auditorium 1 Meeting ends
Meeting
Agenda
Phase 2 – Review
STEP 5: PRESENT ARID
The review facilitators will spends some time to explain the steps of ARID to the participants.
Briefly explain how the APU Online Book Store system architecture follows the steps of ARID
29
evaluation method. And also explain the role of each participant and reviewers to let them
understanding their tasks in the meeting.
STEP 6: PRESENT DESIGN
After explaining the steps of ARID to the reviewers, the leading designer will present the
deployment diagram of the APU Online Book Store system. The following deployment diagram
has already been improved to demonstrate more components during the run-time of the search
product system. The search product system will comprise of 3 components which are the
application server, web server and database server. Application server and web server are the
component where all the executive functions will be carried out through GUI such as search
product, make order, make payment and etc. On the other hand, database server which stores the
customer database based on the product purchased. Therefore, at this stage, it is just to see if the
deployment design is workable.
On the other hand, the scribe captures the questions or potential issues faced by the designer as a
result of lack of resources. The resulting list is summarized to show potential issues that the
designer should address could be considered complete and ready for production. The list of
issues will be capture on a whiteboard for everyone to see, and the designer makes sure that all
the reviewers understands each issue and agrees with it before the presentation continues.
STEP 7: BRAINSTORM AND PRIORITISE SCENARIOS
The Designer allows the reviewer to suggest scenarios for using the design to solve problems
that’s expected to be faced. During brainstorming, the entire seed scenario will be put into the
pool with the each other. Reviewers might suggest that two scenarios are versions of the same
30
scenario or that one subsumes another and should be merged. After that, voting occurs. The
viewer can vote to any scenario as they wish. After the voting is satisfied, the design will then be
used to ‘test’ for usability. After the voting is completed, it is important to have made the point
that the reviewer has just defined what it means for the design to be usable, if it performs well
under the adopted scenarios, then it must be agreed that the design has passed the review.
Quality Meeting Vote

Attributes
Conceptual Integrity 7/10
Maintainability 7/10
Reusability 4/10
Availability 9/10
Interoperability 6/10
List of Scenario Voting
STEP 8: APPLY THE SCENARIOS
Reviewers should select the highest vote of the solutions of the scenarios. In this stage,
programmers have to create pseudo codes and flow chart that uses the design services to solve
the problem posed by the scenario. Designers should design the layout of the system. If there are
31
any problems or constraints faced, the facilitator can stop the design and provide whatever
necessary information for the programmers and designers before proceeding.
Priority Meeting Vote
1 Availability
2 Conceptual Integrity
3 Maintainability
4 Interoperability
5 Reusability
List of Seed Scenarios Priority
STEP 9: SUMMARISE
Close the meeting and compile minute of meeting and report. Combining all topics that had been
discussed and conclude the meeting results. Summarise the opinions and solutions of the
reviewers to solve the problems which could be showing up during the system development.
5.2 Raymond Nathan – TP035647
Introduction
32
Active Design Review (ADR) and the ATAM technique both present strong qualities when it
came to evaluating preliminary design, but something else was needed to support each other, and
so by combining the best of active design reviews and scenarios – based architecture evaluation
methods such as the ATAM (P Kruchten, 1992), Active Reviews for Intermediate Designs
(ARID) was born. ARID fill a niche in the spectrum of design review techniques. What is meant
to be achieved from this is to be able to test and confirm the suitability of the components in
relation to other parts of the architecture (Gallagher, 2000). This is done due to the reason of the
possibility of a compromise in the entire architecture due to a fault in one of the component
design. Therefore reviewing a sub – design in the early stages provide valuable information and
allows in time discovery of error, inconsistencies or incompatibility.
5.2.1 Physical View
The Steps of ARID are as below
Phase 1: Pre – Meeting Step 1 : Identify Reviewers
Step 2 : Prepare design presentation
Step 3 : Prepare seed scenarios
Step 4 : Prepare for the review meeting
Phase 2 : Review Meeting Step 5 : Present ARID method
Step 6: Present Design
Step 7 : Brainstorm and prioritize scenarios
Step 8 : Perform review

Step 9 : Present conclusions
This assignment applies the ARID exercise to evaluate the APU E – Books
Step 1: Identifying Reviewers
It’s important to have a combination of different stakeholders, as it suggest that the (4+1) view
model allows the stakeholder to know what is needed in the architecture (P Kruchten, 1992). The
33
system engineers always approach it from the physical view first and then the process view. The
people who would be the stakeholders here are the software architectures, engineers,
programmers, database administrator and system manager.
Stakeholders/ Reviewer Task

Software Engineers / Programmers / In charge of developing the APU E- Bookstore
System Architecture software and transaction system.
Database Administrator Manages and oversees the database system and
control access.
System Manager In charge of the system, oversees the system and
the transactions.
Step 2: Preparing Design Presentation
The lead designer has the responsibility of preparing a brief explanation of the APU E –
Bookstore system and present it to the stakeholders/reviewers, and its recommended to use visual
aids (such as pictures and diagrams) and make sure all the members understands the system
design generally. This would normally be followed by a Question and Answer session from the
reviewers to clear up any confusions or misunderstandings. The goal of this step is to present the
design sufficiently so that everyone within the briefing can use the design. This would also help
the designer prepare a good presentation and identify area that need improvement. Below is the
illustration
prepared for
the presentation.
E-Bookstore ordering system
34
Step 3: Preparing Seed Scenarios
In this step, a set of possible scenarios are designed and presented to the reviewers during the
brainstorming session. The reviewers have the opportunity to witness a sample set in action and
they can either accept or reject and come up with their own scenarios after the brainstorming
session. But at the end of the scenario the stakeholders should be able to get a better
comprehension of how the system operates.
Suggested Scenario:
The present members will use the APU E – Bookstore online application to browse and place
orders from the booklist and then proceed to checkout. This process should be fast and not
consume too much time. On top of that the members should be able to access the online
application through their laptop or mobile devices
Step 4: Preparing For the Review Meeting
This step includes the preparation of all the details concerning the presentation, such as the
timetable, the main agenda of the presentation and alike. This can be notified in the form of
hardcopy or sent to the stakeholders through other ways such as emails. The needed members
35
should then be able to attend with almost minimum to no absentees. An example of participation
list is shown below.
List of Participants:
No. Name: Position:

1 Tia Jackson Systems Architecture
2 Murphy Saffron Database Administrator
3 Bridget Diann Software Engineer
4 Amy Morgana Database Administrator
5 Cedric Evelina System Manager
6 Savitr Vickie Web application designer
and developer
7 Renae Myra System Developer
Meeting Agenda:
Time Activities
8.00 am Introduce the meeting agenda’s
8.10 am Give a brief explanation of the ARID
process
8.30 am Explain the APU E – Bookstore system
architecture components.
9.00 am Question and answer session
9.30 am Discussion session and brainstorming
session
10.30 am Reviewing the day’s agenda’s
11.10 am Conclude and end today’s meeting.
Step 5: Presenting ARID Method
The review facilitators who are responsible of briefly explaining the steps of ARID to the present
members take over. The provide an explanation to how the logical view system architecture
36
evaluation process works within the confines of the ARID method, and the customers and
stakeholders should be able to engage with this without any struggle, since the presenter has
already prepared them in step 4.
Step 6: Presenting the Design
In this step, the presenter is needed to explain the APU E-bookstore system that he had prepared
earlier for the reviewers. This session will cover the presentation of the architecture for the E –
Bookstore system where it covers what is the system used, why and how the system runs, and the
cost of running and maintaining the system. Which after the members present are hopefully
expected to fully comprehend the architecture of the system.
Next the lead designer would present the overview presentation and walk through the necessary
illustrations. The aim of this is to see if the design is fully functional and applicable without
having the need to reveal the technical aspects of the system. While there would be no questions
regarding the implementation or the logic behind the system, questions that are about clarifying
on the facts are allowed and encouraged.
While all of this is happening, the scribe would have the responsibility of recording each
question and noting down each of the suggestions, and the instances where the designer
referenced to a certain source. The list would then be generalized to show the highlighted issues
that the designer should review before the design can be considered as complete and ready for
production. It would be highly recommended if the list was continuously updated as each
changes is made there and then, so that no member is left behind.
Step 7: Brainstorming and prioritizing scenarios
37
In this step, the reviewers would have to brainstorm on the presented systems architecture and
compare their notes with other reviewers. They would need to come up with a decision as to
place more focus on the interface of the system or the security of the data. Because in ARID, the
reviewers are the design’s primary stakeholder, ARID can be carried out with the absence of a
complete documentation. Like ATAM, the reviewers would need to prepare scenarios, after
where they would remove to only take the most needed ones. At the end of the review ARID will
show is the following, the sufficiency, fitness and suitability of the services provided by the
design and the quality and the completeness of the documentation. Here is a scenario that shows
a stakeholder brainstorming during the session:
Some of the reviewers are using the system to browse the booklist and place them in the order
cart, if a book has run out of stock, the customer might feel that the bookstore cannot coop with
the demands, therefore the system should be able to notify the manager for books that are
currently hot selling so that they don’t run out of stock.
Step 8: Perform Review
Here, the members are supposed to review all that has been done in the presentation and meeting
from the beginning till the end, and also of all the ARID exercise and scenarios to obtain all the
information about reaching the final design of the system.
During the brainstorm session, some of the stakeholders have had some discussions but in the
end, would have come to a decisive vote to change the system architecture and accommodate the
new changes, which by the end of the meeting is reached.
Step 9: Presenting Conclusion
Finally, after going through the steps in ARID and engaging on the issues concerning the design
for the APU E – Bookstore system was rectified and the presenter with the other facilitators and
members shared opinions and discussed in – depth to reach a common feat. The lead designer
thanks the members for their participation and brings the meeting to an end.
38
5.3 Inder Raj Singh – TP034595

Introduction
5.3.1 Concurrency View
Active Reviews for Intermediate Design (ARID) are an easy, lightweight evaluation method for
software architecture that focuses on suitability and does not require complete documentation. It
is a hybrid of active design reviews and scenario-based architecture evaluation methods and
leverages active stakeholders' participation and helps to gain their early buy-in. The ARID
method provides insights about the suitability of a portion of the architecture to be used by
developers to complete their tasks. (Software Engineering Institute Carnegie Mellon University.,
n.d.). The concurrency view is used here as a necessary step for reasoning about what processes
or threads will be created and how they will communicate and share resources.
The ARID progresses over the course of two phases that are made up of nine steps. These are
shown in the table below:
Phase 1: Pre–Meeting Step 1 : Identify Reviewers
Step 2 : Prepare design presentation
Step 3 : Prepare seed scenarios
Step 4 : Prepare for the review meeting
Phase 2 : Review Meeting Step 5 : Present ARID method
Step 7 : Brainstorm and prioritize scenarios
Step 8 : Perform review
Step 9 : Present conclusions
39
Phase 1: Pre-Meeting
Phase One of ARID is basically a meeting between the lead designer and the review facilitator.
Step 1: Identify reviewers
This is where the lead designer and facilitator work together to identify the set of people who
needs be present at the review.
Stakeholders/ Reviewer Task
Programmers & System Engineers Tasks includes overseeing the development of the
APU E- Bookstore software and its transaction
system.
Database Manager & System Manages and oversees the database system and
Administrator control access to it, as well as watching over the
transaction system.
Step 2: Prepare Design Presentation
In step 2, the designer prepares a briefing explaining the design, in this case, for the APU E-
Bookstore System. The aim is to present the design in sufficient detail so that an audience
member with enough knowledge could use the design. The designer prepares a briefing
explaining the design, which is reviewed by the ARID facilitator. The designer then presents the
overview to the reviewers and walks through examples of using the design. This generally helps
to identify sections where the presentation can be improved. It also helps to set the pace for the
presentation itself, as well as giving the designer valuable practice time in presenting the topic to
a critical audience. (Clements, 2000)
The designer and the review facilitator prepare a set of seed scenarios. These are made to
illustrate the concept of a scenario to the reviewers, who have an opportunity to see a sample set.
The scenarios may or may not be used in the actual evaluation and it is up to the reviewers are
agree on adopting them or to instead reject them in favor of others they brainstorm. The designer
and the review facilitator then prepare a set of seed scenarios. In this case, the scenarios which
40
can be presented for the APU EBook-store system is the response and processing time of the
system when a payment is made for the purchase of a book. (Clements, 2000)
Possible Scenario: The current people using the APU E-Bookstore online system to review and
purchase single or multiple books from the booklist. This process should be immediate and
secure.
Step 4: Prepare for the review meeting
This is where materials for the presentation, seed scenarios, and review agenda are produced for
distribution to the reviewers during the main review meeting. The meeting is scheduled,
reviewers are invited, and steps are taken to assure that the minimum number of members of the
team is present at the meetings to make the proceedings of the meeting valid.
Date Location Time Meeting Agenda

25/5/2016 Asia Pacific University 8:00 am Introduction of
reviewers, facilitator
and topics for the
meeting of the day
such as a brief
explanation of the
ARID process and the
architecture
components of the
APU E-Bookstore
system.
25/5/2016 Asia Pacific University 10:00 am Present the ARID
Stages in detail
related to the APU E-
Bookstore System
25/5/2016 Asia Pacific University 11:30 am Brainstorming and
final discussion
session
25/5/2016 Asia Pacific University 12:30 pm End
41
Phase 2: Review Meeting
During Phase Two, the reviewers are assembled and the review meeting begins.
Step 5: Presenting the ARID methodology
This is where the steps of ARID are briefly explained by the review facilitators. They help to
provide an explanation to how the logical view system architecture evaluation process works
within the boundaries of the ARID method.
In this step, the lead designer presents an overview presentation and goes through each of the
possible scenarios. This stage is a critical milestone, and it is understood that by now there
should be no doubts concerning the implementation of the design of the system. In our case, this
included architecture for the APU E-Bookstore system where it covers what is the system used,
how the system functions, and the cost that will be needed to fully operate and maintain the
system. The aim is allow factual clarification to check if the end design chosen is suitable. The final
list is then summarized to show potential issues that the designer should address before the design could
be considered complete and ready for use.
Step 7: Brainstorming & Prioritizing Scenarios
Here, the reviewers brainstorm on the current presented systems architecture and exchange and
compare their results with others. Like the ATAM, participants suggest scenarios for using the
design to solve problems they expect to face, to which the reviewers prepare scenarios, after
which they remove the unnecessary ones. The following is a scenario that was brought up as part
of the brainstorming session:
Some of the reviewers are purchasing multiple books from the system. If the checkout process
takes a long period of time due to the large quantity of books involved, the customer might feel
that the system cannot cope with heavy demands, therefore the system should be able to process
transactions at a more optimized rate.
A situation might arise where the reviewers involved might suggest that two scenarios are
versions of the same one, or that they should be merged. This is another way of eliminating
multiple scenarios. After the pool of scenarios is narrowed down, voting occurs. Each reviewer is
42
allowed a vote total equal to 30% of the number of scenarios. They can cast their votes to any
scenario or scenarios they wish. The scenarios that have the most votes will then be used to “test”
the design for its usability. After the voting is complete, it is crucial for the reviewers to make the
point on what it means for the design to be usable. If it performs well under the adopted
scenarios, then it must be agreed that the design has passed the review. (Clements, 2000)
Now the members are to review everything that has been done in all the presentations and
meetings, including all of all the ARID exercise and scenarios to obtain complete information
about reaching the final design of the system. Once the group feels satisfied, a conclusion is
reached, either the design is correct and usable, which is indicated by the group quickly
understanding how each subsequent scenario would be carried out as a straightforward variation
on either the designer’s examples or previously exercised scenarios, or the design is deemed
unusable, which is indicated by the group finding some show-stopping deficiency. (Clements,
2000)
Step 9: Present Conclusions
This is the final step, where after going through all the required steps in ARID and the issues
with the design for the APU E-Bookstore system is rectified, the team involved contemplates if
they are satisfied with the overall progress and current state of the project. If so, the participants
are then briefly polled for their opinions regarding the efficacy of the review exercise, and they
are thanked for their involvement in the project, and the team congratulates each other on a job
well done. (Clements, 2000)
43
5.4 Prethpal Singh Dhubb (TP032190)

Functional view
An ARID exercise progresses across two phases that comprise nine steps. The table below
summarizes:
Phase 1 : Pre-meeting Step 1: Identify reviewers

Step 2: Prepare design presentation
Step 3: Prepare seed scenarios
Phase 2: Review meeting Step 5: Present ARID method
Step 6: Present design
Step 7: Brainstorm and prioritize scenarios
Step 8: Perform review
Step 9: Present conclusion
Phase 1
Phase One of ARID is carried out as a meeting between the lead designer and the review
facilitator. This meeting, in our case, lasted about a day. In this meeting, the following steps
occur:
Step 1: Identify reviewers
In step 1 the lead designer and facilitator work together to identify the set of people who should
be present at the review. Below table are the stakeholders/reviewer and its task to present.
Stakeholders/Reviewer Task
Software engineers and programmers To develop the functions of APU EBook-
store system
System Manager In charge of the system, oversees the system
and the transactions.
44
Step 2: Prepare design presentation
The designer prepares a briefing explaining of the APU EBook-store system and present
it to the reviewers. The goal is to present the design in sufficient detail so that a knowledgeable
audience member could use the design. Here, during Phase One, the designer should give a dry
run of the presentation to the review facilitator, which is helpful for several reasons. First, it lets
the facilitator see the design, and ask a set of “first order” questions that the reviewers would
probably ask, thus helping the designer prepare. Second, it helps identify areas where the
presentation could be improved. Third, it helps set the pace for the presentation itself, ensuring
that the two-hour slot was not overrun. And fourth, it gives the designer practice in presenting
the material to a critical audience.
The designer and the review facilitator prepare a set of seed scenarios. For example, the
scenarios which can be presented for the APU EBook-store system are the response of the
system when a payment is made or the time taken for an invoice to be generated. The important
aspect to note of this step is that the scenarios may or may not be used in the actual evaluation;
the reviewers are free to adopt them or reject them in favor of others they brainstorm.
Scenarios Explanation
Security The APU EBook-store system are built in a manner where data leak will not
happen as data integrity are given utmost importance while developing the
system from scratch itself
Copies of the presentation, seed scenarios, and review agenda are produced for
distribution to the reviewers during the main review meeting. The meeting is scheduled,
reviewers are invited, and steps are taken to assure the presence of a quorum of reviewers at the
meeting.
45
Date Time Location Activities

30/5/2016 10.00 a.m. APU Main Building Introduction of
reviewers, facilitator
and agenda of the day
30/5/2016 10.20 a.m. APU Main Building Present the ARID
Stages
30/5/2016 11.50 a.m. APU Main Building Explain the APU
EBook-store
architecture section
30/5/2016 12.30 p.m. APU Main Building Discussion and
Brainstorming
session
30/5/2016 1.00 p.m. APU Main Building End
Phase 2
During Phase Two, the reviewers are assembled and the review meeting commences
Step 5: Presenting ARID method
The review facilitators briefly explains the steps of ARID to the audience. Briefly
explaining how the logical view (also known as the object-oriented decomposition) system
architecture evaluation process works within the confines of the ARID method. The customers
should be able to make this connection with ease, since the presenter has been prepping them
from the very beginning.
46
Step 6: Presenting the design
The lead designer presents the two-hour overview presentation and walks through the
functions of APU EBook-store system. During this time, a ground rule is that no questions
concerning implementation or rationale are allowed, nor are suggestions about alternate designs.
The goal is to see if the functions is usable, not to find out why things were done a certain way,
or to learn about the implementation secrets behind the interfaces. Questions of factual
clarification are allowed and encouraged. The facilitator enforces this rule during the
presentation.
During this time, the scribe captures each question, or each instance where the designer
indicated that some sort of resource (usually a kind of documentation) was on its way but not yet
available. The resulting list is summarized to show potential issues that the designer should
address before the design could be considered complete and ready for production. In our case,
the list of issues was captured on a whiteboard for all to see, and the facilitator made sure that all
reviewers understood each issue and agreed with its wording before the presentation continued.
Step 7: Brainstorm and Prioritize scenarios
Just as in the ATAM, participants suggest scenarios for using the design to solve
problems they expect to face. During brainstorming, all scenarios are deemed fair game. The
seed scenarios are put into the pool with all the others. After a rich set of scenarios is gathered
which in our case was the security encryption type and payment method. Reviewers might
suggest that two scenarios are versions of the same scenario, or that one subsumes another and
should be merged. In our case, we eliminated five scenarios in this manner. After the pool of
scenarios is winnowed, voting occurs. Each reviewer is allowed a vote total equal to 30% of the
number of scenarios. They can allocate their votes to any scenario or scenarios they wish. The
scenarios receiving the most votes will then be used to “test” the design for usability. After
voting is complete, it is important to make the point that the reviewers have just defined what it
means for the design to be usable: If it performs well under the adopted scenarios, then it must be
agreed that the design has passed the review.
47
On this section the members are supposed to review the whole presentation and the
meeting in general from start to finish, and through all prior steps of the ARID exercise and
scenarios to collect all information pertaining the system, hence achieving the final design of the
system.
Step 9: Present conclusion
At the end, the list of issues is recounted, the participants are polled for their opinions
regarding the efficacy of the review exercise, and they are thanked profusely for their
participation.
48
References
A.Meiappane, B. C. P. V., 2013. International Journal of Computer Applications. Evaluation of
Software Architecture Quality Attribute for an Internet Banking System, 62(19), pp. 21-24.
Clements, P. C., 2000. Active Reviews for. [Online]

Available at: http://www.sei.cmu.edu/reports/00tn009.pdf
Dobrica L, N. E., 2002. A survey on software architecture analysis methods. IEEE Transactions
on Software Engineering, 28(7), pp. 638-653.
Gallagher, B. P., 2000. Using the Architecture Tradeoff Analysis MethodSM to Evaluate a
Reference Architecture: A Case Study. Architecture Tradeoff Analysis Initiative, 4(1), pp. 5-7.
Kazman, R., Klein, M. & Clements, P., 2000. ATAM: Method for Architecture Evaluation,
Pittsburgh: Carnegie Mellon University.
Klein K., B. L., 1998. The architecture tradeoff analysis method. Engineering of Complex
Computer Systems, pp. 68 - 78.
Maheshwari, P., 2005. Supporting ATAM with a collaborative Web-based software architecture
evaluation tool. Science of Computer Programming, 57(1), pp. 109-128.
Mario Barbacci, P. C. A. L. L. N. W. W., 2003. Using the Architecture Tradeoff Analysis

MethodSM (ATAMSM) to Evaluate the Software Architecture for a Product Line of Avionics
Systems: A Case Study. Architecture Tradeoff Analysis Initiative , 3(1), pp. 9-16.
P Kruchten, 1992. Architectural Blueprints. The "4+1" View Model of Software, 12(6), pp. 42-50.
Pacific, F. R., 2014. 4 REFERENCE ARCHITECTURES TO OPTIMIZE YOUR ECOMMERCE.

[Online]
Available at: http://www.radiofreepacific.com/a/4-reference-architectures-to-optimize-your-
ecommerce/
[Accessed 23 May 2016].
49
R Kazman, M. G. ,. W. W., 2012. Scaling up software architecture analysis. Journal of Systems

and Software, 85(7), pp. 1511-1519.
Rami Bahsoon, S. o. C. S. ,. B., n.d. [Online]

Available at: https://www.cs.bham.ac.uk/~rzb/Architecture%20Evaluation.pdf
Rick Kazman, L. B. G. A. W., 2007. SAAM: A Method for Analyzing the Properties of Software
Architectures. [Online]
Available at: http://resources.sei.cmu.edu/asset_files/WhitePaper/2007_019_001_29297.pdf
[Accessed April 2016].
Rick Kazman, M. K. P. C., 2000. Method for Architecture Evaluation. [Online]

Available at: http://lore.ua.ac.be/Teaching/CapitaMaster/Assignment/ATAM-TR.pdf
[Accessed 2016].
Software Architecture in Practice, Second Edition, n.d. [Online]

Available at: http://www.ece.ubc.ca/~matei/EECE417/BASS/ch11lev1sec3.html
Software Engineering Institute Carnegie Mellon University., n.d. Active Reviews for
Intermediate Design. [Online]
Available at: http://www.sei.cmu.edu/architecture/tools/evaluate/arid.cfm
50

Software Architecture and Testing (CT059 - 3 - 2 - SAT)

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Software Architecture and Testing (CT059 - 3 - 2 - SAT)

Caricato da

Copyright:

Formati disponibili

Software Architecture and Testing (CT059 – 3 – 2 - SAT)

1.0 Workload Matrix

Task Tasnim Osman Raymond Prethpal Inder Total

Question 2 25% 25% 25% 25% 100%

Question 3 25% 25% 25% 25% 100%

Question 4 100% 100% 100% 100% 100%

2.0 Question 1 Commented [RN1]: NEED TO MODIFY ALL

(Diagram 1: Use case diagram for APU E - Bookstore)

Recommended Software Architecture for APU E- Bookstore.

(Image from tutorials.jenkov.com/software-architecture/n-tier-architecture.html)

This system is made out of three layers which are:

Factors for choosing the software architecture

Graphical View of Architecture

(Image taken from: help.sap.com/static/saphelp_utilities472)

3.2 Architecture Trade-Off Analysis Method (ATAM).

3.2.1 Presenting the ATAM

3.2.2 Present business drivers

• Its most important functional requirements

• Its technical, managerial, economic, or political constraints

• Its business goals and context

• Its major stakeholders

Business Context/Drivers Presentation (~ 12 slides; 45 minutes)

1. - Description of the business environment, history, market differentiators, driving

Constraints Business Technical

3.2.3 Present Architecture

Commented [RN2]: NEED TO GIVE NAME “FIGURE 1” to

Gets latest book lists Returns book list Logical Layer

Database Data Layer

(Diagram 2: Three – tier layer representation)

3.2.4 Identifying Architectural Approaches

(Figure 1: Three – tier architecture model)

3.2.5 Generate Quality Attribute Utility Tree

(Diagram 3: Utility Tree diagram for APU E – Bookstore)

3.2.6 Analyze Architectural Approaches

Architectural Approaches Template:

Scenario <a scenario from the

Environment <relevant assumptions

Stimulus <a precise statement of

Response <a precise statement of

Architectural Risk Sensitivity Trade-off

Reasoning <qualitative and/or

Architecture <diagram or diagrams

3.2.7 Brainstorm and Prioritize Scenarios

VOTES SCENARIOS QUALITY

3.2.8 Analyze Architecture Approaches

3.2.9 Present Result

 The architectural approaches documented

 Describe the distinctive nature of a functional partitioning for the domain.

(Rick Kazman, 2007)

4.2 Software Architecture Analysis Method (SAAM)

4.2.1 Develop Scenarios

Identifying Stakeholders and Task:

4.2.2 Describe the Architecture

(Figure 2: Three tier architecture detailed model)

The APU E – Bookstore requires a high performance database, and therefore to

4.2.3 Classify / Prioritize Scenarios

Scenario Description Direct/Indirect Changes

Username/Password Direct Access and security

Bookmarks View Direct Able to see pervious

Manipulate the system Direct The admin can add and

Additional Security Indirect Adding 3-D Secure

Modification to better user Indirect Modify the CSS/HTML

Table 4: Scenario Classification for APU Online Book Store