SAT APIIT APU ASSIGNMENT A+ Grade Yong Hong Man

UC2F1110SE SAT GROUP ASSIGNMENT

Chemical E-learning web based education system

NAME: YONG HONG MAN, CHANG TZYY HAW, HOW CHEE WENG

STUDENT ID: TP019751, TP027121, TP019266

INTAKE CODE: UC2F1110SE

MODULE: CT059-3-2-SAT

Page 1


ContentsWorkload Matrix.............................................................................................................................4

Suggested Software Architecture for the System (Yong Hong Man).............................................5

Factors that for chosen software architecture..................................................................................6

Graphical view of Architecture.......................................................................................................6

General Evaluation Criteria for Software Architecture...................................................................7

Logical View...............................................................................................................................8

Process view................................................................................................................................9

Physical view...............................................................................................................................9

Development view.....................................................................................................................10

Case study(How Chee Weng)........................................................................................................11

Suggested Software Architecture for the System..........................................................................11

Factors and Principals Considered for Chosen Software Architecture.........................................12

Graphical view of the architecture.................................................................................................12

General Evaluation Criteria for Software Architecture.................................................................13

Model View Controller (Chang Tzyy Haw)..................................................................................17

Factors that for chosen software architecture................................................................................18

Create general evaluation criteria for the architecture...................................................................19

What is SAAM..............................................................................................................................25

Input to SAAM evaluation.........................................................................................................26

Output of SAAM evaluation......................................................................................................27

Steps and activities of SAAM....................................................................................................28

Step1- Develop Scenarios..........................................................................................................29

Step2- Describe/ explain the architecture..................................................................................30

Step3- Classify/Prioritize scenarios...........................................................................................31

Step4- Individually evaluate indirect scenarios.........................................................................32

Step5- Assess Scenario interaction............................................................................................33

Step6- Create overall evaluation................................................................................................34

6.0 Question 4: Active Reviews for Intermediate Designs............................................................35

6.1 Introduction..........................................................................................................................35

Page 2


6.2 Nine Step of ARID:.............................................................................................................35

Step 1-Identify Reviewers.....................................................................................................35

Step 2-Prepare design presentation........................................................................................36

Step 3- Prepare seed scenarios...............................................................................................37

Step 4- Prepare for the review meeting.................................................................................37

Step 5- Present ARID method...............................................................................................38

Step 6- Present Design...........................................................................................................38

Step 7-Brainstorm and prioritize scenarios............................................................................39

Step 8- Perform review..........................................................................................................39

Step 9 – Present Conclusions.................................................................................................39

ATAM............................................................................................................................................40

Step 1: Present the ATAM.........................................................................................................41

Step 2: Present business drivers.................................................................................................42

Step 3: Present the Architecture................................................................................................44

Step 4: Identify Architectural Approaches................................................................................45

Step 5: Generate quality attribute utility tree.............................................................................46

Step 6: Analyze architectural approaches..................................................................................47

Step 7: Brainstorm and prioritize scenarios...............................................................................48

Step 8: Analyze architectural approaches..................................................................................49

Step 9: Present result.................................................................................................................49

References......................................................................................................................................50

Page 3


Workload MatrixCriteria How Chee

WengChang Tzyy Haw

Yong Hong Man

IntroductionIndividual Component

Client-Server 100%

Three-Tier 100%

Model-Control-View 100%

Group Component SAAM 33% 33% 33%

ATAM 33% 33% 33%

ARID 33% 33% 33%

Signature

Page 4


Suggested Software Architecture for the System (Yong Hong Man)

The software architecture that has been suggested is Three-tier architectures. The three

tier model is software architecture and a software design pattern. The three-tier architecture

model is the fundamental framework for the logical design model and it has three tiers of

services.

(Figure from ibm.com)

There are 3 layers of tiers which are:

• Presentation tier

• Application tier

• Data tier

Page 5


Factors that for chosen software architecture

One of the factors that for this architecture are it is easier to modify or replace any tier

without affecting the others tier. It will easy to imply on the system that needed to be implement.

For an example, super video Business System would need to implement a new system, the user

input and the logical presentation could be only done in the first presentation tier. This will not

affect the others two layer which perform the different function.

The other factor will be the application and the database functionality will be separate.

This can help to maintain a better database structure and load balancing. For an example, super

video Business System will have database system where they need to keep record of the

customer record, they will have not affecting the database where they need to modify the system.

If the system was breaking down, the database record will still remain the same and won't get

affected.

Graphical view of Architecture

Sample of above is the graphical view of 3 tiers architecture. In this architecture it is

include 3 tiers which are presentation tier, application tier and data tier. From the diagram above,

the presentation tier will the topmost level of application which is the Laptop and Computer. The

