architect presentation post system k14t01 – team 02

27
Architect Presentation POST System K14T01 – Team 0

Upload: earl-hunter

Post on 23-Dec-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Architect Presentation POST System K14T01 – Team 02

Architect Presentation

POST SystemK14T01 – Team 02

Page 2: Architect Presentation POST System K14T01 – Team 02

Today’s Presenters

Nguyen DinhTeam Leader

Ngoc DinhTeam Manager

Anh DoanTechnical Leader

Viet BuiTeam Member

Trang VuTeam Member

Kha NgoTeam Member

Page 3: Architect Presentation POST System K14T01 – Team 02

Table of contents

Project Introduction

Architecture Drivers

Architecture Design

The ATAM

Page 4: Architect Presentation POST System K14T01 – Team 02

Project Introduction

Business topic: Web based application for a cashier to check out the shopping easily and fast.

POST is a computerized system used for managing sale transactions and importing transactions through the sales, handle payments and import item.

POST system is used for a large scale supermarket system. It include a central server system and own server systems for each supermarket. Own server systems connected to central server system to synchronize data and manage information.

Project Vision: This project is developed for manager of a store or series of supermarket that requires a system that can help them sale products and manage inventory, the POST system is business software that is developed in a way meeting the entire customer's needs and being usable.

Page 5: Architect Presentation POST System K14T01 – Team 02

Architecture Drivers

Business and Technical Constraints

Business Goal and Context

Use Case’s Entity

Use Case Diagram and Description

Quality Attributes

Quality Attribute Scenarios

Page 6: Architect Presentation POST System K14T01 – Team 02

Constraints

Business ConstrainsID Description

POST.CON.B.01

System is developed within 6 weeks

POST.CON.B.02

System must be deployed with all functions and required document such as user manual, SRS, SDS…Technical Constrains

ID DescriptionPOST.CON.T.01

System can be run on any different operating systems: Window, linux, unix

POST.CON.T.02

Computer platform: PC, server, mainframe

POST.CON.T.03

Using Java programming language

POST.CON.T.04

Using J2EE/EJB platform

POST.CON.T.05

Using Wed-based system, Java, JDBC, SQL Server Express Edition 2005, Netbeans IDE.

Page 7: Architect Presentation POST System K14T01 – Team 02

Goals and Context

In general, the goal of this system is to increase checkout automation, to support faster, better, and cheaper services and business processes

The POST is a system that helps retail record sales and handles payments. It includes hardware components such as a computer and a bar code scanner, and software to run the system. Cashiers can use product barcode to sale product and product barcode must exist in database.

The purpose of this project is to create a Virtual POST system, Web based POST software can be run on any computer with an internet connection and supported browser, without additional software.

Page 8: Architect Presentation POST System K14T01 – Team 02

Use Case’s Entity

Entity listPOST.E.01 CashierPOST.E.02 AdministratorPOST.E.03 Banking ServicePOST.E.04 Inventory Manager

Entity name: Cashier Entity ID: POST.E.01Description:This is a human entity that has responsible for executing sale items. This entity interacts with system through keyboard, barcode scanner, and some other hardware.

Provides assumptions: Log in Scan item barcode Create order Remove item from order Commit order Input money

Requires assumptions: Item information Total amount money, balance due Connect to web’s service bank to execute payment Print bill

Identified use cases: POST.UC.001, POST.UC.002

Page 9: Architect Presentation POST System K14T01 – Team 02

Use Case’s Diagram

Cashier

POST System

Sale Item

Create Order

«include»

Commit Order

«include»

Commit Bill

«include»

Admin

Cashier

Administrator

Inventory Manager

Authenticate account

Sale itemManage account

Config system

Manage inventory

POST System

Import Item

Manage Sale

Manage Import

Page 10: Architect Presentation POST System K14T01 – Team 02

Quality Attributes

ID Quality Attributes

Priority

Description

POST.QA.01

Performance 1 Quick checkout for customer, fast sales analysis; this is one of the most important qualities which customer needs in system. The specification is described in business context.

POST.QA.02

Availability 1 System must be maintained behavior 24/7 with very small downtime period. This quality is necessary for a distributed market system where just small downtime can lead to a huge lost in business. Therefore, this quality has high priority.

Page 11: Architect Presentation POST System K14T01 – Team 02

