1. Architect Presentation POST System K14T01 – Team 02

2. Today’s Presenters Nguyen Dinh Team Leader Ngoc Dinh Team Manager Anh Doan Technical Leader Viet Bui Team Member Trang Vu Team Member Kha Ngo Team Member

3. Table of contents Project Introduction Architecture Drivers Architecture Design The ATAM

4. Project Introduction Business topic 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 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.

5. Architecture Drivers Business and Technical Constraints Business Goal and Context Use Case’s Entity Use Case Diagram and Description Quality Attributes Quality Attribute Scenarios

6. Constraints Business Constrains IDDescription 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 IDDescription POST.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.

7. Goals and Context goal 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.

8. Use Case’s Entity Entity list POST.E.01 Cashier POST.E.02 Administrator POST.E.03 Banking Service POST.E.04 Inventory Manager Entity name: Entity name: CashierEntity 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: Identified use cases: POST.UC.001, POST.UC.002

9. Use Case’s Diagram

10. Quality Attributes ID PriorityDescription POST. QA.01 Performance1 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 Availability1System 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.

11. 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 StimulusCashier scan barcode 2 Source(s) of stimulusCashier 3 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 second 8 Growth scenarioIn busy status, system must archive this scenario 9 Exploratory scenarioSystem 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 1StimulusOne servers die suddenly 2Source(s) of stimulusCashier, Administrator, Inventory Manager 3 Relevant environment condition POST system is running 4Architecture elementsDatabase server system, application server, load balancer 5Architecture decisionsActive redundancy, ping/echo 5System response Performance reduce minor System back to normal in small time period 7Response measure(s) Response time reduce < 2 seconds Downtime < 5 minutes 8Growth scenario One of databases die suddenly, response time still be the same, downtime < 2 minutes 9Exploratory scenarioHalf of servers dies suddenly with slightly effecting system performance

12. Architecture Design Context Diagram Static Perspective Dynamic Perspective Physic Perspective Mapping

13. Context Diagram

14. Static Perspective

15. Dynamic Perspective

16. Sale UI ServletServlet Sale Controller OrderOrder Item facade ItemItem Bill facade Bill detail facade BillBill Bill detail Data base Banking services Request create order Request add item Remove Item Commit order by cash Commit order by Credit card BrowserBrowser

17. Dynamic Perspective

20. Physic Perspective

21. Mapping

22. The ATAM Utility Tree Mapping Decision to QA Sensitivity and Tradeoff points Risks and Non-risks

23. Utility Tree

24. Mapping Scenario :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 and Response Less than one half second Architecture decisions SensitivityTradeoffRiskNon-risk Multi-thread among processes S1T1 N1 Use LAN is 100MBps N2 Strong processor S2 N3 Reasoning 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-thread A 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 second Architecture decisions SensitivityTradeoffRiskNon-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 Scenario :ID05 Scenario: One of databases die suddenly Attributes Availability environment POST system is running Stimulus One of databases die suddenly Response Response time reduce < 2 seconds. Downtime < 5 minutes Architecture decisions SensitivityTradeoffRiskNon-risk Active redundancy T4R1 ping/echo S7 N8 Reasoning 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

25. 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 DescriptionT1 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 authenticati on 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/echoThis 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

26. Risk & Non-Risk Risk name Architecture decision Description DescriptionR1 Active redundancyWhen 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

27. The End Thanks For Your Attendance K14T01 – Team 02