application tier is the application server where it controls and application functionality by

Page 6


performing detailed processing. Last but not lease is the data tier which will be the database

server.

General Evaluation Criteria for Software Architecture

The 4+1 model is recommended to define the primary view of the architecture. The 4+1

model is made up of 5 main views which are the views of scenarios, logical, development,

process and physical.

Scenario Diagram

The figure above has shown the basic scenario of the case study. It shows that job and

ability task to perform by each of the users. The scenario diagram on above show the process and

the overall story of how the system progress.

Page 7


Logical View

The logical view is concerned with the functionality that the system could provide to the

user. The diagram above is the logical view of diagram which using UML pattern to represent

the logical view.

Page 8


Process view

On the diagram above show one of the processes of the system which will be the register.

Process view will explain how the system process and how they communicate.

Physical view

The physical view of the architecture is concerned with the topology of software components on

the physical layer. The following is the steps where the process of the physical layer.

1. User Send Data using COMPUTER (presentation tier)

2. Data pass though firewall

3. Data goes is web server (Application tier)

4. Data goes to application server (Application tier)

5. Finally data will store into database.

Page 9


Development view

The development view illustrates a system from a programmer's perspective and is

concerned with software management. On the diagram above it will show how the sub system

integrates with the main system. On the diagram above its show that a web server needed to

pass through when the main system need to integrate with its subsystem.

Page 10


Case study(How Chee Weng)SuperVideo (Inc) is a new company which plans to sell and rents videos, music, and

games to customers. They planned to establish two branches in KL and simultaneously embark

on an eCommerce portal to expand their reach. The vision of SuperVideos is to be a market

leader in the use of technology to provide the highest quality customer service with the broadest

range of products and services. The online system would be synchronized with the physical

system in the store which is managed by servers with database and high security components.

The system provides standard services to customers including; allowing customers to download

application and samples from the portal and play in their own computers. Registered members

are allowed to purchase or ‘rent’ movies which will be delivered electronically or physically

upon payment.

Suggested Software Architecture for the SystemThe Professional software development team have suggested using the Client–server

model architecture to build this system.

The Client–server model are involved a separate client and server system, and a connecting

network by a distributed systems. The Basic form of Client–server system contains a server

application that is accessed directly by multiple clients, referred to as below.

Figure 1 Basic form of Client-server system

Page 11


Factors and Principals Considered for Chosen Software ArchitectureFirst factor have stated that there are two branches in KL having the same database and

function. This proven that it can use this model that those two branches act as Client and having

either one branches act as a central server to share and fully utilises the database. In order to

support many clients it has to choose this architecture.

Second factor, since this is an online distributed system, it allows customer to act as a

Clients and use the system act as server though Internet, allowing customer to perform many

tasks and features like downloading application. It provide a interface (Web browser) programs

running on the Internet, able to performs tasks like access remote data stores (such as FTP clients

) . It using web-based applications through a web browser so is suitable for client server

architecture.

Graphical view of the architecture

Figure 2Client Server Architecture Diagram

Above is an example of view of the current selected architectures, the database it will

install at one of the firm’s bunches is it not necessary to be at a central place. In this firm, high

Page 12


security is high demanded due to there might have unauthorized people access to the product of

this firm.

Page 13


General Evaluation Criteria for Software ArchitectureWith the help if rational 4+1 model it can establish criteria for whether or not a system is

ready for an architecture evaluation. Beside that it can describe whole software architecture, by

using this model to compose of multiple views or perspectives. In order to address the whole

architectures, therefore 4+1 model is used by proposing the five main views concurrently as

shown below:-

Figure 3 Scenarios Diagram

The elements in the four views are shown to work together seamlessly by the use of a small set of important scenarios —instances of more general use cases. The scenarios address the overall story of the case and whole picture of the system. For example that above scenarios diagram shown that there are three users that interact with the system.

Page 14


Figure 4 Logical View

The logical view mainly addresses the functional requirements of the system. The system is decomposed into a set of component and transforms it in object classes. For example above views have shown that there are three function of the system, able login and etc. All the function can be interact from the users.

Page 15


Figure 5 Process View

The process view focus on non-functional requirements, such as performance and availability. It addresses the design’s concurrency and synchronization aspects of the architecture. For example the procedure of the one function that is undertaken and it won’t let the user know what it happening inside. All the sub activity is executing during the function.

Figure 6 Physical View

The physical view mainly focus on non-functional requirements of the system such as availability, reliability (fault-tolerance), performance (throughput), and scalability. It also addresses of the software onto hardware and show dynamic aspect of the system and explains the

Page 16


system processes. For example physical view has shown how the whole system hardware blueprint looks like. It mainly involve client and server – web server & application server