ScenariosID01

Raw quality attribute

Performance: Response time (When POST receives bar code system will response less than one half second, it includes returning product information).

1 Stimulus Cashier scan barcode 2 Source(s) of stimulus Cashier3 Relevant

environment condition

Network devices, POST system is running, cashier is working

4 Architecture elements

Bar code scanner, local POST server, and cashier’s computer

5 Architecture decisions

Multi-thread among processes, use LAN is 100MBps, strong processor.

6 System response Information of item, it includes barcode, price, quantity, and name.

7 Response measure(s) Less than one half second8 Growth scenario In busy status, system must archive this scenario9 Exploratory scenario System must handle at least 20 clients at one time in

the best performance which is specific in growth scenario

ID05 Raw quality attribute Availability: one server dies suddenly

1 Stimulus One servers die suddenly

2 Source(s) of stimulus Cashier, Administrator, Inventory Manager

3 Relevant environment condition

POST system is running

4 Architecture elements Database server system, application server, load balancer

5 Architecture decisions Active redundancy, ping/echo

5 System response Performance reduce minorSystem back to normal in small time period

7 Response measure(s) Response time reduce < 2 secondsDowntime < 5 minutes

8 Growth scenario One of databases die suddenly, response time still be the same, downtime < 2 minutes

9 Exploratory scenario Half of servers dies suddenly with slightly effecting system performance

Page 12: Architect Presentation POST System K14T01 – Team 02

Architecture Design

Context Diagram

Static Perspective

Dynamic Perspective

Physic Perspective

Mapping

Page 13: Architect Presentation POST System K14T01 – Team 02

Context Diagram

Adminstrator

Cashier

Inventory manager

Log in

Add accountRemove account

Edit accountView detail account

Remove billView detail bill

Remove import listView detail import list

Log out

View config informationEdit config information

View itemRemove item

Edit itemAdd typeView type

Remove typeEdit type

Add supplierRemove supplier

Edit supplierView list of supplier

Import item

Log in

Log out

Create order

Commit order

Commit bill

Log inLog out

Change password

Change password

View itemRemove item

Edit itemAdd type

Remove typeEdit typeView type

Add supplierRemove supplier

Edit supplier

View list supplier

Change password Check out

POST system

Adminstrator

Cashier

Inventory manager

Log in

Add accountRemove account

Edit accountView detail account

Remove billView detail bill

Remove import listView detail import list

Log out

View config informationEdit config information

View itemRemove item

Edit itemAdd typeView type

Remove typeEdit type

Add supplierRemove supplier

Edit supplierView list of supplier

Import item

Log in

Log out

Create order

Commit order

Commit bill

Log inLog out

Change password

Change password

View itemRemove item

Edit itemAdd type

Remove typeEdit typeView type

Add supplierRemove supplier

Edit supplier

View list supplier

Change password Check out

POST system

Page 14: Architect Presentation POST System K14T01 – Team 02

Static Perspective

Page 15: Architect Presentation POST System K14T01 – Team 02

Dynamic Perspective

Page 16: Architect Presentation POST System K14T01 – Team 02

Persistence LayerSession BeanWeb

Dynamic Perspective

Sale UI

Servlet Sale Controller Order

Item facade

Item

Bill facade

Bill detail facade

Bill

Bill detail

Database

Banking services

Request create orderRequest add itemRemove ItemCommit order by cashCommit order by Credit card

Browser

Page 17: Architect Presentation POST System K14T01 – Team 02

Dynamic Perspective

Head System

Session Bean Persistence LayerWeb

DatabaseSession Facade

Session Facade

Session Facade

Data ManagerServletRequest Upload/Dowload data

Entity Bean

JDBC

Upload/Update data

Timer

JDBC

JDBC

Entities

Entities

Entities

Set/Get data

Set/Get data

Set/Get data

Branch System

Session Bean Persistence Layer

DatabaseSession Facade

Session Facade

Session Facade

Data Manager

Entity Bean

JDBC

JDBC

JDBC

Entities

Entities

Entities

Set/Get data

Set/Get data

Set/Get data

Web

Servlet

Upload/Update Data

Upload/Download data

Return data

Return data

Data

Upload/Download data

Request Upload/Dowload dataTimer

Page 18: Architect Presentation POST System K14T01 – Team 02

