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

Contents
Workload 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 6.2 Nine Step of ARID: ............................................................................................................ 35 Page 2

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 Matrix
Criteria Introduction Individual Component Client-Server Three-Tier Model-Control-View 33% 33% 33% 100% 33% 33% 33% 33% 33% 33% How Chee Weng Chang Tzyy Haw Yong Hong Man
100% 100%
Group Component SAAM ATAM ARID
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

Laptop Computer Desktop Smart Phone
Application Server
Office Database
Mail Database
User Database
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 performing detailed processing. Last but not lease is the data tier which will be the database server. Page 6

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.
Register
Download
Maintain
Member
rent
delete
Admin/ Staff
buy
update
Guest
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
Presentation Application
Register
Database
Respon
Register
confirm
Respon
Verify
Log in
respon
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
Video main system
Web Server Purchase subsystem
Online Chatsubsystem
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 System

The Professional software development team have suggested using the Clientserver model architecture to build this system. The Clientserver model are involved a separate client and server system, and a connecting network by a distributed systems. The Basic form of Clientserver 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 Architecture
First 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 firms bunches is it not necessary to be at a central place. In this firm, high security is high demanded due to there might have unauthorized people access to the product of this firm. Page 12

General Evaluation Criteria for Software Architecture
With 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 13
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 14
Figure 5 Process View
The process view focus on non-functional requirements, such as performance and availability. It addresses the designs concurrency and synchronization aspects of the architecture. For example the procedure of the one function that is undertaken and it wont 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 15

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 chunksprogram 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 16

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: Http Browser Request Controller Interpret Model Result View Generates Results Response
Database
Feature 1: Model-View-Controller architecture
Page 17

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 18

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 19

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.
Login
Purchase & Rent
Download trailer
View
Generate Report Feature 3: Logical diagram
Page 20

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.
Client
Server
Database
View Menu
Request
Response
Send Info
Feature 4: Sequence Diagram
Page 21

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)
Customer
Purchase Order Data (Online) Weekly Sales Report
Staff
Order Submitted Notice Order Rejected Notice
0
Updated Product Data Order Amount
Processed Order
SuperVideo System
branches
Delivery order
Feature 5: Context Diagram
Page 22

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)
Database User
User Server Internet
User Feature 6: Physical Diagram
Page 23

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.
SuperVideo System
Purchase & rent <<uses>> <<uses>> <<uses>> View Member Report <<uses>>
Download trailer <<uses>> <<uses>> Staff <<uses>> <<uses>>
Update catalog
Add new product Visitors
Feature 7: Use case diagram
Page 24

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 25

Input to SAAM evaluation
The 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 26

Output of SAAM evaluation
With 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 27

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 28

Step1- Develop Scenarios
This 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 29

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 30

Step3- Classify/Prioritize scenarios
In 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 31

Step4- Individually evaluate indirect scenarios
After 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 indepth 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 6 Change the programming language of system to Java 7 Change the web server hosting direct The stakeholders 1 Rm10000, 1 month. Direct The stakeholders 1 Rm5000, 3 months indirect The stakeholders and the user 1 Rm2000, One weeks
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 32

Step5- Assess Scenario interaction
When 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 33

Step6- Create overall evaluation
In 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 34

6.0 Question 4: Active Reviews for Intermediate Designs
6.1 Introduction
ARID 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 Reviewers
In this step we had to identify the stakeholders or reviewer of the system. Such as the software engineers, programmers, database administrator, manager. Stakeholders/ Reviewer Software Engineers/ Programmers Task 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 35

Step 2-Prepare design presentation
Designer 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 36

Step 3- Prepare seed scenarios
This 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 meeting
Prepare 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: 1. 2. 3. 4. 5. 7. 8. Name: James Lee Albert Chua Vincent Leong Jennifer Nick Chua Justin Ng Jess Chan Position: Software Engineer Database Administrator Software Engineer Database Administrator Manager Conversion System Developer Conversion System Developer
Page 37

Agenda for the meeting Time 10.00 10.10 Activities Introduction of Meeting Process section -Explain the ARID Process
10.40
Explain the Conversion System Architecture section
11.10 11.30
Question and Answer section Discussion section -Brainstorm scenario
12.00 12.30
Review today meeting section Section End
Step 5- Present ARID method
The 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 Design
Presenter 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 38

Step 7-Brainstorm and prioritize scenarios
In 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 review
This 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 Conclusions
At 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 39

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 40

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 41

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. Customers 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 42

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 43

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 ModelView-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 44