Figure 7 Deployment View

The development architecture focuses on the actual software functions hierarchy chart on the software development environment. The software is packaged in small chunks—program libraries, or subsystems— that can be developed by one or a small number of developers. For example, it shown all the sub system have cooperate to work together as a whole system and it can serve independently without executing same with the all the system.

From all the above views, it generalizes the few software criteria demanded there are:-

Higher security. All data is stored on the server, which generally offers a greater control

of security than client machines.For example, in this system the purchasing of product

need highly security in the purchasing part because it involve transaction of money and it

is a big issue of this firm. The matter of gaining trust of the customer is here.

Centralized data access. Because data is stored only on the server, access and updates to

the data are far easier to administer than in other architectural styles. For example this

firm is having one central server that everyone able to access to it, the database is install

in one of the brunches in the firm.

Page 17

Http Browser

Request Response

Controller

Model

Database

Result Interpret

View

Generates Results


Model View Controller (Chang Tzyy Haw)

The Professional software development team have suggested using the Model View

Controller model architecture to build this system. Model-View-Controller is encapsulating some

data together with its processing (the model) and isolates it from the manipulation (the

controller) and presentation (the view) part that has to be done on a user interface (UI).

(Microsoft, 2012)In simple term, the model is the packaging field data and logic, the view is the

user interface that present data to the user and the controller is intercepts user requests and

change the field of data.

This system is online distributed system, mean it allows customer visit their webpage thru

online. For example, client can search or view the product data with a simply action which click

the button. This action looks simply, but those actions explain how the system intercepts user

requests, through the field data sent between client and server, and present the result into GUI to

the client.

Graphical view of Model-View-Controller architecture:

Feature 1: Model-View-Controller architecture

Page 18


Factors that for chosen software architecture

User Interface, the junction between a user and computer program. A good user interface

design can be user-friendly and speed up the user's work. For example, user can easily

and intuitions use this system without any training e.g. user can search the product

information by type the keyword on the search box.

Convenient, this system is online distributed system. Therefore, user can access this

online system with their smart phone, laptop or mobile table anytime thru internet.

Security and privacy, this system provides member function, different user type have

different permission. All personal record will be store on the online database and only

authenticate user can access they record on the database. For example, in this system only

registered member can purchasing product thru credit card that has high security on the

payment side.

Page 19


Create general evaluation criteria for the architecture

4+1 is an architectural view model that designed by Philippe Kruchten. The views are

used to describe the system from the viewpoint of different stakeholders, such as end-users,

developers and project managers. The four views of the model are logical, development, process

and physical view. (Kruchten, 1995) Below show how 4+1 view with UML and stakeholders.

Feature 2: 4+1 view with UML and stakeholders

Page 20


Page 21

Login Purchase & Rent

Download trailer

View

Generate Report


Logical View

The logical architecture primarily supports the functional requirements i.e. what the

system should provide in terms of services to its users. (Kruchten, 1995) Below is the logical

view of SuperVideo system.

Feature 3: Logical diagram

Page 22

Client Server Database


Process View

The process architecture focuses on non-functional requirements, such as performance and availability. (Kruchten, 1995) Below is the process view of SuperVideo system.

Feature 4: Sequence Diagram

Page 23

View Menu Request

Response Send Info


Development View

The development architecture focuses on the actual software module organization on the software development environment. The software is packaged in small chunks i.e. subsystem (Kruchten, 1995)

Feature 5: Context Diagram

Page 24

Server

Database


Physical View

The physical architecture takes into account primarily the non-functional requirements of the system such as availability, reliability (fault-tolerance), performance (throughput), and scalability. (Kruchten, 1995)

Feature 6: Physical Diagram

Page 25

User

User

User

Internet


Use Case View (Scenarios)

4+1 model are establishing criteria for whether or not a system is ready for an architecture

evaluation. Below is the overall use case of SuperVideo System.

Feature 7: Use case diagram

Page 26


What is SAAM

SAAM is software architecture analysis method aim to predict the quality of a system

before it has been developed. (Oslo, 2004) The SAAM is a relatively simple architecture

evaluation method that was created to operate the vague claims of modifiability, robustness,

portability and so forth that people typically make for their architecture.

SAAM is also a method for doing a scenario based architecture analysis. The first idea to

develop SAAM is to enable competing architectural to have a comparison solution. With

experience of the architecture analysis of previous study group, SAAM has several steps that

need to be done in order to analysis the architecture.

Page 27


Input to SAAM evaluationThe input of SAAM is the quality attribute that are going to be evaluated in a SAAM

session. However, to do this evaluation, all the quality attributes must be addressed in a certain

context. This imposed the adoption of scenarios as the descriptive means in specifying and