Dynamic Perspective

Head System

Session Bean Persistence LayerWeb

DatabaseSession Facade

Session Facade

Session Facade

Data ManagerServletRequest Upload/Dowload data

Entity Bean

JDBC

Upload/Update data

Timer

JDBC

JDBC

Entities

Entities

Entities

Set/Get data

Set/Get data

Set/Get data

Branch System

Session Bean Persistence Layer

DatabaseSession Facade

Session Facade

Session Facade

Data Manager

Entity Bean

JDBC

JDBC

JDBC

Entities

Entities

Entities

Set/Get data

Set/Get data

Set/Get data

Web

Servlet

Upload/Update Data

Upload/Download data

Return data

Return data

Data

Upload/Download data

Request Upload/Dowload dataTimer

Page 19: Architect Presentation POST System K14T01 – Team 02

Dynamic Perspective

Head System

Session Bean Persistence LayerWeb

DatabaseSession Facade

Session Facade

Session Facade

Data ManagerServletRequest Upload/Dowload data

Entity Bean

JDBC

Upload/Update data

Timer

JDBC

JDBC

Entities

Entities

Entities

Set/Get data

Set/Get data

Set/Get data

Branch System

Session Bean Persistence Layer

DatabaseSession Facade

Session Facade

Session Facade

Data Manager

Entity Bean

JDBC

JDBC

JDBC

Entities

Entities

Entities

Set/Get data

Set/Get data

Set/Get data

Web

Servlet

Upload/Update Data

Upload/Download data

Return data

Return data

Data

Upload/Download data

Request Upload/Dowload dataTimer

Page 20: Architect Presentation POST System K14T01 – Team 02

Physic Perspective

System

Client

Client

Firewall

Load balancer

POST Application serverLAN 1(port 80)

Database server

HTTPS

POST Application server

Database server

LAN 2(port 5530)

Firewall

Client

GlassfishWeb server

GlassfishWeb server

Ping/echo

Ping/echo

Port 80

Port 80

Center system

System 1

Client

Client

Firewall

Load balancer

POST Application serverLAN 1(port 80)

Database server

HTTPS

POST Application server

Database server

LAN 2(port 5530)

Database server

Database server

Internet

Firewall

Client

GlassfishWeb server

GlassfishWeb server

Port 80

Port 80

Firewall

HTTPS

Load balancer

POST Application serverPOST Application server

GlassfishWeb server GlassfishWeb server

LAN 1(port 80)

Firewall

HTTPS

LAN 1(port 80)

LAN 1(port 80)

LAN 1(port 80)

Firewall

LAN 2(port 5530)

Banking System

SOAP

System 2

Client

Client

Firewall

Load balancer

POST Application serverLAN 1(port 80)

Database server

HTTPS

POST Application server

Database server

LAN 2(port 5530)

Firewall

Client

GlassfishWeb server

GlassfishWeb server

Port 80

Port 80

Firewall

HTTPS

Page 21: Architect Presentation POST System K14T01 – Team 02

Mapping

Page 22: Architect Presentation POST System K14T01 – Team 02

The ATAM

Utility Tree

Mapping Decision to QA

Sensitivity and Tradeoff points

Risks and Non-risks

Page 23: Architect Presentation POST System K14T01 – Team 02

Utility

Performance

Availability

Restrict access to page

(H,M)

Respone time

(H,M)

Security

Authorize users Separate authority for user (H,L)

Using firewall among tiers

(H,H)

System confirm bar code and calculate total price of item (Less than one second)

Time to server response a request from client and return results(Less than half of a second)

Respone time(One of databases die suddenly)

Performance reduce minorSystem back to normal in small time period(Response time reduce < 2 seconds Downtime < 5 minutes)

(H,H)

Utility Tree

H-High, M-Medium, L-Low(Importance,Achivability)

Modifibility Add new clientCost for adding is minor, client and change code

Usability

Training cashier to use POST system

Training time < 2 days

(L,M)

(L,L)

Show pleasing messages (L,L)

Less than one second

Correctness Two clients commit same item at the same time

Amount of that item is reduced correctly in database(100%)

(H,M)

Scalability 30 client connect at the same timeSystem still working(Maximum 2 seconds)

(M,M)

Utility

Page 24: Architect Presentation POST System K14T01 – Team 02

