Capstone Project Guide Line
User Manual: Pdf
Open the PDF directly: View PDF 
.
Page Count: 47
| Download | |
| Open PDF In Browser | View PDF |
MINISTRY TRAINING OF EDUCATION FPT UNIVERSITY Capstone Project Document Tên đề tài Nhóm số Group members Tên các thành viên trong nhóm – Mã số sinh viên Supervisor Giảng viên hướng dẫn Ext. Supervisor N/A Capstone Project Mã đề tài code -Ho Chi Minh City, Ngày bắt đầu làm- PAGE \* MERGEFORMAT 1 AND This page is intentionally left blank PAGE \* MERGEFORMAT 1 Table of Contents Table of Contents ................................................................................................................................3 List of Tables........................................................................................................................................4 Definitions, Acronyms, and Abbreviations..........................................................................................6 A. Report No. 1 Introduction ...........................................................................................................7 1. Project Information .................................................................................................................7 2. Introduction ............................................................................................................................7 3. Current Situation .....................................................................................................................7 4. Problem Definition ..................................................................................................................7 5. Proposed Solution ...................................................................................................................8 6. 7. 5.1 Feature functions ............................................................................................................8 5.2 Advantages and disadvantages .......................................................................................8 Functional Requirements ........................................................................................................9 6.1 Name Card Management ................................................. Error! Bookmark not defined. 6.2 Event ................................................................................ Error! Bookmark not defined. 6.3 Searching .......................................................................... Error! Bookmark not defined. 6.4 Suggestion ........................................................................ Error! Bookmark not defined. 6.5 User Management ........................................................... Error! Bookmark not defined. Role and Responsibility ...........................................................................................................9 PAGE \* MERGEFORMAT 1 List of Tables Table 1: Roles and Responsibilities .....................................................................................................9 PAGE \* MERGEFORMAT 1 List of Figures Figure 1: Modified Waterfall Development Model.............................. Error! Bookmark not defined. PAGE \* MERGEFORMAT 1 Definitions, Acronyms, and Abbreviations Miêu tả từ viết tắt hay các term dùng trong tài liệu thuyết minh bên dưới Name Definition Từ viết tắt Định nghĩa PAGE \* MERGEFORMAT 1 A. Report No. 1 Introduction 1. Project Information - Project name:Project Code: Product Type: Start Date: End Date: 2. Introduction Ví dụ: In this document, we introduce a solution for motorbike insurance company. Current insurance company systems have some problems like delayed in renew contracts for customer or inconvenient in checking insurance card validation process. Based on our researches and analysis, we proposed a solution for insurance company in Vietnam and other developed countries. We build a system, which help the insurance companies to solve current problems. In the process of analysis, we believe the NFC cards is capable to resolve the problem by using NFC card to save information about insurance contract. NFC cards are convenient to manage the contract information and checking, validating process. Beside of that we also provide an information system to manage NFC cards so that insurance companies will manage the contracts easier. This document also describes our working process in 4 months includes our perspective in the system, component designs and detailed core workflows. We hope the system and our solution will help resolve the problems from insurance companies in Vietnam and other developed countries. 3. Current Situation Ví dụ When participating in traffic, vehicle owners are required to have compulsory insurance (according to Article 6, Decree on compulsory insurance for civil liability of motor vehicle owners, Decree No. 103/2008/ND-CP by Vietnam Government). Therefore, vehicle owners buy insurance from insurance companies or its agents. They pay insurance premium by cash or in online website and receive an insurance certificate with a term of one year, the term can be shorter in some specific situation. When their insurance out of date, they must buy a new insurance, old certificate will be useless. Traffic police will read insurance certificate to check traffic participants. 4. Problem Definition <Định nghĩa vấn đề: nêu ra các khó khăn, khuyết điểm, hạn chế ở hệ thống hiện tại> PAGE \* MERGEFORMAT 1 Ví dụ Below are disadvantages of current situation: Forget insurance’s expired date: Vehicle owners usually keeps their insurance certificate in wallet or somewhere on their vehicle. However, except in cases of necessity, people are not often check their insurance so they could forget its expired date. An expired insurance is not good while it be revealed by traffic officers and could get worse in case of traffic accident. Hard for traffic officers to check and verify insurance: .... ... 5. Proposed Solution Ví dụ: Our proposed solution is to build an insurance NFC card system named “MIC system” to resolve the current situations and compatible with current laws, we also design the system to be scalable so we can deploy this system to a multiple insurance services company in future plan. MIC system includes a web application and two mobile applications with following functions: 5.1 Feature functions Ví dụ Web application: o Register insurance: user can register a new insurance card with on website using online payment. A staff will contact the user to create contract and sends an insurance NFC card to him/her. If users already have a NFC card, they can use the website to renew current contract. o Check card information: ... o ... Insurance card printer (mobile app): o Simulating NFC card printer: staff can print NFC card.... ... 5.2 Advantages and disadvantages - Advantages: Ví dụ PAGE \* MERGEFORMAT 1 - o The interaction between the insured one and the insurance company: the insured one and the company now are easier to communicate through the website when each person has an account. o ... Disadvantages: Ví dụ o Currently not consistent with the law of Vietnam about insurance card issues. o ... - Notes: Có thể phân tích điểm vượt trội hay khuyết điểm của giải pháp sẽ được thực hiện so với hệ thống đang có sẵn 6. Functional Requirements Function requirements of the system are listed as below: Ví dụ User component: o New contract request o ... Staff component o Create new contracts o ... ... 7. Role and Responsibility Liệt kê danh sách và vai trò theo mô hình phần mềm mà nhóm sẽ lựa chọn trong phần tiếp theo. Các thành phần nên đặc tả vào bảng để dễ nhìn Ví dụ No 1 2 3 4 5 Full Name Role Position Kiều Trọng Khánh Đinh Quang Trung Nguyễn Hữu Phúc Phùng Quang Minh Trí Nguyễn Chí Kha Project Manager Developer Developer Developer Developer Supervisor Leader Member Member Member Contact khanhkt@fpt.edu.vn trungdqse60994@fpt.edu.vn phucnhse60749@fpt.edu.vn tripqmse60746@fpt.edu.vn khanc60351@fpt.edu.vn Table 1: Roles and Responsibilities PAGE \* MERGEFORMAT 1 B. Report No.2 Software Project Management Plan 1. Problem Definition 1.1 Name of this Capstone Project - Ví dụ Official name: Insurance Card Vietnamese name: Thẻ bảo hiểm Abbreviation: MIC 1.2 Problem Abstract Ví dụ As current in Viet Nam customer use Motor Insurance Certificate Paper when they get problems with their motor. Using the Motor Insurance Certificate Paper is inconvenient, for example, it can be wet or to insert or update the information in to insurance certificate paper is complicate. So we use the NFC card we call it is insurance card to handle it. Insurance company supplies the NFC card when the customer buy insurance. The card contains the information of customer, if the customer joins with many insurance service they just use only one card. We provide a software to check the validation of card, the expired date of card and insurance services that customer joined. We also provide other advantages that can help save time and costs in some process of company. For example, the software can automatic extend the insurance service, update the information about accidents of motor. In addition, we also provide a system software to manage the information of customer via some insurance card we bought, this software will deploy at insurance company 1.3 Project Overview 1.3.1 Current Situation - Ví dụ Below are the problems encountered in this project: Security: currently, there is few possible problems encountered with NFC tags, as NFC tags can be counterfeited, attacked during data transmission caused data loss, data corruption. PAGE \* MERGEFORMAT 1 Server crash: all the needed data is stored in the server. So if server crash, all the devices cannot get card information. Absence of team members: team members can get sick or unexpected problems. Currently not consistent with the law of Vietnam about insurance card issues. ... 1.3.2 The Proposed System Ví dụ According to the technology researches, we found out that the NFC technology is very capable of resolve the current situations in insurance companies. We can use a feature of NFC tag to resolve the security problem from NFC card. The basic idea is to use a NFC tag (or NFC “card”) which contains a unique card ID as an insurance card instead of paper card currently. We also build a high available web server to maintain the main system to work 24/7 to make sure that if mobile applications need access to the information there will be always available. We assign responsibility in vertical to make sure if any member in this problem cannot continue to work in our team there will be the least harmful to the project processes. To resolve problem from Vietnam laws of insurance for motorbike, we support the insurance companies to propose new law sections about using technology devices to work with insurance certificate paper to make our system work legally in current situation. Our system includes three main subsystems: an online website for company’s staffs, a mobile application for police officers and a mobile application to simulate the card printer 1.3.2.1 Web Site - Ví dụ Website is a common communication portal for insurance company’s staffs and users (customers). Website provide following features: For users (customers): o Users can register new insurance card with online payment. o ... For staffs: o ... Beside above, website system also provides an API interface for two mobile applications to retrieve, update data from mobile applications. 1.3.2.2 Mobile Application - PAGE \* MERGEFORMAT 1 Ví dụ This is a simulating application to simulate the work of Card Printer. In reality, the company who deploy this system need to have a NFC Card Printer to write information about the insurance company and customer information into an NFC card. However, our system currently only support this as a simulating application. This application is used by company’s staffs and do followings: Retrieves insurance contract information and write data to a physical NFC card. ... ... 1.3.3 Boundaries of the System Ví dụ This section supposes that the government laws in local area supports the method of using NFC cards as insurance cards, and accept NFC insurance cards are legal. Every company who has Information System infrastructure can deploy this system. Companies who deployed this system has to equip enough devices for the system to run, includes: o Computer system with internet connection. o ... 1.3.4 Future Plans Ví dụ Current system only can deploy to a company which provides single service: motor insurance card, we call this is the Isolated Single Service Model. We design the system to make it easy to scale to 2 bigger models: Isolated Multiple Service Model: system can be deployed to one company which provide multiple insurance services such as motor insurance, health insurance, assets insurance… Distributed Multiple Service Model:..... ... 1.3.5 Development Environment 1.3.5.1 Hardware requirements PAGE \* MERGEFORMAT 1 Ví dụ: Windows Internet Connection Operating System Computer Processor For server Minimum Requirements Cable, Wi-Fi (4 Mbps) Window Server 2008 Intel® Xeon ® 1.4GHz Computer Memory 1GB RAM Recommended Cable, Wi-Fi (8 Mbps) Window Server 2008 Intel® Xeon ® Quad Core (12M Cache, 2.50 GHz) 2GB or more Table 2: Hardware Requirement for Server ... 1.3.5.2 Software requirements Mô tả các yêu cầu phần mềm mà nhóm sẽ áp dụng trong phát triển sản phẩm. Nên mô tả dưới dạng bảng biểu Ví dụ: Software Operating system Environment Modeling tool IDE DBMS Source control Web browser Name / Version Window Server 2008 Java EE 6 Microsoft Visio 2013 Netbeans 7.2.1, Intellij IDEA 14.1 MySQL 5.6 TortoiseSVN 1.8.11 Chrome 42 or above Description Operating system and platform for development Specification for developing web application Used to implement website and web service Programming tools Used to create & manage the database for system Used for source control Testing browser 2. Project organization 2.1 Software Process Model Ví dụ This project is developed under waterfall model. We apply customized waterfall model to capable with current situation in our team. We choose this model because the following reasons: Based on researches and clarify Vietnam laws of insurance for motorbike and current system in insurance companies, the requirements of this project are stable, clear, fixed and well understood by all team members. This project use NFC technology, ... ... PAGE \* MERGEFORMAT 1 Figure 1: Waterfall model Reference: Page 30, chapter 2, Software process model, SOFTWARE ENGINEERING 9th Edition, by Ian Sommerville. 2.2 Roles and responsibilities Ví dụ No 1 Full name Kiều Trọng Khánh Responsibilities Specify user requirement Control the development process Give out technique and business analysis support Trần Nguyễn Đăng Team Leader, BA, Managing process Khoa DEV, Tester Designing database Clarifying requirements Prepare documents GUI Design Create test plan Coding Testing Table 3: Roles and Responsibilities Details 2 ... Role in Group Project manager 2.3 Tools and Techniques Ví dụ Tool / Technique Frontend Backend ... Name / version HTML, CSS, JavaScript, jQuery, Bootstrap JavaEE, Servlet, JSP, Hibernate PAGE \* MERGEFORMAT 1 3. Project Management Plan 3.1 Software development life cycle Ví dụ Phase Description Deliverables Requirement Analysis - Collect requirements from customer. -Identify and clarify requirements for the system in general. - Architecture design for the system - Detail design using top-down break down - Choose Architecture style -Introduction of proposed system. -Software requirement specification. -Project Task Plan. - Prototypes - Software 20 manDesign Document days - Base code structure - Technology notes Design Resource needed 20 mandays Dependencies and Constrains N/A Depend on “Requirement Analysis” Risks - Missing requirement - Unclear scope of project - Lack of member share of understand - Lack of experience. - Not fulfil requirement. .... Table 4: Software Development Life Cycle Detail 3.2 Phase Detail Ví dụ 3.2.1 Phase 1: Requirement Analysis Task 1. Collect requirements 2. Identify and clarify main functions. ... Description Find which systems currently provide similar service, their strengths and weakness. Define which main functions system should provide. Table 5: Phase 1: Requirement Analysis PAGE \* MERGEFORMAT 1 Author KhoaTND, HuyDN, TanNH KhoaTND, HuyDN, TanNH 3.3All Meeting Minutes 4. Coding Convention PAGE \* MERGEFORMAT 1 C. Report No. 3 Software Requirement Specification 1. User Requirement Specification Ví dụ 1.1 Guest Requirement Guest is a person who doesn’t have access to the system. Guest can use some functions in the system. To use all functions, guest must login. These are some functions guest can use: Register. Login. ... 1.2 Member Requirement ... 1.3 ... 2. System Requirement Specification 2.1 External Interface Requirement 2.1.1 User Interface Ví dụ General requirement for graphics user interface is the GUI should be simple, clear, intuitive, and reminiscent. The interface design is an iterate process includes: design, sketching, prototyping, user assessment. Some design principles will be taken into consideration: o UI for businesss web applications Janko Jovanovic [Ref: http://www.smashingmagazine.com/2010/02/25/designing-user-interfaces-forbusiness-web-applications/] o Ten principles of effective web design – Vitaly Friedman [Ref: http://www.smashingmagazine.com/2008/01/31/10-principles-of-effective-webdesign/] o Principles of mobile interface design – Jonathan Stark [Ref: http://www.oreilly.com/pub/e/2144] 2.1.2 Hardware Interface Ví dụ Smartphone with NFC support. 2.1.3 Software Interface Ví dụ PAGE \* MERGEFORMAT 1 Web application: work with Firefox (v30 or above), Chromes (v14 or above), Internet Explorer (v10 or above) browse. Mobile application: Android operating system (v 4.0 or above). 2.1.4 Communication Protocol Ví dụ Use HTTP protocol 1.1 for communication between the web browser and the web server. 2.2 System Overview Use Case Ví dụ Thông tin mô tả về đặc tả UML tham khảo tại http://www.omg.org/spec/UML/2.0/ Chú ý - Các quan hệ giữa các use case và khi dùng extend phải ghi rõ và condition - Overview usercase phải thể hiện ràng buộc giữa các usecase trong hệ thống, tuyệt đối không được liệt kê usecase - Nên sử dụng abstract usecase với nhóm chức năng có liên quan. Không nên sử dụng dạng abstract usecase chỉ có một usecase, không sử dụng dạng abstract usecase có chứa thành phần abstract usecase - Khi mô tả usecase nên chú ý tập trung chức năng, view là các thành phần phụ trợ (có thể nói là extend) không phải là chức năng chính của hệ thống - Cần phân biệt rõ usecase là chức năng, qui trình. Usecase không phải là màn hình, hay các bước - step - trong quá trình xử lý Ví dụ PAGE \* MERGEFORMAT 1 PAGE \* MERGEFORMAT 1 Figure 2: System Overview Use Case 2.3 List of Use Case <Đặc tả chi tiêt Use case theo từng role> Ví dụ 2.3.1 Overview Use Case Figure 3: Overview Use Case Ví dụ 2.3.1.1 Register Use Case Diagram Figure 4: Register Use Case Specification PAGE \* MERGEFORMAT 1 GuideLine: Đây là giai đoạn lấy requirement nên các mô tả phải được diễn đạt theo ngôn ngữ của khách hàng, không phải là nơi mô tả màn hình giao diện khi ứng dụng đã hoàn tất. Ngoài ra, đây chính là nơi thể hiện rõ vai trò lấy requirement với phương pháp ethnography - observate để chuẩn bị thông tin cho thiết kế và thực hiện sản phẩm. Các nội dung trong phần này chính là phần thông tin để hình thành nên các thực thể trong conceptual diagram USE CASE – Use Case No. Đánh số UC Use Case Version Use Case Name Tên UC Author Người thiết kế, hiện thực Date Ngày viết Priority 2.0 Mức độ quan trọng trong dự án. Core flow thì đánh là High và giảm dần đến Normal Actor: - Summary: - Goal: - Triggers: - Preconditions: - - Ví dụ: để cancel một hóa đơn thì precondition là o User phải là một customer o Hóa đơn vẫn đang trong tình trạng chưa hết thời hạn hủy của hệ thống là 3 ngày Post Conditions: - < Trạng thái sau khi tiến hành bắt buộc phải có 2 trạng thái cho success và fail. Vì vậy khi ghi phải có đủ và phần fail bắt buộc xuất hiện trong exception scenario> - Success: Khi thành công thì tình trạng hệ thống thế nào đối với hệ thống và đối với người dùng - Fail: Khi có lỗi xảy ra thì hệ thống sẽ xử lý thế nào để đảm bảo usability cho người dùng và toàn vẹn dữ liệu cho hệ thống Main Success Scenario: Step Actor Action System Response 1 2 Alternative Scenario: No Actor Action System Response 1 Exceptions: Gồm các tình huống xử lý ngoại lệ cũng như xử lý các exception do người dùng gây ra khi nhập liệu No Actor Action System Response Relationships: Mối quan hệ với các Use case khác nếu có trong quá trình xử lý, tuy nhiên nó không phải là abstract usecase Business Rules: - Thành phần mô tả các yêu cầu về mặt nghiệp vụ của use case. - Tất cả các giả định về nghiệp vụ nếu có phải được ghi vào - Chú ý tới sự chuyển đổi về trạng thái của dữ liệu cũng phải được ghi tại đây - Các định nghĩa cũng cần làm rõ (sản phẩm nổi bật, sản phẩm sắp có là sản phẩm thế nào trong hệ thống) - Các ràng buộc dữ liệu dưới hệ thống, các rule liên quan đến toàn vẹn dữ liệu - Các qui trình, activities, quá trình chuyển đổi trạng thái của hệ thống Ví dụ USE CASE – WG01 Use Case No. WG01 Use Case Version Use Case Name Login Author TrungDQ Date 27/05/2015 Priority Actor: - Guest Summary: - This use case allows guest to log in the system. Goal: - Guest can log in the system. Triggers: - Guest sends the login command. Preconditions: - N/A Post Conditions: PAGE \* MERGEFORMAT 1 2.0 Normal - Success: Guest login the system. - Fail: Show error message. Main Success Scenario: Step Actor Action 1 Guest goes to login view. 2 3 Guest inputs information. Guest sends command to login to system Alternative Scenario: Step Actor Action 1 Guest enter wrong identity information. Exceptions: Step Actor Action 1 System Response System requires identity information from Guest: - Email or customer code: free text input - Password: free text input Guest will login system with their specific role [Alternative 1] [Exception 1] System Response Wrong identity information, System shows error message. System Response System show message the "System is busy" when the internet is lost Relationships: N/A Business Rules: - Password are encrypted before being sent to server. - After login to system, guest will be redirected to specific view based on their role on the system: staff or customer. o If role is “Customer”, the system will display to Customer view. o If role is “Staff”, the system will display to Staff Dashboard view. Ví dụ Create new contract request Figure 5 Create new contract request USE CASE – WG02 Use Case No. Use Case Name Author Date Actor: - Guest WG02 Use Case Version Create new contract request TrungDQ 27/05/2015 Priority PAGE \* MERGEFORMAT 1 2.0 Normal Summary: - This use case allows guest to create new contract request. Goal: - Guest can create new contract request. Triggers: - Guest sends command to create contract request. Preconditions: - N/A Post Conditions: - Success: New account and new contract will be created for guest. - Fail: Show error message. Main Success Scenario: Step Actor Action System Response 1 Guest goes to new System requires information from guest: contract view. Personal information - Name: free text input, required, length 3 – 80. - Address: free text input, required, length 3 – 250. - Email: free text input, required, length 3 – 250. - Phone number: free text input, required, length 8 – 15. - Personal ID: free text input, length 8 – 15. Contract information (all information below are required) - Contract’s type: select one of the options. - Start date: date time input, required. - Contract term: text - Contract’s fee: text Vehicle information - Plate: free text input, required, length 4 – 15. - Brand: free text input, required, length 2 – 20. - Model code: free text input, length 2 – 20. - Vehicle type: free text input, length 2 – 20. - Color: free text input, length 2 – 20. - Engine: free text input, required, length 2 – 20. - Chassis: free text input, required, length 2 – 20. - Capacity: free text input, required, length 2 – 20. - Year of manufacture: number text input, value from 1900 to current year. - Weight: free text input, value from 1 – 1000, unit: kilogram - Seat capacity: free text input, value from 1 – 100. Security question - Answer: free text input, required, length 1 10 2 Guest inputs information. 3 Guest sends command System validate information, display contract details to create new contract and request for confirmation. request. [Exception 1, 2, 3] 4 Guest sends command Add new account and new contract information to the to create new contract system. Show successful message and ask user to request. process payment. 5 Guest sends command Display new view let user select one of following PAGE \* MERGEFORMAT 1 to process payment 6 7 If user chooses PayPal gateway and sends confirm command. [Alternative 1] User process the PayPal payment payment gateways: - PayPal payment gateway. - Direct payment. And show guest the fee: Contract’s fee: text. Forward to PayPal payment view to process the payment. If payment succeed: Show message created successful. [Exception 4] Alternative Scenario: No Actor Action 1 If user chooses direct payment method Exceptions: No Actor Action 1 Guest sends command to create new contract request 2 Guest’s email is existed in the system 3 Guest’s vehicle plate is existed in the system 4 If payment failed System Response Show company address map. System Response System shows error message to ask user input missing required fields. Show message to notify guest that their email is existed in the system. Show message to notify guest that their vehicle is existed in the system. Show message to notify user that payment failed and the renew request has been aborted. Relationships: Payment Business Rules: - New customer account and new contract will be created in the system with inputted information. - The initial status of contract will be set to “Pending”. - When customer completed payment process: + if the contract’s start date has come, contract’s status would change from “Pending” to “No Card”. + If start date is not come yet, the contract status is not changed. - Staff will receive a notification about new contract request, they verify contract’s information and issue a card for this contract, in this case, contract’s status would change from “No Card” to “Ready”. - System must ensure has no duplicate customer or vehicle. - An email contains customer code and password will be sent to user, user can use this information to login to the system later. - Start date must not be earlier than the current date. - Contract term is specified by the system. - Contract types are loaded from system, contract type can be managed by system administrator. - Contract price would be calculated from contract type and contract term. Table 6 Use case WG02 - Create new contract request Ví dụ PAGE \* MERGEFORMAT 1 Cancel contract Figure 6 Cancel contract USE CASE – WC03 Use Case No. WC03 2.0 Use Case Version Use Case Name Cancel contract Author TriPQM Date 27/05/2015 High Priority Actor: - Customer. Summary: - This use case helps user cancel their contract. Goal: - Customer can cancel the contract. Triggers: - Customer sends cancel contract request. Preconditions: - User must login into the system with role Customer. - User’s contract has not expired. - Customer's contract status must not be “Expired”, "Cancelled" or “Request cancel”. Post Conditions: - Success: Send to the staff the cancel contract request. - Fail: Show error message. Main Success Scenario: Step Actor Action System Response 1 User goes to cancel contract Display new view require user input some view. information: - Reason to cancel the contract: can be optional selected from these values: o “Xe cơ giới bị thu hồi đăng ký và biển số theo quy định của pháp luật” o “Xe cơ giới hết niên hạn sử dụng theo quy định của pháp luật” o “Xe cơ giới bị mất được cơ quan công an xác nhận” o “Xe cơ giới hỏng không sử dụng được hoặc bị phá huỷ do tai nạn giao thông được cơ quan công an xác nhận” o Other reason: free text input, required, length 1-250. 2 User inputs information 3 User sends cancel contract - Change contract status. request command. - Send request to the Staff. [Exception 1] Alternative Scenario: N/A PAGE \* MERGEFORMAT 1 Exceptions: No 1 Actor Action System Response If user didn't check any reason Show message to notify user that they have to to cancel contract choose the reason for cancel contract. Relationships: N/A Business Rules: - Cancel contract request will be sent to the system with inputted information. - System update status of the contract from “Pending”, “No Card” or “Ready” to “Request cancel”. - A notification will be sent to staff after the process is completed. Table 7 Use case WC03 - Cancel contract Ví dụ System Auto parse System Figure 7: Auto parse use case diagram Use Case Specification USE CASE – ARB08 ARB08 2.0 Use Case No. Use Case Version Auto parse Use Case Name Pham Nguyen Bich Hien Author 30/05/2014 Normal Date Priority Actor: - System. Summary: - System can parse resource automatically from many websites at specified time. Goal: - Get resource from many websites. Triggers: - The time hits configured time. Preconditions: - Parse time has been configured. Post Conditions: - Success: New data is inserted to storage. Log file is generated. - Fail: Nothing is changed in the storage. Log file is generated. Main Success Scenario: Step Actor Action System Response 1 Server checks the current time. If it hits configured time, parse process starts. Send request to the parsed link. Fetch data from the response based on the inputted XPaths. PAGE \* MERGEFORMAT 1 Validate data [Exception 1]. If data is valid, insert to storage [Alternative 1]. Generate log file. Alternative Scenario: Step Actor Action 1 Server checks the current time. If it hits configured time, parse process starts. System Response If fetched link resource is already in the storage, update its information. Generate log file. Exceptions: No Actor Action System Response 1 Data is invalid. Generate log file. Relationships: N/A Business Rules: - If link resource exists in storage, do nothing. - If link resource is not active, do nothing. - Log file structure: ARB LOG FILE Tạo file lúc: {Created date}, {Created time} STT Link Thời gian parse Dạng dữ liệu Tổng số sách nhận được Insert thành công Insert thất bại Tổng thời gian parse dạng {Data type}: {Elapsed time} Tổng thời gian parse: {Total elapsed time} Tổng sản phẩm parse được: {Total parsed books} Table 8: Auto parse use case specification table 3. Software System Attribute 3.1 Usability 3.2 Reliability 3.3 Availability 3.4 Security 3.5 Maintainability PAGE \* MERGEFORMAT 1 3.6 Portability 3.7 Performance ….. 4. Conceptual Diagram Chú ý Chỉ sử dụng một tập kí hiệu và cần reference đến địa chỉ mô tả tập kí hiệu để sử dụng cho chính xác Các Diagram cần lớn rõ ràng, phải dàn trang cho phù hợp và nên dùng trang A3 để in Các thành phần trong diagram phải được thể hiện thông qua dictionary Data Dictionary <Đặc tả các thực thể có trong hình> Entity Data dictionary: describe content of all entities Entity Name Description Ví dụ Figure 8 Conceptual diagram PAGE \* MERGEFORMAT 1 Data Dictionary Entity Data dictionary: describe all content of all entities Entity Name User Customer Contract Card CardInstance Payment Staff Compensation Punishment Accident ContractType NewCardRequest Notification Description Abstract entity describes a user in system Contain the customer information. Contain the contract information. Contain the card information Represent a card assigned to a contract Contain the payment information. Contain the staff information. Contain the compensation information. Contain the punishment information. Contain the accident information. Contain the contract type information. Contain the new card request information. Contain the notification information Table 9 Conceptual Diagram Data Dictionary PAGE \* MERGEFORMAT 1 D. Report No. 4 Software Design Description 1. Design Overview - - - This document describes the technical and user interface design of MSSC System. It includes the architectural design, the detailed design of common functions and business functions and the design of database model. The architectural design describes the overall architecture of the system and the architecture of each main component and subsystem. The detailed design describes static and dynamic structure for each component and functions. It includes class diagrams, class explanations and sequence diagrams for each use cases. The database design describes the relationships between entities and details of each entity. Document overview: Section 2: gives an overall description of the system architecture design. Section 3: gives component diagrams that describe the connection and integration of the system. Section 4: gives the detail design description which includes class diagram, class explanation, and sequence diagram to details the application functions. Section 5: describe screens design. Section 6: describe a fully attributed ERD. Section 7: describe algorithms. PAGE \* MERGEFORMAT 1 2. System Architectural Design Ví dụ Figure 9 System architecture design This diagram is referenced and modified from an original concept from: Chapter 6 Architecture Design, SOFTWARE ENGINEERING 9th Edition, by Ian Sommerville. 2.1 Web application architecture description Ví dụ In Web Application, the system is developed under J2EE MVC architecture style. We choose this architecture for Web application because of following advantages: Web app contains a Web service (public API for mobile app), with MVC architecture, we can separate business code with Controller and View, so we can use the business code in web service without repeat the code. ... This project follows MVC architecture with following components: Servlet (Controller) is the parts of the application that acts like event handler to handles user interaction. Typically, controller read data from a request and calls appropriate Business’s method then selects view to return to user. ... 2.2 ... PAGE \* MERGEFORMAT 1 3. Component Diagram Ghi chú: Xem lại bộ quy ước kí hiệu của UML 2.0 trước khi vẽ các mối quan hệ cũng như hiểu rõ thiết kế để vẽ chính xác. Nếu tool không phù hợp thì nhóm nên dùng Paint để vẽ Component dictionary: describe component Component Name Description Ví dụ Figure 10 Component Diagram Component Dictionary: Describes components Web Application Web application package: View, Controller Mobile Application Mobile application package PayPal Handle payment process with PayPal API Payment Component Component to handle payment process Web Service Provide API for mobile applications to interact with the system. Staff Component Component to handle staff activities in the system Customer Component Component to handle customer activities in the system Public Component Component to handle guest activities in the system Admin Component Component to handle admin activities in the system Schedule Component Component to handle scheduler in the system Business Objects Data Access Objects Common objects to handle domain business operations for each components Component to handle interaction between the system and database Table 10 Component Dictionary PAGE \* MERGEFORMAT 1 4. Detailed Description 4.1 Class Diagram Class dictionary: describe Class Class Name Description Ví dụ Figure 11 Class Diagram PAGE \* MERGEFORMAT 1 Class Name PaymentEntity CardEntity CardInstanceEntity CustomerEntity ContractEntity StaffEntity CompensationEntity PunishmentEntity AccidentEntity ContractTypeEntity NewCardRequestEntity CardAccessLogEntity NotificationEntity NotificationReadEntity Class dictionary: describe Class Mapping column Description with Conceptual diagram Payment Contain the payment information. Card Contain the card information. CardInstance Contain the card instance information Customer Contain the customer information. Contract Contain the contract information. Staff Contain the staff information. Compensation Contain the compensation information. Punishment Contain the punishment information. Accident Contain the accident information. ContractType Contain the contract type information. NewCardRequest Contain the new card request information. N/A Not exist in conceptual diagram. But needed in class diagram to contain the card access log information. N/A Not exist in conceptual diagram. But needed in class diagram to contain the notification information. N/A Not exist in conceptual diagram. But needed in class diagram to know what notifications is read. Table 11 Class dictionary 4.2 Class Diagram Explanation Ví dụ 4.2.1 Role Attribute Attribute RoleID Name Type int string Visibility Private Private Description Unique identifier of a role Role name Method Method Getter Setter Return type Attribute type Void Visibility Public Public Description Get attribute value Set value of attribute 4.2.2 ... 4.3 Interaction Diagram 4.3.x Tên Interaction Diagram PAGE \* MERGEFORMAT 1 Summary: . Ví dụ 4.3.1.1 Create new contract Summary: this diagram show process of staff creates new contract Figure 12 Sequence diagram - Create new contract 4.3.1.2 View Friend List Summary: This diagram shows how member views all contacts that include MSSC contacts and android cell phone contacts. PAGE \* MERGEFORMAT 1 Figure 13: View Friend List 5. Interface 5.1 Component interface Nội dung được đặc tả theo dạng bảng như sau Signature Tên hàm Description Mô tả mục đích Input Tham số truyền Output Format Output Kết xuất khi hàm xử lý xong Kiểu dữ liệu Exception Xử lý lỗi Ví dụ Web Service Interface Signature public ResponseObject getCheckConnection(R r) Description Check server status Input Request object r Output Json Boolean the status of server PAGE \* MERGEFORMAT 1 Output Format Boolean Exception JsonProcessi ngException ... 5.2User Interface Design . Lưu ý phải đánh số đặc tả các control trên giao diện cùng với các thành phần trong ràng buộc Ví dụ 5.3Guest Interface Design 5.3.1 Login Figure 14: Login Fields No 1 Field Name Username 2 Password Description Fill user name Fill password Read only No Mandatory Data Type String Length Yes Control Type Textbox No Yes Password String N/A N/A Buttons/Hyperlinks No Function Description Validation Outcome 3 Signin Log-in into the system N/A Transfer to home page 6. Database Design 6.1 Entity relationship diagram (ERD) PAGE \* MERGEFORMAT 1 6.2 Data Dictionary Entity Data dictionary: describe content of all entities Entity Name Description Entity name Tên Attributes Description Domain Thuộc tính 1 {PK} Mô tả Kiểu dữ liệu ... ... ... Null Y/N ... Table 12: Detail Data Dictionary * Business integrity constraint: 7. Algorithms Chú ý Không nhất thiết phải là thuật toán nổi tiếng mà có thể là cách tổ chức dữ liệu cũng như giải thuật do nhóm đang thực hiện ở bên trong hệ thống: ghi rõ bản chất, phân tích về độ phức tạp, nếu tham khảo phải ghi rõ nguồn Cách giải quyết hay cách áp dụng các qui trình nghiệp vụ hay cách chuyển đổi bài toán khi làm bằng tay - chưa áp dụng máy tính và chương trình để cho thấy việc áp dụng giải bài toán hay giải quyết vấn đề rồi chuyển đổi cách đó sang thành chương trình máy tính Ví dụ 7.1Document Breakdown 7.1.1 Definition Document breakdown is the way to break the document into many small parts. Each part has it own title and contents of it. And the final data has tree structure. 7.1.2 Define Problem All content of document is quite difficute for manage so we must re-construc structure of document for using. 7.1.3 Solution To solve this problem, we should follow these steps: - Convert (save) document DOCX file as html type by using Microsoft Word save as Web Filtered. - Import both html file and directory that incluses all pictures of document. - Using xpath to get data of html file as we need, include h1, h2, h3,…, image, text content,.. - Save them with structure as below: -TitleA: contentA PAGE \* MERGEFORMAT 1 ---TitleA1: contentA1 ------TitleA1.1: contentA1.1 ------TitleA1.2: contentA1.2 ---TitleA2: contentA2 7.1.4 Complexity - In total, the complexity of this algorithm is 7.1.5 Flowchart PAGE \* MERGEFORMAT 1 PAGE \* MERGEFORMAT 1 Figure 15: Breakdown document flow chart 7.2 String Comparison 7.2.1 Define Problem Given two strings. Calculate their matching percent. 7.2.2 - - Robustness to changes of word order: two strings which contain the same words, but in a different order, should be recognised as being similar. Language independence: the algorithm should work not only in English, but in many different languages. 7.2.3 - Requirement Solution If a string contains many words, break it into a list of words. For each word, we find out how many adjacent character pairs are contained in it. Create a function pairs(s) which returns a list of adjacent character pairs of string s. Then, we use below formula to calculate matching percent. 7.2.4 Example Calculate the matching percent of 2 strings: France and French. - Upper case 2 strings: + France FRANCE. + French FRENCH. - Break string into list of adjacent character pairs: + FRANCE + FRENCH - Calculate its matching percent. PAGE \* MERGEFORMAT 1 E. System Implementation & Test 1. Introduction 1.1 Overview Ví dụ This section provides in detail all necessary information about implementation information and testing procedure of MSSC includes test plans, test cases, test result and risks estimations. 1.2 Test Approach 2. Database Relationship Diagram 2.1 Physical Diagram 2.2 Data Dictionary Data dictionary: describe content of all tables Table Name Description Tên Explanation Entity name Tên Attributes Description Thuộc tính 1 {PK} Mô tả ... ... Table 13: Attribute Data Dictionary Domain Kiểu dữ liệu ... 3. Performance Measures Ví dụ 3.1 Clustering Performance Clustering is performed by running K Mean Algorithm which has complexity of : O(n * k * I * d) o n : number of points o k : number of cluster o I : number of iteration o d : number of attributes (3) PAGE \* MERGEFORMAT 1 Null Y/N ... Clustering take almost the time of process that we can ignore the time needed to load data from database, digitalize data. The speed of clustering will vary and increase dramatically when n increase. The purpose of this project is not about optimizing K-Mean Algorithm so it is accepted to let the process run till it completes. Moreover, the clustering is designed to run by staff, wait time is acceptable. 4. Test Plan <Đưa ra kế hoạch test> Ví dụ The purpose of this section is to verify and ensure that MSSC meets its design specification and other requirements from user. The following part will describe which features to be tested and which will not. 4.1 Features to be tested 4.2 Features not to be tested 5. System Testing Test Case Ví dụ PAGE \* MERGEFORMAT 1 Figure 16: Guest, Member Core Flow PAGE \* MERGEFORMAT 1 MSSC - Introduction 5.1 Guest Test Case 5.1.1 Search Event ID Test Case Description Test Case Procedure Expected output Inter-test Case Dependence Result Test Date Note MSSC - Introduction F. Software User’s Manual 1. Installation Guide 1.1 Setting up environment at server side The following software must be installed into the server machine: 1.1.1 Hardware requirements 1.1.2 Software requirements 1.2 Deployment at server side 1.2.1 Prepare deployment package 1.2.2 Configure Server before deploy 1.2.3 Deploy web application on server 1.3 Setting up the environment at client side 1.3.1 Setting up for computer 2. User Guide G. Appendix 47
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Page Count : 47 Language : en-US Author : KhoaTNDSE60680 Creator : Microsoft® Office Word 2007 Create Date : 2015:09:03 17:40:02 Modify Date : 2015:09:03 17:40:02 Producer : Microsoft® Office Word 2007EXIF Metadata provided by EXIF.tools