evaluating qualities. (Mugurel,T, 2002)

Beside scenarios, there must be available for all the participants of the system

architecture, the reference artifact and the quality of scenario attached onto. Scenarios that are

describing the interaction of the users with the system will be the primary inputs to a SAAM

evaluation.

For an example, the Input of SAAM evaluation in the case of super video Business

System will be the scenario of super video business system. The super video business will be

expand their business at KL with will let the user to download, purchase or rent the video using

the system. The statement on above will be the scenario of the users integrate with the system

and it will be the main input of SAAM.

Page 28


Output of SAAM evaluationWith the strength of SAAM, the stakeholders can understand the architecture that has

been analyzed. On the other hand, some of the cases have shown that after an evaluation of

SAAM has been done, the software architecture documentation has been improved. It also can

enhance communication among the stakeholders with the users.

On the strength has been describe on above, a mapping of a brainstormed scenarios onto

the architectures of the system can be note down. As the result after using SAAM, the cost and

effort for performing the necessary change can be estimated.

For an example of Output of SAAM evaluation on the given super video business system

will be, the documentation of the expanding business of the video business system could be

enhance. Last but not lease is the cost can be estimate after the SAAM evaluation has been done.

By studying the scenario of the video business system, SAAM evaluation team can figure out

similar encounter problems and also a solution for it.

Page 29


Steps and activities of SAAM

(Diagram 1 from SAT lecture slide)

The diagram on above has shown several steps that will be involved in SAAM. The SAAM has 6

main steps in order to complete the whole SAAM process.

• Step1- Develop Scenarios

• Step2- Describe/ explain the architecture

• Step3- Classify/Prioritize scenarios

• Step4- Individually evaluate indirect scenarios

• Step5- Assess Scenario interaction

• Step6- Create overall evaluation

Page 30


Step1- Develop ScenariosThis step is to develop task scenarios that illustrate the kind of activities the system must

be support and the kinds of changes which it is anticipated will be made to the system in the

future. During the process of developing these scenarios, it's important that to capture all

important uses of a system. On the other words, the attribute and how the user intergrates with

the system need to be included.

With the scenario develop; it will be representing to different roles of task such as,

customer, marketing manager, software analyzer, developer and admin. These steps will be

usually performed two times due to the more integration and information has been shared by the

participants, the more scenarios can be made out with the brainstorm session. It is encourage to

perform this activities in parallel because of idea can be share and discuss between them.

For the example with the case study of super video business system, the developer or the

stakeholders of the super video business system need to come out with the scenario of the

system. With the super video business system, it can be categorized to groups of scenario such as

scenario with the users.

They have to illustrate the scenario that the system must be able to support and changes

to the client system. Last but not lease, Scenarios such as how the user will able to download the

application from the super video business system platform will be an example of scenario under

user group.

Page 31


Step2- Describe/ explain the architecture In this step in to explain and describe the architecture that has been chosen to the

participants. The architecture notation that has been use must clearly describe and well

understood by the audience as well as the behavior of the system.

These architecture description need to indicate the system computation and data

components, as well as all the component relationships. Some of the data such as meta-data need

to be providing also on the above presentation.

For the example with the case study of super video business system, the presenter need to

be clearly described about the architecture that need to be use and also meta-data need to be

provide on the presentation. Some of the example to let the user understood about the system

without ambiguities is to use natural language. For the case, the presenter must be able to present

and describe the notation of the architecture to the participant to let them fully understood on

what the architecture is about.

Page 32


Step3- Classify/Prioritize scenariosIn this step, the analysis of the scenarios has to be classified into two groups which are

direct scenarios and indirect scenarios. A direct scenario which is means that it is supported by

the candidate architecture based on the requirements of the system.

The direct scenarios are perfectly candidate for the architecture performance or

reliability. On the other hand the indirect scenarios must be suffering from major or changes. The

prioritization of the scenarios will be choosing by the voting of the participants.

For the example with the case study of super video business system, the scenarios have

been figured out has to be categorizing to this two groups. A voting will be held to determine the

group of the scenario will be. For an example, scenarios that were from previous user group need

to be classified into two categories. Which are the direct scenarios or the indirect scenario.

Page 33


Step4- Individually evaluate indirect scenariosAfter the scenarios have been categorized to direct or indirect group, table has to be

drawn to show the change would be required to execute it. For each of the indirect group, list

downs the changes to the software to the software architecture that need to change in order to

support the scenario and estimate the cost of each task.

By the end of this stage, summarize of table modification need to be drawn in order to

show the changes and estimate cost more accurately. This will allow the stakeholders to have in-

depth understand of how the changes made can be benefit the overall system.

Scenario

number

Scenario

description

Direct/indirect Require change Added

component

Effort for