MappingScenario :ID01 Scenario: Response time (When POST receives bar

code from bar code scanner, system will confirm and calculate price in less than one half second)

Attributes Performance environment Network devices and POST system is running

Stimulus Bar code is scanned by scanner andResponse Less than one half second

Architecture decisions

Sensitivity Tradeoff Risk Non-risk

Multi-thread among processes

S1 T1   N1

Use LAN is 100MBps       N2Strong processor S2     N3Reasoning Multi-thread in processor: Using multi-thread can speed up

processing rate from 1.5 to 1.8 than single-thread. In addition, using multi-thread can avoid the problem of waiting for long task in single-threadA high-speed internet can greatly improve performance of a web-based system.With a strong processor, server may not be stuck if too much information has received

Scenario :ID02 Scenario: Response time (Time for servers to response a regular request from client must less than one second)

Attributes Performance environment POST system is running

Stimulus Commit order, change configuration, add item …

Response Less than a secondArchitecture decisions

Sensitivity

Tradeoff Risk Non-risk

Hardware concurrency (load balancer)

S3     N4

Reasoning Introduce concurrency (load balancing): a load balancing can help system reduce waiting time by deliver request to appropriate component. Without using load balancing, system may be stuck with too many requests at the same time.

Architecture diagram Load balancer

POST Application serverLAN 1(port 80)

POST Application server

GlassfishWeb server

GlassfishWeb server

Port 80

Port 80

Scenario :ID05

Scenario: One of databases die suddenly

Attributes Availabilityenvironment

POST system is running

Stimulus One of databases die suddenly

Response Response time reduce < 2 seconds. Downtime < 5 minutes

Architecture decisions

Sensitivity Tradeoff Risk Non-risk

Active redundancy

  T4 R1  

ping/echo S7   N8Reasoning If a server dies, the other server still maintain operation of system. So we

use active redundancy to ensure availability, and also increase performance for system, because normal, at the same time has two server is operate. To know server alive or die, load balancer will redirect requests to another server. "Ping/echo" fault detectors can be organized in a hierarchy, in which a lowest-level detector pings the software processes with which it shares a processor, and the higher-level fault detectors ping lower-level ones. And it uses less communications bandwidth

Architecture diagram

Load balancer

POST Application serverLAN 1(port 80)

POST Application server

GlassfishWeb server

GlassfishWeb server

Ping/echo

Ping/echo

Port 80

Port 80

Page 25: Architect Presentation POST System K14T01 – Team 02

Sensitivity & Trade-off

Sensitivity Points

Architecture decision

S1 Multi-thread among processes

S2 Strong processor

S3 Hardware concurrency (load balancer)

S4 Use firewall

S5 Use authorize and authentication user

S6 Using Encrypt

S7 ping/echo

S8 Use EJB

Trade-off

Points

Architecture decision

Description

T1 Multi-thread among processes

This is a trade-off between performance and security. At performance, we use multi-thread among processes; this tactic will help increase performance. Therefore, more connections will be established and make the system difficult to ensure security.

T2 Use authorize and authentication user

This is a trade-off between security and performance. At security, we use firewall to increase security. Therefore, it will check any access and reduce performance

T3 Using Encrypt

This is trade-off between security and performance. At quality attribute security, we have architecture decision is using encryption. This architecture decision increases security, so it will reduce performance.

T4 Active redundancy

This is a trade-off between availability and modifiability, security. We use active redundancy to increase availability, and active redundancy will make more connections and component so that it affect modifiability and security

T5 ping/echo This is a trade-off between availability and performance. At availability, we use ping/echo to increase availability, so it cost our system a little time to process information and reduce performance

Page 26: Architect Presentation POST System K14T01 – Team 02

Risk & Non-Risk

Risk name

Architecture decision

Description

R1 Active redundancy When one server dies, all connections will be redirected to another server. Therefore, another server may be overloaded

Non-risk name Architecture decision

N1 Multi-thread among processes

N2 Use LAN is 100MBps

N3 Strong processor

N4 Hardware concurrency (load balancer)

N5 Use firewall

N6 Use authorize and authentication user

N7 Using Encrypt

N8 ping/echo

N9 Use EJB

Page 27: Architect Presentation POST System K14T01 – Team 02

The End

Thanks

For

Your

Attendance

K14T01 – Team 02