Step 4: Identify Architectural Approaches
Current the SuperVideo system is using Model-View-Controller as architectural. Below is the graphical view of the architecture. Http Browser Request Controller Interpret Model Result View Generates Results Response
Database
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 45

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:
(M,L) Minimize latency between client and server to 150MS (M,L)Deliver product in day Transaction Throughput
Data Latency Performance
(M,L)Update new product Modifiability New product categories (L,M)comment of the product Change COTS
Utility
Availability
Hardware failure
(H,w)Network failure reconnect in <1 mins (H,M)Server restart in <3mins
COTS software failures Security Data integrity
(H,M) Credit card transcation are secure all the time Client database authorizzation work 99% of the time
Data confidentiality
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 46

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 47

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 48
Step 8: Analyze architectural approaches

This 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 result

Step 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 49

References
Paul 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%2Fde8cc2082fc4d31b 4825730e002bd111%2Fb32d672041953cb6482575fa0029a573%2F%24FILE%2FARID.ppt&ei =kwKpT8K2N4HrAe9y4n4AQ&usg=AFQjCNH8mqZ_dva3TYATdjpPU3YyFVQDhg&sig2=zn_1hhJ39SZ5q1 tUTIQspw [Accessed 20 Jun 2012] Mark L (2010) Active Review for Intermediate Designs [Online] Available from http://www.superiorwebdesign.org/CapellaPortfolio/Assignments/TS5353/U09a1ActiveReviewf orIntermediateDesign(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/enus/library/ff649643.aspx [Accessed 20 july 2012]. Sommerville, I., 2007. Software Engineering, Eighth Edition. 8th ed. Addison-Wesley Publishers Limited.
Page 50

Assignment Marking Criteria Checklist SAT (CE059-3.5-2)
Students Names 1 2 3 Yong Hong Man Chang Tzyy Haw How Chee Weng
Students ID TP019751 TP027121 TP019266
Students Signature
Part-A - Individual Marking Criteria (40%)
Student 1- Yong Hong Man: Criteria Presentation of Software Architecture 20 marks Discussion on Evaluation Criteria 20 marks Individual Total TOTAL (Individual + Group) Marks awarded Comment
Student 2 - Chang Tzyy Haw: Criteria Presentation of Software Architecture 20 marks Discussion on Evaluation Criteria 20 marks Individual Total TOTAL (Individual + Group) Marks awarded Comment
Page 51

Student 3 - How Chee Weng: Criteria Presentation of Software Architecture 20 marks Discussion on Evaluation Criteria 20 marks Individual Total TOTAL (Individual + Group) Marks awarded Comment
Part-B - Group Marking Criteria (60%)
Criteria ATAM 20 marks ARID 20 marks SAAMS 20 marks Total
Marks given
Comments
Page 52

SAT APIIT APU ASSIGNMENT A+ Grade Yong Hong Man

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAT APIIT APU ASSIGNMENT A+ Grade Yong Hong Man

Uploaded by

Copyright:

Available Formats

UC2F1110SE SAT GROUP ASSIGNMENT

Chemical E-learning web based education system

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

Group Component SAAM ATAM ARID

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

Graphical view of Architecture

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

Video main system

Web Server Purchase subsystem

UC2F1110SE SAT GROUP ASSIGNMENT

Suggested Software Architecture for the System

Figure 1 Basic form of Client-server system

UC2F1110SE SAT GROUP ASSIGNMENT

Graphical view of the architecture

Figure 2Client Server Architecture Diagram

UC2F1110SE SAT GROUP ASSIGNMENT

Figure 3 Scenarios Diagram

UC2F1110SE SAT GROUP ASSIGNMENT

Figure 4 Logical View

UC2F1110SE SAT GROUP ASSIGNMENT

Figure 5 Process View

Figure 6 Physical View

UC2F1110SE SAT GROUP ASSIGNMENT

Figure 7 Deployment View

UC2F1110SE SAT GROUP ASSIGNMENT

Feature 1: Model-View-Controller architecture

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

Feature 2: 4+1 view with UML and stakeholders

UC2F1110SE SAT GROUP ASSIGNMENT

Purchase & Rent

Generate Report Feature 3: Logical diagram

UC2F1110SE SAT GROUP ASSIGNMENT

Feature 4: Sequence Diagram

UC2F1110SE SAT GROUP ASSIGNMENT

Order Submitted Notice Order Rejected Notice

Feature 5: Context Diagram

UC2F1110SE SAT GROUP ASSIGNMENT

User Server Internet

User Feature 6: Physical Diagram

UC2F1110SE SAT GROUP ASSIGNMENT

Download trailer <<uses>> <<uses>> Staff <<uses>> <<uses>>

Add new product Visitors

Feature 7: Use case diagram

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

UC2F1110SE SAT GROUP ASSIGNMENT

6.2 Nine Step of ARID:

UC2F1110SE SAT GROUP ASSIGNMENT

Figure 8 Context Diagram