change and

cost

5 Change the

security

software to

kaspersky

indirect The

stakeholders

and the user

1 Rm2000,

One weeks

6 Change the

programming

language of

system to Java

Direct The

stakeholders

1 Rm5000,

3 months

7 Change the

web server

hosting

direct The

stakeholders

1 Rm10000,

1 month.

Figure 2

The figure above is an example of super video business system where the evaluation of them

mapped into a table with categorized of direct and indirect.

Page 34


Step5- Assess Scenario interactionWhen two or more scenarios that are requesting to change over the single component of

the architecture there are said to have indirect interact. In this case, the components that need to

be modified have to be divided or change to avoid the interaction of different scenarios.

The favors of SAAM architecture is with the fewest scenario conflicts. For the example

with the case study of super video business system, if two scenario has been create to change the

single component of super video business system security, there might have conflict or

interaction occur in the both scenario. Thus it will create a confused situation where the final

change of the scenario should be.

One of the example will be if the super video business system security has two scenario

on the same time, one of the scenario will ask to add in Kaspersky firewall to build up high

security, another will be use Avast as the main security software; both of the scenario needed to

change the same component will have conflict or interaction occur on both scenarios.

Page 35


Step6- Create overall evaluationIn the last step, the scenarios has to be weight in terms of the relatively importance and

use that weighting to determine an overall ranking of the scenarios. This process will have to

involving all of the stake holders in the system.

The weighting that has been calculated out can reflect the importance of the quality

factors that could benefit the whole system. For the example with the case study of super video

business system, the whole scenarios that have been collected need to be weighting in order to

know the relative importance of the quality factors of the scenario. On the other words, it's just a

process which will conclude all the scenarios and determine which one is more importance or

have great affect and impact to the chosen architecture.

Page 36


6.0 Question 4: Active Reviews for Intermediate Designs

6.1 IntroductionARID evaluation method is a hybrid method between ATAM (Architecture Tradeoff Analysis

Method) and ARD (Active Reviews Designs), a lightweight evaluation approach for software

architecture that concentrates on suitability and does not require complete documentation

(Software Engineering Institute).

6.2 Nine Step of ARID: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 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 will follow the step in ARID will used to evaluate the SuperVideo System

Step 1-Identify ReviewersIn this step we had to identify the stakeholders or reviewer of the system. Such as the software

engineers, programmers, database administrator, manager.

Stakeholders/ Reviewer Task

Software Engineers/ Programmers Development the database and SuperVideo

System.

Database Administrator Deal with the database system. Who need to

be involved in and to judge the reviews

Manager In charge in the system, there need to

understand what is the system do and done.

Page 37


Page 38


Step 2-Prepare design presentationDesigner had to prepare a brief explanation of the SuperVideo System to all the

reviewers, and gather all the information of the system by illustrated context diagram of the

SuperVideo System to increase the understanding from every one of the reviewers. After

gathered all the information, presenter will do a small questioning session to the reviewers, by

asking all types of question to the reviewers. Below was the diagram that prepares for the

presentation:

Figure 8 Context Diagram

Page 39


Step 3- Prepare seed scenariosThis scenario will be used to illustrate the work of the system, from the scenarios so that the

stakeholder will get a better understand how the system works.

Scenarios:

Several of Customer and member are using the system for downloading product, rent /

purchasing product. Each time the service is provided to the Customer/Member, once the

product is not available then it will notify to the client.

Step 4- Prepare for the review meetingPrepare all the details and information relate to the presentation, example like hardcopy about the

Agenda of meeting, seed scenarios, system detail and other relate information. Below show the

example of list of participants and Agenda of meeting.

List of participants:

No: Name: Position:

1. James Lee Software Engineer

2. Albert Chua Database Administrator

3. Vincent Leong Software Engineer

4. Jennifer Database Administrator

5. Nick Chua Manager

7. Justin Ng Conversion System Developer

8. Jess Chan Conversion System Developer

Page 40


Agenda for the meeting

Time Activities

10.00 Introduction of Meeting Process section

10.10 -Explain the ARID Process

10.40 Explain the Conversion System Architecture

section

11.10 Question and Answer section

11.30 Discussion section

-Brainstorm scenario

12.00 Review today meeting section

12.30 Section End

Step 5- Present ARID methodThe review facilitators briefly explain the steps of ARID to the participants. Briefly

explain how the conversion system architecture evaluation process works with the step of ARID

method. Let the participants understanding the flow of meeting.

Step 6- Present DesignPresenter presents the detail of the distribution system that had prepared earlier to the

participants. Presenter had to explain about the conversion system in this section to the

participants. The presentation covers on the conversion system architecture where includes what

is the system, why using this system, how the system works and etc. After this section, the

participants should clearly understand the architecture of the system.

Page 41


Step 7-Brainstorm and prioritize scenariosIn this section, stakeholders had to brainstorm the systems architecture, discuss with other

people about the system base on their opinion. There need to brainstorm the question or some

scenarios for the design, example like which part the system most important, like performance

part or security part. Think about the system which part can do the improvement, weakness of

the system, or adding new feature inside the system and etc to make a better system and together

solve the problem of the system. Below show a scenario that stakeholder brainstorm during the

section:

Several of Customer and member are using the system for downloading product, rent /

purchasing product. Each time the service is provided to the Customer/Member, the speed of

system is reduce. Therefore have to limit the number of Customer/Member login to the system

implementing the FIFO concept.

Step 8- Perform reviewThis section all participants need to review back the first scenario till the end. Thru all the

step of ARID method and scenarios to gather all information and detail of the system, then

finalize the system and get the final design of the conversion system.

In the brainstorm section, some stakeholders have some arguments but in the end they

have decide to do the changing of the system. That is the final review of the system thru the

meeting end.

Step 9 – Present ConclusionsAt the end, from going through the step of the ARID method, the list of issues with the

conversion system architecture is recounted, the participants shared their opinion and thru

efficacy of the discussion section and they are thanked for their participation in the meeting.

Page 42


ATAM

Architecture Tradeoff Analysis Method (ATAM) is a useful technique for analysing and

evaluating software architectures. ATAM not only can be used to evaluate architectural decisions

against specific quality attributes, it also allows engineering tradeoffs to be made among possibly

conflicting system quality goals. Therefore, ATAM evaluation can detect areas of potential risk

in meeting quality goals within the architecture of a complex software-intensive system.

ATAM involves project decision makers, other stakeholders and a software architecture

evaluation team to determine the critical quality attributes of the system. ATAM has 3 phases

and 9 steps which are:

Phase 1: Presentation

1. Present the ATAM

2. Present business drivers

3. Present architecture

Phase 2: Investigation and Analysis

4. Identify architectural approaches

5. Generate quality attribute utility tree

6. Analyze architectural approaches

Phase 3: Testing

7. Brainstorm and prioritize scenarios

8. Analyze architectural approaches

9. Reporting

Page 43


Step 1: Present the ATAM

This step is described to the assembled stakeholders. It used to explain the process that

everyone will be following allows time to answer questions, and sets the context and

expectations for the remainder of the activities. With this action, evaluation team will collected

the information that needs by using these 3 techniques which is Utility Tree Generation,

Architecture Elicitation and Analysis and Scenario Brainstorming.

After scrutinized, the output from the evaluation, the scenarios elicited and prioritized,

the questions used to understand/evaluate the architecture, a “utility” tree, describing and

prioritizing the driving architectural requirements, the set of identified architectural approaches

and styles, the set of risks and non-risks discovered, the set of sensitivity points and tradeoffs

discovered will be reported to respective department.

Page 44


Step 2: Present business drivers

In this step, all participants’ needs understood how the system to be evaluated. The project

managers request to presents the system overview from a business perspective. The system itself

must be presented:

1. Most important functional requirements

2. Most important quality attribute requirements

3. The business goals and context

4. The major stakeholders

For the example with the case study of super video business system, this system is used to

sell and rents videos, music, and games. So for the functional requirements on this system, this

system needs a database to record the data which member purchase or rent the videos, music, and

games.

The stakeholders are the register member, product owner and the SuperVideo owner.

Functional requirements are the proclamations of services the system should deliver. It

includes how the system should react to particular inputs and how the system should behave in

particular situations. (Sommerville, 2007). The functional requirements of the system for

SuperVideo are listed as below:

1. An online portal which shall allow customers to view product info, purchase

product that available on SuperVideo.

Information of the product will be displayed in the online portal to allow customer

choose and compare. Customer also can view or try the trailer when they interest about

that product.

2. Customer’s purchase detail shall be saving in the database.

Detail of the purchase record will be store in online database after customer purchase the

related product.

3. Monthly report shall be generated by the system.

A report that generated by the system will list out the monthly sales.

Page 45


Page 46


For quality attribute requirements, i.e. non-functional requirement are the constraints on the

services or function offered by the system. It ranges from timing constraints, constraints on the

development process and standards. (Sommerville, 2007). The non-functional requirements of

the system for SuperVideo are listed as below:

1. The system shall be able to handle heavy user traffics.

The system should be able to handle at least one thousand user requests to access the

system concurrently.

2. Database should be stored the encrypted account details to protect user details.

The account details of the user who created accounts are stored in a database. The

database contains sensitive personal information such as name and contact numbers. To prevent

unauthorized access to the database, the database should be encrypted to ensure that it is secured.

3. Different access level should be available for staff and administrators.

Administrators are able to gain access to all features in the system. Staff are able to gain

access to the system, but not all features are available to staff. Features that are not available to

staff are adding product to the system and access to the database of the system. However, staffs

are able to view the purchase record that customers made.

Page 47


Step 3: Present the Architecture

Architecture team will present architecture at an appropriate level of detail, which is

technical context of the system such as an OS, hardware, or middleware prescribed for use; other

systems with which the system must interact and architectural approaches used to meet quality

attribute requirements.

For the example with the case study of super video business system with using Model-

View-Controller, this system request a server database to store the information of the product,

user personal detail such as purchase record and soon. The aim of SuperVideo is to sell and rent

the music, movie and games to customer. Nowdays most of the media software and games are

run well on Microsoft window, therefore Microsoft window 7 Professional editions are

recommended to be the system operation system , this is also because most of the user are using

Microsoft window, it will be reduce time to training the stuff to use the operating system. And

also, Microsoft window provide a good and simple use interface to user.

In other hand, the architect, project manager and marketing representative need to

describe how the system will create value of the organization. Simple description of this system,

an online application will reduce time to the user when they are planning to buy the product

without going out. And online system allow user to purchase their product on 24/7 hour. This is

another benefit by using online system.

To connect between the Presentation tier, Application tier and Data tier, i.e. client

application with server database, Internet connections are needed. And also, connection with

internet also means these systems are 24/7 hour available.

Page 48

Http Browser

Request Response

Controller

Model

Database

Result Interpret

View

Generates Results


Step 4: Identify Architectural Approaches

Current the SuperVideo system is using Model-View-Controller as architectural. Below

is the graphical view of the architecture.

As the diagram show, the product record and register member detail will be store on the

database. This system is the web application system so users only can access by internet. When

user request download the trailer from SuperVideo system, the controller will request the model

to get it from database after this, system sends the trailer to the user.

Page 49


Step 5: Generate quality attribute utility tree

Utility trees provide a top-down mechanism for directly and efficiently translating the

business drivers of a system into concrete quality attribute scenarios. With this method, should

select the most important quality goals to be the high level nodes. Below is the quality attribute

utility tree of SuperVideo:

Scenario of SuperVideo

1. A manager requests a database report via the Web during peak period and receives it no

more than 10 seconds.

2. Detail of purchase record should encrypt when store on database.

3. Half of the servers go down during normal operation without effecting overall system

availability.

Page 50

Utility

Performance

Data Latency

(M,L) Minimize latency between

client and server to 150MS

(M,L)Deliver product in day

Transaction Throughput

Modifiability

New product categories

(M,L)Update new product

(L,M)comment of the product

Change COTS

AvailabilityHardware failure

(H,w)Network failure reconnect in

<1 mins

(H,M)Server restart in <3minsCOTS software

failures

Security

Data integrity

Data confidentiality

(H,M) Credit card transcation are

secure all the time

Client database authorizzation work

99% of the time


Step 6: Analyze architectural approaches

In this step, the evaluation team probes architectural approaches with related to specific

quality attributes to identify risks. And also identify the approaches which pertain to the highest

priority quality attribute requirements of the case and generate quality-attribute specific

questions for highest priority quality attribute requirement. The evaluation team also needs to ask

quality-attribute specific questions, identify and record risks and non-risks

For the example of quality attributes question, in the case of SuperVideo Business

System:

Performance

1. How are priorities assigned to purchasing and rent?

2. What are transaction processing times?

Availability

1. How long will be taken when server restart?

2. How much transaction can be taken per day?

Portability

1. Can the different platform access this system?

At this point is the end of the second phase, the evaluation team needs to summarize the

knowledge gained of previous phase. When the assessment of decision-makers ready, members

of the evaluation team convened together, and starts the last phase. And repeat the step 1, which

is the present the ATAM and reaffirming the role played by this stage everyone, and outline the

results of step 2 to 6. Everyone will get a risk decision-making, risk-free decision-making,

sensitive point. After this, step 7 is beginning.

Page 51


Step 7: Brainstorm and prioritize scenarios

Brainstorming is an interactive group process to develop, without criticism or judgment,

IDEAS from all participants about this case. Based on quality attribute utility tree on step 5, in

order to understand the architect is how to treat the driving factors of quality attribute

framework. With this discussion process, it can be promote mutual communication, creativity,

and play the role of expressing the common wish of the participating personnel. Therefore, the

requirements of different stakeholders on the scene is not the same, for example maintenance

personnel may be more concerned about the ease of modification, the end user may focus on a

feature or ease, which need to be discussed and balanced.

After stakeholders have brainstormed a large set of scenarios, each stakeholder is

allocated a number of votes roughly, which equal to 0.3* #scenarios. Normally each stakeholder

would be given six votes. Once the votes have been made, they are tallied and the scenarios are

prioritized. Normally cut-off made separates the high-priority scenarios from the lower ones, and

only high-priority will be evaluation in future.

For the example with the case study of super video business system, the evaluate team

found many customer are suggestion SuperVideo create a mobile application to visit, purchase

and view the trailer of movie. These ideas are get many vote from stakeholder, therefore, Mobile

application are the highly ranked scenarios.

Page 52


Step 8: Analyze architectural approachesThis step actually is reiterates the activities of step 6, but using the highly ranked

scenarios from step 7. Mainly to identify the architectural approaches impacted by the scenarios

generated in step 7, and continue identifying risks and non-risks; continue annotation

architectural information.

From step 7, a new platform to access the system are suggest which is the mobile

application. In this step, evaluate team need to identify again with method step 6.

Step 9: Present resultStep 9 is the report of the ATAM; present the ATAM output which is Architectural

approaches, utility tree, scenarios, risks and non-risk and sensitivity points and tradeoffs. And the

last, the evaluate team will offer recommendations how to improve the SuperVideo system to the

owner.

Page 53


ReferencesPaul C (2000) Active Review for Intermediate Designs [Online] Available from http://www.sei.cmu.edu/reports/00tn009.pdf [Accessed 20 Jun 2012]

Clements (2000) Active Review for Intermediate Designs [Online/PPT] Available from http://www.google.com.my/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CGIQFjAD&url=http%3A%2F%2Fcsnotes.upm.edu.my%2Fkelasmaya%2Fweb.nsf%2Fde8cc2082fc4d31b4825730e002bd111%2Fb32d672041953cb6482575fa0029a573%2F%24FILE%2FARID.ppt&ei=kwKpT8K2N4-HrAe9y4n4AQ&usg=AFQjCNH8mqZ_dva3TYATdjpPU3YyFVQDhg&sig2=zn_1hhJ39SZ5q1tUTIQspw [Accessed 20 Jun 2012]

Mark L (2010) Active Review for Intermediate Designs [Online] Available from http://www.superiorwebdesign.org/CapellaPortfolio/Assignments/TS5353/U09a1ActiveReviewforIntermediateDesign(ARID).ppt. [Accessed 22 Jun 2012]

Kruchten, P., 1995. The “4+1” View Model of Software Architecture. Architectural Blueprints.

Microsoft, 2012. MSDN. [Online] Available at: http://msdn.microsoft.com/en-us/library/ff649643.aspx [Accessed 20 july 2012].

Sommerville, I., 2007. Software Engineering, Eighth Edition. 8th ed. Addison-Wesley Publishers Limited.

Page 54

http://msdn.microsoft.com/en-us/library/ff649643.aspx

http://www.superiorwebdesign.org/CapellaPortfolio/Assignments/TS5353/U09a1ActiveReviewforIntermediateDesign(ARID).ppt

http://www.superiorwebdesign.org/CapellaPortfolio/Assignments/TS5353/U09a1ActiveReviewforIntermediateDesign(ARID).ppt

http://www.google.com.my/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CGIQFjAD&url=http%3A%2F%2Fcsnotes.upm.edu.my%2Fkelasmaya%2Fweb.nsf%2Fde8cc2082fc4d31b4825730e002bd111%2Fb32d672041953cb6482575fa0029a573%2F$FILE%2FARID.ppt&ei=kwKpT8K2N4-HrAe9y4n4AQ&usg=AFQjCNH8mqZ_dva3TYATdjpPU3YyFVQDhg&sig2=zn_1hhJ39SZ5q1tUTIQspw



http://www.sei.cmu.edu/reports/00tn009.pdf


Assignment Marking Criteria Checklist

SAT (CE059-3.5-2)

Students’ Names Students’ ID Student’s Signature

1 Yong Hong Man TP019751

2 Chang Tzyy Haw TP027121

3 How Chee Weng TP019266

Part-A - Individual Marking Criteria (40%)

Student 1- Yong Hong Man:

Criteria Marks awarded Comment

Presentation of Software Architecture – 20 marks

Discussion on Evaluation Criteria – 20 marks

Individual Total

TOTAL (Individual + Group)

Student 2 - Chang Tzyy Haw:




Individual Total


Page 55


Student 3 - How Chee Weng:




Individual Total


Part-B - Group Marking Criteria (60%)

Criteria Marks given Comments

ATAM – 20 marks

ARID – 20 marks

SAAMS – 20 marks

Total

Page 56

Documents

SAT APIIT APU ASSIGNMENT A+ Grade Yong Hong Man