Build applications for supporting to keep vehicles using NFC technology

Introduction

Project Information

- Project name: Build applications for supporting to keep vehicles using NFC technology

- Product Type: Android phone Application, Website

Introduction

The increasing volume of vehicles entering and leaving major economic centers has created significant parking challenges Inadequate infrastructure leaves shoppers with limited options for convenient parking, exacerbating the problem.

We offer a convenient side road parking service that utilizes NFC technology to enhance the parking experience Our designated parking spots are equipped with Park-O-meters featuring NFC scanners, allowing users to easily prepay for their parking using their NFC-enabled devices By linking their digital wallets to these devices, users can efficiently manage their parking payments, ensuring a seamless and hassle-free process.

Current Situation

In major cities across Vietnam, roadside parking is facilitated through traditional methods and mobile applications such as Parking in Hanoi, My Parking in Ho Chi Minh City, and Smart Parking in Da Nang.

To park a vehicle through the apps, the user has to do the steps below:

2 Enter the number plate of the vehicle

Problem Definition

The advantage of the current situation:

● Require low budget and easy to install

● Create jobs for parking cashier

Below are the disadvantages of the current situation:

● Lack of infrastructure: controlled parking lot traffic flow, security systems to verify vehicles, surveillance system

● Parking fee is not clear

● The NFC card got lost easily

Vehicle owners often unknowingly violate parking regulations due to a lack of awareness about which areas are restricted and the duration of permissible parking To address this issue, mobile applications like iParking, My Parking, and Smart Parking provide convenient solutions for users to easily find and comply with parking rules.

The advantage of the apps:

● Easy to pay the fee

Below are the disadvantages of the apps:

● The apps don’t concentrate on roadside parking

● Need Keeper for parking security

● Mobile app for the user needs internet in order to conduct payment

● Users need to have a smartphone to use the system

Proposed Solution

Our solution is to create more roadside parking lot which will be installed with automatic

Park-O-Meter and using our application, the user can use their smartphone device or NFC card which link to the user’s digital wallet to prepay for a parking spot

Figure A.1: The project solution concept 5.1 Feature functions

● Web application for the staff:

○ Create an account for user: for users who don’t have a smartphone with NFC support, admin can use an NFC card to register a new account for the user

○ Update the user’s vehicle information

○ Set policy and pricing method to the location

● Web application for the manager:

● Mobile app for Park-O-meter:

○ Scan users NFC supported device

○ Check the user’s digital wallet for information

○ Confirm payment for the parking spot

○ Users can register a new account

○ Users can register a new vehicle

○ Users can check-in to a parking spot by scanning the smartphone with the Park-O-meter

○ Users can recharge their digital wallet

○ Users can see information about their digital wallet

○ Users can see their parking history

○ Users can remove their vehicle

○ Easy to keep track of parking status

○ Can be used in offline mode

○ Easy to recharge their digital wallet using Paypal’s One touch

○ Can verify vehicle type by checking User’s account which has a vehicle plate number and notifies the user if that vehicle type is not allowed to park

○ Users must have an NFC supported device (smartphone which has NFC or Android Beam, NFC card).

○ Cannot manage users parking behavior in real-life scenarios

○ Users must take full responsibility after confirming payment for the parking spot.

Function Requirement

Function requirements of the system are listed as below:

○ Register account for the smartphone with NFC supported

○ Register account for NFC card

○ Use NFC/mobile as parking card to check in and check out

○ Set policy, pricing method for Park-O-meter

○ Link information from NFC devices to a users account

○ Transfer balance from One touch Paypal to user’s digital wallet

○ Send notification to the user about parking status

○ Send notification to staffs when a user creates a new unverified account

○ Send notification to the manager when a staff sends a refund request.

Role and Responsibility

No Fullname Role Position Contact

1 Kieu Trong Khanh Project Manager Supervisor khanhkt@fpt.edu.vn

2 Le Vu Truong Mentor Supervisor Truonglv11@fe.edu.vn

3 Mai Vu Cuong Developer Leader cuongmvse62265@fpt.edu.vn

4 Dang Ngoc Trung Developer Member trungdnse61649@fpt.edu.vn

5 Nguyen Quoc Bao Developer Member baonqse62485@fpt.edu.vn

Software Project Management Plan

Problem Definition

1.1 Name of this Capstone Project

● Official name: Build applications for supporting to keep vehicles using NFC technology.

● Vietnamese name: Xây dựng ứng dụng hỗ trợ giữ xe sử dụng NFC

To utilize Park-O-meter with an Android device equipped with NFC technology, it's essential to acknowledge the limited reading distance and low data transfer rates of NFC devices The system must selectively read data from these devices and establish a connection to the server to verify user information and facilitate payment processing for customers.

To ensure optimal functionality of the user's NFC device, the information stored must be both concise and sufficiently detailed to facilitate data retrieval from the server for account information or payment for the Park-O-meter.

Below are the problem encountered in this project:

NFC devices are essential for Park-O-meters to facilitate user payments and store account information, allowing seamless parking transactions However, access to NFC-enabled smartphones remains limited for many users Additionally, smaller companies may struggle to sustain their revenue and improve profits due to the high costs associated with purchasing and maintaining the necessary machines and equipment The installation of hardware and software, along with the hiring of technicians for maintenance, can lead to escalating expenses for these businesses.

● Security: currently, there are a few possible problems encountered with NFC tags, as NFC tags can be counterfeited, attacked during data transmission caused data loss, data corruption

● Parking and Pricing policy: Differents place has different parking policy as well as pricing methods Implementing many different policies may cost more than the benefit it gains

The user ethics of this parking system emphasize that it does not restrict users from parking various types of vehicles, even if they may not be suitable for specific spots Additionally, users have the option to leave without formally checking out their vehicle, but they are not allowed to reserve two parking spaces simultaneously.

Users who don’t have access to NFC supported device, we provide NFC Cards which has user’s account information needed for Park-O-meter to conduct payment

To handle security problems with NFC card, we will encode user’s data inside the NFC card and can only be decoded when having a key from the system

Users may face ethical concerns when leaving a parking spot without checking out, as the system continues to register their status as parked Consequently, any fines for exceeding the parking time limit will be added to their account Upon their next check-in for a new parking spot, they will be required to pay both the outstanding fine and the fee for the previous parking session.

To address parking regulations in Vietnam, the Park-O-meter will issue warnings regarding the types of vehicles permitted to park upon confirming payment.

The website provides the following features:

○ Create an account for user: for users who don’t have a smartphone with NFC support, staff can use an NFC card to register a new account for the user

○ Set policy and pricing method to location

○ Parking timer for parking process

○ Conduct payment for Park-O-meter

This application serves as a simulation tool for Card Printer operations, designed for companies that utilize NFC Card Printers to encode customer information onto NFC cards Currently, our system functions solely as a simulation, catering specifically to managers who oversee the process.

○ Write data about user account to a physical NFC card

○ Scan users NFC supported device

○ Check current Park-O-meter information

○ Check the user’s digital wallet for information

○ Confirm payment for the parking spot

● Every company who has an Information System infrastructure can deploy this system

● Companies who deployed this system has to equip enough devices for the system to run, includes:

○ Computer system with internet connection

○ The management website for the manager

○ NFC Card reader, writer to check, write customer’s information in the NFC card

○ Android Devices with NFC feature and NFC type A compatible act as Park-O- meter

○ The mobile application for users

● The language of the application is Vietnamese for mobile application and English for management website

● Users follow Vietnam laws of parking, check-in and check-out process

To enhance system security, we can integrate a camera into the Park-O-Meter, serving as an effective surveillance tool This camera will capture the vehicle's license plate number during the check-in and check-out process, allowing for verification and monitoring of users' vehicles throughout their parking duration.

The Park-O-meter requires a continuous connection to the server to gather user information for payment processing In the event of a temporary internet outage, it will securely store the user's account ID to ensure that payments can be completed once the connection is restored.

Currently, the Park-O-meter system is designed to manage payments for only one parking spot at a time However, enabling payment for multiple spots would significantly lower the installation costs associated with the Park-O-meter.

Internet Connection Cable, Wi-Fi (4 Mbps) Cable, Wi-Fi (8 Mbps)

Operating System Window Server 2008 Window Server 2008

Computer Processor Intel® Xeon ® 1.4GHz Intel Core i7 2.60GHz

Computer Memory 4GB Ram 8GB or more

Table 2: Hardware Requirement for Server

Computer Memory 150MB 150MB or more

Table 3: Hardware Requirement for User Mobile

Hardware NFC enabled device NFC enabled device

Computer Memory 150MB 150MB or more

Table 4: Hardware Requirement for Meter NFC Scanner

Operating system Window 10 Operating system and platform for development

Environment Java EE 6 Specification for developing the web application Modeling tool StarUML version 5.0.2 Used to create models and diagrams

Used to implement website and web service

DBMS MySQL Workbench 6.3 Used to create and manage the database for the system Source control Git 2.15.1.2 Used for source control

Project Organization

This project utilizes a customized Scrum model, which is part of an agile framework for software development We have adapted this model to suit our team's current needs, choosing it for its flexibility and effectiveness in delivering results.

- Small requirements change based on project progress and clearly verify after each meeting minute can be handled more flexible without huge amendments to the budget or schedule

- Because of the various technologies that follow NFC, with limited time, we try to develop smaller easier function first and make scheduler to fit in more complicated function later

- In this project, all team members have strong background knowledge and well practice skills We also have experiences in building web and mobile application system

No Full name Role in Group Responsibilities

1 Kiều Trọng Khánh Project Owner - Specify user requirement

- Give out technique and business analysis support

2 Mai Vũ Cường Scrum master - Create Sprint Backlog and Product Backlog

- Make sure Scrum teams understand and follow the process

- Help the team master scrum artifacts such as Sprint Backlog, Product Backlog, …

- Always be present to answer questions and

21 give advice when product owner or scrum member needs

3 Mai Vũ Cường Đặng Ngọc Trung

- Testing Table 5: Roles and Responsibilities Details

Front End HTML, CSS, Javascript, jQuery

Back End JavaEE, Spring boot, JSP, JPA

Mobile development environments Android studio 1.0

Project Management Plan

Sprint Story ID Story Task ID Task

1.2 Introduction 1.3 Current Situation 1.4 Problem Definition

1.5 Proposed Solution 1.6 Role and Responsibility 1.7 Function Requirement

2 Product Backlog 2.1 Create Product Backlog

3 Project management plan 3.1 Problem Definition

3.2 Project Organization 3.3 Project management plan 3.4 Coding Convention

4.2 Software Requirement Specification 4.3 Software System Attributes

5.2 System Architectural Design 5.3 Component Diagram

3 6 Park-O-meter retrieve meter’s information

6.1 Send meter’s id to the server

6.2 Retrieve meter’s information from the server

7.1 Detect the user’s NFC device

7.2 Read user’s data from the user’s

NFC device 7.3 Send the user’s id to the server

7.4 Retrieve user’s information from the server

8.1 Match user’s vehicle type to vehicle type that allowed by the meter 8.2 Check user’s balance

8.3 Conduct payment and send to the server

9 Register account for user’s mobile application

10 System match vehicle type to user’s account

10.1 Get user’s plate number and license id from user’s account

10.2 Send user’s plate number and license id to Third-Party API

10.3 Retrieve vehicle type and match to user’s account

11 System create transaction log from payment

11.1 Create check-in date for the transaction 11.2 Replicate meter, user’s information 11.3 Open transaction

12 User check-out Park-O- meter

12.1 Detect the user’s NFC device

12.2 Read user’s data from the user’s

NFC device 12.3 Send the user’s id to the server

12.4 Get Open transaction match user’s id and meter’s id 12.5 Conduct payment fee for the user

13 Users use mobile application services

13.2 Users get parking transaction history list 13.3 Users update password 13.4 Users top-up digital wallet using

Third-party API 13.5 The User removes their vehicle 13.6 The User bind a new vehicle

14 Staffs use website application services

14.2 Write user’s data to an NFC card 14.3 Check, adjust users information 14.4 Register a new Park-O-meter

14.5 Check, adjust Park-O-meters information

4 15 Test the system 15.1 Create a test plan

16 Verify the quality of the system

17 Software user’s manual 17.1 Installation guide

1.3 Current Situation 1.4 Problem Definition 1.5 Proposed Solution 1.6 Role and Responsibility 1.7 Functional Requirements 2.1 Create Product Backlog

3.1 Problem Definition 3.2 Project Organization 3.3 Project Management plan 3.1 Coding Convention

Task ID Task Responsible Review

1.1 Project Information CuongMV TrungDN, BaoNQ

1.4 Problem Definition CuongMV BaoNQ, TrungDN

1.5 Proposed Solution TrungDN CuongMV, BaoNQ

1.6 Role and Responsibility TrungDN CuongMV

2.1 Create Product Backlog CuongMV TrungDN, BaoNQ

3.3 Project management plan BaoNQ, TrungDN CuongMV

4.1 User Requirement Specification 4.2 Software Requirement Specification 4.3 Software System Attributes

4.4 Conceptual Diagram 5.1 Design Overview 5.2 System Architectural Design 5.3 Component Diagram

4.1 User Requirement Specification CuongMV TrungDN, BaoNQ 4.2 Software Requirement Specification BaoNQ CuongMV

4.3 Software System Attributes BaoNQ CuongMV

4.4 Conceptual Diagram CuongMV BaoNQ, TrungDN

5.1 Design Overview TrungDN CuongMV, BaoNQ

5.2 System Architectural Design TrungDN CuongMV

5.3 Component Diagram CuongMV, TrungDN BaoNQ

5.4 Detailed Description TrungDN TrungDN, BaoNQ

5.6 Database Design CuongMV BaoNQ, TrungDN

6.1 Send meter’s id to the server 6.2 Retrieve meter’s information from the server 7.1 Detect the user’s NFC device

7.2 Read user’s data from the user’s NFC device 7.3 Send the user’s id to the server

7.4 Retrieve user’s information from the server 8.1 Match user’s vehicle type to vehicle type that allowed by the meter 8.2 Check user’s balance

8.3 Conduct payment and send to the server 9.1 Guest_Register

10.1 Get user’s plate number and license id from user’s account 10.2 Send user’s plate number and license id to Third-Party API 10.3 Retrieve vehicle type and match to user’s account

11.1 Create check-in date for the transaction 11.2 Replicate meter, user’s information 11.3 Open transaction

12.1 Detect the user’s NFC device 12.2 Read user’s data from the user’s NFC device

12.3 Send the user’s id to the server 12.4 Get Open transaction match user’s id and meter’s id 12.5 Conduct payment fee for the user

13.1 Users get account’s information 13.2 Users get parking transaction history list

13.3 Users update password 13.4 Users top-up digital wallet using Third-party API 13.5 The User removes their vehicle

13.6 The User bind a new vehicle 14.1 Register a new user account 14.2 Write user’s data to an NFC card 14.3 Check, adjust users information 14.4 Register a new Park-O-meter 14.5 Check, adjust Park-O-meters information

6.1 Send meter’s id to the server CuongMV TrungDN, BaoNQ

6.2 Retrieve meter’s information from the server

7.1 Detect the user’s NFC device CuongMV TrungDN

7.2 Read user’s data from the user’s NFC device

7.3 Send the user’s id to the server TrungDN CuongMV

7.4 Retrieve user’s information from the server

8.1 Match user’s vehicle type to vehicle type that allowed by the meter

8.2 Check user’s balance CuongMV TrungDN

8.3 Conduct payment and send to the server

10.1 Get user’s plate number and license id from user’s account

10.2 Send user’s plate number and license id to Third-Party API

10.3 Retrieve vehicle type and match to user’s account

11.1 Create check-in date for the transaction

11.2 Replicate meter, user’s information CuongMV BaoNQ, TrungDN

11.3 Open transaction TrungDN CuongMV, BaoNQ

12.1 Detect the user’s NFC device TrungDN CuongMV

12.2 Read user’s data from the user’s NFC device

12.3 Send the user’s id to the server TrungDN CuongMV, BaoNQ

12.4 Get Open transaction match user’s id and meter’s id

12.5 Conduct payment fee for the user CuongMV BaoNQ, TrungDN 13.1 Users get account’s information TrungDN CuongMV

13.2 Users get parking transaction history list

13.3 Users update password TrungDN CuongMV, BaoNQ

13.4 Users top-up digital wallet using

13.5 The User removes their vehicle TrungDN BaoNQ, TrungDN

13.6 The User bind a new vehicle TrungDN CuongMV, BaoNQ

14.1 Register a new user account BaoNQ CuongMV

14.2 Write user’s data to an NFC card CuongMV BaoNQ, TrungDN

14.3 Check, adjust users information BaoNQ CuongMV

14.4 Register a new Park-O-meter BaoNQ CuongMV

14.5 Check, adjust Park-O-meters information

15.1 User Requirement Specification 15.2 Software Requirement Specification 15.3 Software System Attributes

15.4 Conceptual Diagram 16.1 Design Overview 17.1 System Architectural Design 17.2 Component Diagram

15.1 Create a test plan BaoNQ TrungDN, BaoNQ

15.2 Run test cases BaoNQ, CuongMV, TrungDN CuongMV

15.3 Fix bug BaoNQ, CuongMV, TrungDN CuongMV

15.4 Test document BaoNQ BaoNQ, TrungDN

16.1 Quality document for system TrungDN CuongMV, BaoNQ

17.2 User manual CuongMV, TrungDN BaoNQ

18.1 Paper document CuongMV TrungDN, BaoNQ

All meeting minutes are saved at: https://drive.google.com/open?id=1OIwL05cRr-biYKMMILykwTetgV-bPLeq

Coding Convention

Java: Using to develop the website

● For variable’s name, use camel case Example: phoneNumber, vehicleNumber, …

● For function name, class name, use Pascal case

○ User, Location, … (for class name)

○ getUserById, createOrder, … (for function name)

● Write only one statement/declaration per line

● Indent continuation one tab stop (four spaces)

● Add at least one blank line between method definitions and property definitions

● Use parentheses to make clauses in an expression apparent

- Language Guidelines: Using Java Code Convention From:

● https://google.github.io/styleguide/javaguide.html

Software Requirement Specification

User Requirement Specification

● Check-in using NFC device

● Check-out using NFC device

● Get the user’s profile information

● Get all users profile information

● Create an account for guest

● Create a vehicle for the user

● Send notifications to mobile and website application

● Send SMS message to mobile devices

System Requirement Specification

● The mobile interface uses Vietnamese Users can learn to perform check-in, check-out first time using the application

● Web application: Work with Firefox (v30 or above), Chrome (v14 or above)

● Mobile application: Android operating system (v4.4.0, v5.1.2, v7.0.0)

● Smartphone with NFC support and NFC Type A compatible

[Ref: http://nearfieldcommunication.org/nfc-signaling.html/]

● Use HTTP protocol 1.1 for communication between the web browser and the web server

● Use HTTP protocol 1.1 for communication between the mobile application and the web service

Figure C1: System Overview Use Case

Figure C2: Guest Overview Use Case

Use Case Specification USE CASE - G01

Use Case No G01 Use Case Version 2.0

- This use case allows guest to register an account to be a member of the system

- Guest receives a new account with a confirm code

- Guest sends the register command with guest information

- Success: Guest receives a new account with a confirm code

Step Actor Action System Response

1 The guest goes to the register screen The System requires identity information from Guest:

- Phone number: number text input length 8-14

- Last name: free text input

- Password: free text input, length 6-20

3 The guest sends a command to register

The guest will be transferred to the waiting to verify screen

1 The guest enters the wrong format or phone number, vehicle number, license id has already exist

The System shows an error message “ Tài khoản/phương tiện này đã tồn tại“

1 When the connection to the server is lost

The System shows an error message

- A new user account will be created in the system with inputted information

- Initial status is inactive When user enters verify code, user will be change status to active

- Staff will verify user’s vehicle and system will send verify code to user

Use Case No G02 Use Case Version 2.0

- This use case allows guest to login to the system

- Guest can login the system

- Guest sends the login command

- Success: Guest login the system

1 The guest goes to the login screen The System requires identity information from Guest:

- Phone number free text input length:8-14

- Password free text input, length 6-20

3 The guest sends a command to log in The guest will log in the system

1 The guest enters wrong phone number or password

The system shows an error message

1 The guest logins to an unactivated account

The system shows the enter confirm code screen

2 The guest enters the confirm code

3 The guest sends confirm command to the system

The guest will log in the system

1 The guest enters the wrong confirm code

The system shows an error message “Sai mã xác nhận”

The system shows the message the “Vui lòng thử lại”

- Only staff or manager can login to website

- After login to the system on website, user will be redirected to specific view based on their role on the system: staff or manager

- If role “staff” , the system will display to Staff view

- If role “manager” , the system will display to Manager view

- After user logins to the system on mobile application, system will display Prepare to check-in screen

Figure C5: User Overview Use Case

Use Case No U01 Use Case Version 2.0

Use Case Name Top-up

- This use case allows user to recharge their account

- Account’s balance will be updated

- Guest sends the top up command

- User’s device must be online

- Success: Account’s balance will be updated

1 User enters top up screen System requires user to input money

2 User sends top up command System requires user to login to paypal

4 User logins to paypal System sends notification and account’s balance is updated [Exception 1]

Use Case Name Check In

- When user scans their device to meter, meter will send check in request to the system and system will validate request

- System sends response to meter and records order transaction as status open then save it into the system

- System records order transaction as status open after user scans their device to meter

- User scans device to meter at location

- User must be logged in (when using mobile application)

- User must have verified vehicle

- Success: System records order as status open and charges money on user’s account

1 User scans device to meter Pricing list and information of location will be displayed

2 User sends check in commands

User will be transferred to waiting screen with counting time System will charge account money

1 User checks in location while having checked in another location

The System shows message “ Bạn đang đăng ký một địa điểm Bạn có chắc muốn đăng ký địa điểm này không?”

2 User sends check in commands The system will record new order and close the previous other

- User scans NFC device to meter with an active account and user must have verified vehicle

- System will check if this account is having another order :

- If user is having another opening order, system will check out that order

- If user is not having any opening orders, system will choose suitable policy based on time slot and the user vehicle type

The system will retrieve pricing based on the selected policy, which varies according to the time slot and the type of vehicle, and will then add this list pricing to the order total.

- User will receive notification after order is saved with “open” status

Use Case Name Check out

- When user scans their device at second time, meter will send check out request to the system

- System sends response to meter and records order transaction as status closed then save it into the system

- System records order transaction as status closed after user scans their device to meter at the second times

- User scans device to meter at the same location at the second times

- User must be checked in the same location where user check out

- User must have verified vehicle

- Success: System records order as closed and the system will charge money on account’s balance

1 User scans device to meter at the second times

System will show order pricing Meter will ask user to confirm if user still wants to check out

2 User sends confirm check out commands

System will close order transaction and user’s balance will charged money [Exception 1]

- When user check out, system will compose a list of hour has price based on the order pricing from the order

The system calculates the total price based on a list of hourly rates For each hour, it checks if the parking time exceeds the allowed limit If it does, the system adds a fine to the total price; if not, the hourly rate is included in the total.

- The system will minus the total price to user’s balance

- System will update status of the order to close and save the check out date

- User will receive notification after check out order

Figure C9: Get parking history

Use Case Name Get parking history

- This use case allows user to get parking history

- User can view their parking history

- User sends get parking history command

- Login to the system as user role

- Success: Parking history will be displayed as list in UI or displayed label “Không có lịch sử đậu”

1 User goes to profile screen

2 User sends get parking history command

Parking history list will be displayed with information :

1 User sends get parking history command

Parking history list is not displayed

The system shows the message the “Hệ thống đang bận”

- User will get the parking history list

- Parking history list is sorted by date

- User can view receipt when taps on history item

- Parking receipt will contain information:

- User can view order pricing information when sends get order pricing commands:

- Each pricing from hour row:

Use Case Name Change password

- This use case allows user to change their account’s password

- User can change their password

- User sends change password command

- Success: User will receive password in SMS sent by system and user will be moved to login screen

1 User sends change password command

System requires user to input information:

3 User sends confirm change password command

System will move user to main screen [Alternative 1]

1 User input password that length is less than 6 characters

System shows the message “ Mật khẩu có ít nhất 6 ký tự”

The system shows the message the

- User’s password will be updated in the system with inputted information

Figure C11: Staff Overview Use Case

2.3.3.1 Look up Parking Order

Figure C12: Look up Parking Order

Use Case No S01 Use Case Version 2.0

Use Case Name Look up Parking Order

- This use case allows staff to look up parking order’s information such as date, status, user

- Staff can see details of the parking order

- Staff sends get parking order command

- Login to the system as staff role

- Success: Parking orders will be displayed as list in UI or displayed label “No data”

1 Staff goes to order screen System requires staff to input conditions:

3 Staff sends get parking order command [Alternative 2]

Parking Order list will be displayed with information :

1 Staff sends get parking order command

Parking history list is displayed as “No data”

1 Staff sends order detail command Order detail will be displayed with information:

2 Staff sends request refund command System requires staff to input information :

4 Staff sends confirm request refund command Request refund will be saved to system and displayed on

- Extend to Request Refund Order(send request refund order command)

- Staff will get the parking order list

- Parking order list can be looked up by vehicle number/ status of order with specific date

- Staff can get order detail which contains :

- Staff can send request refund when customer calls system’s fault about their order

- When there’s a incident in customer’s order caused by the system, customer calls to staff to feedback Staff verifies the issue and can send a request refund to system

Figure C13: Get Vehicle Information

Use Case Name Get Vehicle Information

- This use case allows staff to get vehicles

- Vehicle will be displayed as list

- Staff sends get vehicle command

- Success: Vehicle list will be displayed in UI or displayed label “No data”

1 Staff sends get vehicle command

Vehicles will be displayed as list with information:

1 Staff sends get vehicle command Vehicle list is displayed as “No data”

1 Staff can filter vehicle by following condition:

- Vehicle Number/ License Plate Staff sends get vehicle command

Matched vehicles will be displayed as list with information:

- Staff will get the vehicle list

- Vehicle list can be looked up by vehicle number/ license plate

- Staff can get vehicle detail which contains :

Use Case Name Update Vehicle

- When user want to change vehicle information, user will contact to staff

- Staff can update vehicle information

- Staff can remove if user want to remove their current vehicle

- If that vehicle existed and does not belong to any users in the system, staff will add vehicle to user

- If that vehicle does not exist in the system, staff will verify and add to user

- Staff sends update vehicle command

- Success: Vehicle information will be updated

1 Staff sends get vehicle command Vehicles will be displayed as list with information:

2 Staff chooses specific vehicle and sends update vehicle command [Alternative 2]

The system requires user to edit vehicle informations

3 Staff sends a command to save Vehicle will be updated and vehicles will be displayed as list with information:

1 Staff sends get vehicle command Vehicle list is displayed as “No data”

1 Staff chooses specific vehicle and sends delete vehicle command

1 Staff chooses specific vehicle and sends verify vehicle command

System requires user to input:

3 Staff sends verify vehicle command Vehicle will be updated.\

Relationship: Set Vehicle To User, Verify Vehicle

- Staff will get the vehicle list

- Vehicle list can be looked up by vehicle number, license plate

- Staff can get vehicle detail which contains :

- Only unverified vehicles will be displayed on verify vehicle screen

Use Case Name Create Vehicle

When a user registers an account, they provide their vehicle number and license plate to the staff The staff then verifies this information by checking it against a government website If the details are confirmed to be valid, the staff will create a vehicle profile and add it to the user's account.

- Staff can create vehicle and add it to user’s account

- Staff sends create vehicle command

- Success: Vehicle will be created and added to user’s account

1 Staff sends create vehicle command System requires staff to input information:

3 Staff sends a command to save New vehicle will be saved to the system and added to user’s account [Exception 1]

- A new vehicle will be created in the system with inputted information

- Initial verify status of vehicle is “Verified”

- Initial active status of vehicle is “Inactive”

Figure C16: Get User Information

Use Case Name Get User Information

- This use case allows staff to get user’s information

- Staff can get user’s information

- Staff sends get user information command

- Success: Users will be displayed as list in UI or displayed label “No data”

1 Staff sends get users command Users will be displayed as list with information:

1 Staff sends get vehicle command Users list is displayed as “No data”

- Staff will get the user list

- User list can be looked up by phone number/ lastname/ license plate

- Staff can get users with information:

Use Case Name Create User

- When guest does not have smart phone so guest needs to have staff create an account for them

- Staff sends create user command

- Success: New user will be added to system and need to be verified

1 Staff sends create users command System requires staff to input information:

- Vehicle Number: text, max length: 10, require

- License Plate: text, max length:

3 Staff sends command to save

A new user will be added to system and need to be verified

1 Staff send command to reset All inputs are blank

- Phone number must be valid

- License plate and vehicle number must be valid

- Default money in user’s balance is zero

- User must wait for staff to verify user’s vehicle to use mobile app

Use Case Name Update User

- This use case allows staff to update user information

- Staff can update user information

- Staff sends update user command

- Success: User’s information will be updated

1 Staff sends update users command System requires staff to input information:

- Type User: send SMS or Notification

3 Staff sends command to save

User information will be updated [Exception 1]

1 Staff send command to close Back to “user manage” screen

Relationship: Verify Vehicle, Set Vehicle To User

- Customer that use NFC card will be a user as “send SMS” type

- Customer’s information will be updated in the system with inputted information

- Staff can remove vehicle from user by sending remove vehicle command

Figure C19: Get Location Information

Use Case Name Get Location Information

- This use case allows staff to get location information

- Staff can get location information

- Staff sends get location command

- Success: Location list will be displayed in UI or displayed as label “No data”

1 Staff sends get location command Location will be displayed as list with information:

1 Staff sends get locations command Location list is displayed as “No data”

Relationship: Extend to Manage Location (send manage location command), Extend to Set

Policy To Location(send set policy to location command)

- Staff can get locations as list

- Location list is displayed with information:

- When sends set policy to location command, the chosen policy will be duplicated and added to location

- Policies in location can be filtered by vehicle types, location

Use Case Name Create Location

- This use case allows staff to create locations

- Staff sends create location command

- Success:A new location will be added to the system and staff will be moved to location manage screen

1 Staff sends create locations command System requires staff to input information:

3 Staff sends command to save A new location will be saved to the system

1 Staff sends command to save The system shows the message the

- Location status default is “Available”

- A new location will be created in the system with inputted information when user sends command to save

Use Case Name Update Location

- This use case allows staff to update location

- Staff sends update location command

- Success: Location will be updated and staff will be moved to location manage screen

1 Staff sends update location command System requires staff to input information:

3 Staff sends command to save A location will be updated

- Location will be updated in the system with inputted information

Figure C22: Get Policy Information

Use Case Name Get Policy Information

- This use case allows staff to get policy

- Staff can get policy information

- Staff sends get policy command

- Success: Policy list will be displayed in UI or displayed as label “No data”

1 Staff sends get policy command Policy list will be displayed with information:

1 Staff sends get policy command Policy list is displayed as “No data”

Relationship: Extend to Set Policy To Location (send set policy to location command), extend to manage policy (send manage policy command)

- Staff can get policy as list

- Policy list will be displayed with information:

- Policies can be filtered with vehicle types and location

- When staff want to reuse the policy on different location instead of creating new one, staff can look up policy and add to location

- When sends set policy to location command, the chosen policy will be duplicated and added to location

Use Case Name Create Policy

- This use case allows staff to create policy

- Staff sends create policy command

- Success: A new policy will be added to system and staff will be moved to manage policy screen

1 Staff sends create policy command System requires staff to input information:

3 Staff sends a command to save A new policy will be added to the system

System requires staff to set pricing for policy

5 Staff sends a command to save A new pricing will be added to policy

1 Staff leaves inputs blank System will show message “ Please choose {vehicle type/ time allowed}”

- The same location and time allows

System will show message “ This policy existed”

- A new policy will be created in the system with inputted information

- A policy can contains many vehicle types

- A location can contain many policies

- Each particular time and vehicle has its own pricings

Use Case Name Update Policy

- This use case allows staff to update policy

- Staff sends update policy command

- Success: Policy will be updated and staff will be moved to manage policy screen

1 Staff sends update policy command System requires staff to input information:

3 Staff sends a command to save Policy will be updated to the system

1 When connection is lost System will alert message “Please try again.”

- Policy will be updated in the system with inputted information

Use Case No M01 Use Case Version 2.0

Use Case Name Approve Refund

- This use case allows manager to approve or reject refund request sent by staff when customer feedbacks incident caused by the system about their order

- Manager can approve or reject refund request

- Staff sends approve/reject refund command

- Login to the system as manager role

- Success: If manager approves, amount of money in refund request will be transferred to user’s balance If manager rejects, staff will be notified

1 Manager sends approve/reject command

A list of refund request is waiting for handle

3 Manager sends a command to approve [Alternative 1]

Amount of money in refund request will be transferred to user’s balance

1 Manager sends a command to reject refund

Staff will be notified that refund request is rejected

- Manager can approve or reject refund

- Amount of money in refund request will be transferred to user’s balance if manager approves

- Staff will be notified that refund request is rejected if manager rejects

- Refund request can be looked up with order/staff/manager

Use Case No H01 Use Case Version 2.0

Use Case Name Send SMS

- This use case allows handler to send SMS to guest and user

- When guest registers an account, handler will send SMS to guest

- When user registered their account as “Send SMS” type which handler will use SMS instead of notification to notify user

- User or guest requests sending SMS

- Guest or user as “Send SMS” type

- Guest or user requests sending SMS

- Success:User or guest will receive a SMS

1 User/Guest requests sending SMS Send SMS to user/guest

- Guest will receive SMS containing verify code when register an account

- User will receive SMS when they registered their account as “Send SMS” type.

Software System Attribute

● The User can learn to perform check-in, check-out within 5 minutes

● Staff can learn to use functions in website application within less than 1 day of training

● The manager will need less than 2 days of training to use the system

● When Users lost connection to the internet, users can use their smartphone with NFC supported or NFC card to use check-in, check-out features

● The system can be accessed by User with Android mobile device (Android 5.1.2, 6.1.0, 7.0.0) that include NFC support and NFC type A compatible

Users will receive NFC cards from the system distributor, enabling them to utilize check-in and check-out features Additionally, they will get SMS notifications sent to their registered phone numbers.

● To handle security problems with NFC card, we will encode user’s data inside the NFC card and can only be decoded when having a key from the system

● Website application has an authoring system to verify between staff and manager

● All functions within the system are categorized based on the component that they belong to

Conceptual Diagram

Entity Data dictionary: describe all content of all entities

User Is a person who has access to the mobile application

● Phone_number (used to verify the user)

● Password (used to authenticate the user)

● Money (used in payment for the parking spot)

Vehicle ● Is an entity describe specific information of a vehicle which belongs to the user

● License plate id, vehicle number (used to verify vehicle)

VehicleType Is an entity describe the information about the types of vehicle that allowed for a specific location Exp: ”Small van, small truck, ”

Location Is an entity which holds information about the location that vehicle can park

● Is_active (used to check if the location is available for parking)

Policy Holds information about the time schedule of a location:

● Allowed parking time (to limit parking time to the parking spot )

● Vehicle types that can parking in the location with the specific prices

Order Is an entity contain the information when a user makes parking transaction:

● Check-in, check-out date

OrderType Describe the status of an order such as open, closed,

Notification Describe a handler which will manage notifications of the system

Staff Member of the system that has permission to manage user, vehicle, location, policy, view orders and request refund for order

Manager High-level member that have permission to approve order refund request

Refund Staff sends a refund request for an order to the manager Has the following attributes:

● Order id (to trace back to the original order)

When manager approve or decline when manager rejects the request:

● Request status (“Waiting”, ”Approved”, ”Rejected”) Table 12: Component Diagram Data Dictionary

Software Design Description

Design Overview

This document outlines the technical and user interface aspects of Parking With NFC, detailing its architectural design, common and business function specifications, as well as the database model design.

- The architectural design describes the overall architecture of the system and the architecture of each main component and subsystem

- The detailed design describes a static and dynamic structure for each component and functions It includes class diagrams, class explanations for each use cases

- The database design describes the relationships between entities and details of each entity

• 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 a class diagram, class explanation, activity diagram and sequence diagram to details the application functions

• Section 6: describe fully attribute ERD

Software Architecture Design

Web Application is developed using only View model: Freely and easy to design, customize page and show essential data

A web service serves as a central hub for data retrieval and updates between mobile applications (User and Meter Application) and web applications, facilitating seamless communication This separation necessitates a web service to streamline changes in business logic, enhancing overall efficiency and adaptability.

User application is developed in Android OS because the use of NFC supported functions as well as wide support of libraries,

Component Diagram

Figure D2: Component Diagram MVC view

User Application Contains all views of the user application

Meter Application Contains all views of the meter application

Management Web Contains all views of the management website application

Exchange Rate API A REST service that provide currency exchange rates live real time Controller Contains all the web service mapping process

Service Contains all the business requirement processing in the system

Repository Contains all the database connecting and data retrieving process

Model Contains all information about database entities

Figure D3: Component Diagram describe by business role

Layout Renderer Contains all views of application

Activities Contains all activities that handle model and layout renderer

Models Contains all models of application

SQLite Services Contains all services to manage data in local database

RMI Services Contains all REST services to work with Web Server

Firebase Services Contains all services to send or receive notifications

Paypal API A REST service that process payment

Exchange Rate API A REST service that provide currency exchange rates live real time View Renderer Contains all views of Management Web

Policies Contains Model, Controller, Repository, Service of Polices

Locations Contains Model, Controller, Repository, Service of Locations

Orders Contains Model, Controller, Repository, Service of Orders

Users Contains Model, Controller, Repository, Service of Users

Vehicle Types Contains Model, Controller, Repository, Service of Vehicle Types

Vehicles Contains Model, Controller, Repository, Service of Vehicles

Staffs Contains Model, Controller, Repository, Service of Staffs

Detailed Description

Attribute Type Visibility Description id Integer private Unique identifier of refund staffUsername Staff private Information of staff who requested managerUsernam e

The article discusses the essential components of a refund request, including the manager's decision on the request, the order ID associated with the refund, and the current status of the refund It highlights the refund amount to be processed, along with the creation and closure dates of the request Additionally, it outlines the description provided for each refund request to ensure clarity and understanding.

Method Return type Visibility Description

Getter Attribute type public Get attribute value

Setter void public Set attribute value

Attribute Type Visibility Description id Integer private Identifier of refund status name String private Name of refund status description String private Description of refund status

Attribute Type Visibility Description id Integer private Identifier of location

Location String private Name of location

The location's description is stored as a private string, while a boolean value indicates whether the location is activated Additionally, another boolean value is used to determine if the location has been deleted.

Attribute Type Visibility Description id Integer private Identifier of Order

The total double private parking fee is determined by the vehicle's unique identifier number and the check-in date, which records the time the vehicle enters the parking spot The check-out date indicates when the vehicle leaves, while the duration reflects the total time parked The allowed parking times specify the beginning and end of when the vehicle can be parked, with a minimum hour requirement set to estimate the parking fee Additionally, the order status provides insight into the current status of the parking order, and user information is linked to the individual who parked the vehicle.

The article discusses essential elements related to vehicle parking information, including personal details such as name and phone number, the specific location ID where the vehicle was parked, and the associated address and description It also highlights the order pricing list, which contains rules for estimating parking fees, as well as a list of hourly prices that contribute to the overall parking fee calculation.

The article outlines key attributes related to parking order pricing, including an integer identifier for the order (id), a time period for estimating parking fees (fromHour), and a double value representing the hourly parking fee (pricePerHour) Additionally, it specifies a late fee charged per hour for extended parking (lateFeePerHour) and an integer identifier for the order itself (orderID).

Attribute Type Visibility Description id Integer private Identifier of order status name String private Name of order status description String private Description of order status

The policy includes several key attributes: an identifier represented as an integer (id), the start time for allowed parking (allowedParkingFrom) specified in long format, the end time for permitted parking (allowedParkingTo) also in long format, and a location identifier (locationID) as an integer.

The PolicyHasTblVehicleType includes several key attributes: an integer identifier (id) for the policy, a private vehicleTypeId containing information about the vehicle type such as name and description, and a policyId that serves as the identifier for the applicable policy at the location Additionally, it specifies a minimum hour (minHour) required to estimate the parking fee.

The pricing structure for parking includes a unique identifier, a defined time period for estimating fees, and a standard hourly rate Additionally, there is an increased fee for extended parking beyond the allotted time, and the pricing rules are applicable from a specific date and time.

The user attributes include a unique identifier (id), a private phone number (phoneNumber), and a secure password (password) Each user also has a wallet balance represented as a double (money), alongside personal details such as their first name (firstName) and last name (lastName) Additionally, the user's vehicle information is stored, including the vehicle number (vehicleNumber) and details like brand and size (vehicle) Lastly, a boolean value (smsNoti) indicates whether the user receives SMS notifications.

Notifications or not isActivated Boolean private Determine validity of account that is activated or not deviceToken String private Token of user’s device that help device can receive notifications

The article outlines the attributes of a staff account, including a private username that serves as the identifier for the account, a private password for security, a Boolean value indicating whether the staff member is a manager, and another Boolean value that determines the activation status of the account.

The article details the attributes of a vehicle, including a unique identifier number known as the vehicle number and the license plate ID, both of which are private strings It also outlines the brand and size of the vehicle, along with the expiration date represented as a long integer Additionally, it highlights the verification status of the vehicle through a boolean value, and provides information about the vehicle type, including its name and description, categorized under the VehicleType attribute.

Owner User private Information of user who parked vehicle such as: name, phone number, etc…

Is_activated boolean private Determine validity of vehicle that is activated or not

Attribute Type Visibility Description id Integer private Identifier of vehicle type name String private Name of vehicle type

4.3 Interaction Diagram 4.3.1 Authenticate activity diagram

- This diagram describes the process of a guest to login to system

- Guest will fill in Username and Password as input of process If guest login successfully, they can use the functions of system as user

Figure D5: Authenticate Activity Diagram 4.3.2 Check-in activity diagram

- This diagram describes the process of user to check-in the spot

To initiate the check-in process, users will scan the device to the meter Once the check-in is successful, users will receive a notification message confirming the check-in, and the meter will display the relevant check-in information.

Figure D6 Check-in Activity Diagram 4.3.3 Check-out activity diagram

- This diagram describes the process of user to check-out the spot

To initiate the check-out process, the user scans their device at the meter Upon successful check-out, the user receives a notification confirming the check-in, and the meter displays the relevant check-out information.

Figure D7: Check-out Activity Diagram 4.3.4 Top-up activity diagram

- This diagram describes the process of a user top-up

- User will select the amount of money to top-up as input of process After complete payment successfully , user will be notified the latest amount of money in account

Figure D8: Top-up Activity Diagram 4.3.5 View history activity diagram

- This diagram describes the process of viewing parking history of user

- User will select Parking history to begin the process The User app will show parking history of user

Figure D9: Get History Activity Diagram 4.3.6 Verify vehicle sequence diagram

- This diagram describes the process of verifying user’s vehicle

Staff will input the brand, size, expiration date, and vehicle type for the selected vehicle Once the verification process is successfully completed, the owner can use the vehicle for check-in or check-out at the designated spot.

Figure D10: Verify vehicle sequence diagram 4.3.1 Request a refund sequence diagram

- This diagram describes the process of staff to request a refund

Staff members will input the refund amount during the refund request process Once the request is successfully completed, the manager can review the refund request and decide whether to approve or reject it.

Figure D11: Request a refund sequence diagram 4.3.1 Approve a refund sequence diagram

- This diagram describes the process of manager to approve or reject a refund

- Manager will select approve or reject as input of process If refund request is approved, user will get the money back

Figure D12: Approve a refund sequence diagram

User Interface Design

5.3 Mobile Interface Design 5.3.1 Welcome Page

No Field Name Description Read-only Mandatory Control Data Type Length

3 Logo Image logo of application

Yes Yes Textview String 30-40 characters

No Function Description Validation Outcome

1 Sign In Open Sign In page N/A Navigate to Sign In page

2 Create a new account Open Sign Up page N/A Navigate to Sign Up page

Figure D14: Sign-up Page Fields

No Field Name Description Read-only Mandatory Control Data Type Length

2 First Name Fill first name

No Yes Edit text String 1-30 characters

3 Last Name Fill last name No Yes Edit text String 1-30 characters

No Yes Edit text String 8 – 12 characters

5 Password Fill password No Yes Edit text String 6-30 characters

10 Name of page Name of page

Yes Yes Textview String 17 characters

1 Back Back to previous page N/A Navigate to Welcome page

8 Sign Up Validate all field and perform sign up

Send sign up request to server and navigate to Success page

9 Sign In Open sign in page N/A Navigate to Sign in page

Figure D15: Sign-in Page Fields

No Field Name Description Read- only

Mandatory Control Data Type Length

3 Password Fill password No Yes Edit text String 6-30 characters

7 Name of page Name of page Yes Yes Textview String 15-30 characters

No Function Description Validati on

4 Sign In Validate all field and perform sign in process

Success: Navigate to Verify page or Main page Fail: Stay and show Login fail

5 Sign Up Open sign up page N/A Navigate to Sign up page

6 Forget password Open Forget password page N/A Navigate to Forget password page

Figure D16: Forget password Page Fields

2 Phone Number Fill phone number

5 Description Request user to Yes Yes Textview String 20-40

3 Confirm Validate phone number and open verify phone number page

Navigate to verify phone number page

Figure D17: Verify phone number Page Fields

2 Confirm code Fill confirm code

No Yes Edit text String 6 characters

6 Logo Phone logo Yes Yes ImageView Image N/A

7 Notification Notify that an message is sent to user’s phone number

Yes Yes Textview String 50-70 characters

1 Back Back to previous page N/A Navigate to Forget password page

3 Confirm Validate code and perform check confirm code process

Success: Navigate Main page Fail: Show check code fail

4 Resend confirm code Request system to send a new code

N/A Server generate a new code and send to user mobile

2 Name of page Name of page Yes Yes TextView String 15-30 characters

3 Logo A gif image to show that the app is ready to check-in

A text to show that the app is ready to check- in

Yes Yes TextView String 15-30 characters

1 Back Back to previous page N/A Navigate to Forget password page

Display first name and last name of user

Yes Yes Text view String N/A

Display phone number of user

3 Profile Open profile page N/A Navigate to Profile page

4 History Open history page N/A Navigate to History page

5 Top up Open top up page N/A Navigate to Top up page

6 Sign out Perform sign out process and open Welcome page

No Field Name Description Read- Mandatory Control Data Type Length

2 Money Display money in wallet of user

Display phone number of user

7 Vehicle number Display Vehicle number

8 Vehicle plate id Display vehicle plate id

9 Car type Display type of the car

15 Logo of license plate ID

Logo of license plate ID

17 Title of money in user’ account

A text to show that the money in account is below

1 Back Back to previous page N/A Navigate to pop up menu

3 Top up Open top up page N/A Navigate to Top up page

4 Change password Open change password page N/A Navigate to Change password page

2 Time of order Display time of order

Yes Yes Text view String 15-30 characters

3 Date of order Display date of order

Display total fee of order

8 Title of location A text to show that the next text is location

A text to show that the next text is parking fee

1 Back Back to previous page N/A Navigate to pop up menu

6 History Detail Show detail of the selected order

N/A Navigate to history detail page

Figure D22: History detail page Fields

3 Car type Display type of the car

4 Vehicle number Display Vehicle number

6 Time of order Display time of order

7 Date of order Display date of order

A text to show that the next is full name of user

A text to show that the next is type of user’s vehicle

A text to show that the next is vehicle number

14 Title of location A text to show that the next text is location

15 Title of time A text to show that the next text is check-in and check-out time

16 Title of date A text to show that the next text is check-in and check-out time

A text to show that the next text is parking duration

A text to show that the next text is total parking fee

1 Back Back to previous page N/A Navigate to History page

6 Detailed of total fee Show detailed fee of the order

N/A Navigate to detailed fee pop up

Figure D23: Detail fee Page Fields

1 Time and date of order

Display time and date of order

2 Policy Display policy of the location

Yes No Text view String N/A

3 Detail fee of the order

Display detail fee of the order

5 Title of policy A text to show that the policy below

6 Title of detailed parking fee

A text to show that the detailed parking fee is below

7 Title of total parking fee

A text to show that the next text is total parking fee

5 Close detail fee pop up

Press anywhere to close detail fee pop up

N/A Navigate to history detail page

Figure D24: Change password Page Fields

2 Old password Fill old password

No Yes Edit text String >6 characters

3 New password Fill new password

No Yes Edit text String >6 characters

A text to request user to fill in blank

1 Back Back to previous page N/A Navigate to Profile page

5 Change password Validate all field and perform changing password

Success: Server change password and navigate to sign in page Fail: Stay and show fail error.

Database Design

Figure D25: Entity Relationship Diagram 6.4 Data Dictionary

Staff Member of the system that has permission to manage user, vehicle, location, policy, view orders and request refund for order

Refund Staff sends a refund request for an order to the manager Has the following attributes:

● Order id (to trace back to the original order)

When manager approve or decline when manager rejects the request:

● Request status (“Waiting”, ”Approved”, ”Rejected”)

Order Is an entity contain the information when a user makes parking transaction:

● Check-in, check-out date

Location Is an entity which holds information about the location that vehicle can park

● Is_active (used to check if the location is available for parking)

Policy Holds information about the time schedule of a location:

● Allowed parking time (to limit parking time to the parking spot )

● Vehicle types that can parking in the location with the specific prices

User Is a person who has access to the mobile application

● Phone_number (used to verify the user)

● Password (used to authenticate the user)

● Money (used in payment for the parking spot)

Order Status Describe the status of an order such as open, closed,

Describe policy of a vehicle type at a location

Order Pricing Describe rules to estimate the parking fee that applied in the order

Vehicle Type Is an entity describe the information about the types of vehicle that allowed for a specific location Exp: ”Small van, small truck, ”

Pricing Describe rules to estimate the parking fee of a vehicle type at a location

Vehicle Is an entity describe specific information of a vehicle which belongs to the user

● License plate id, vehicle number (used to verify vehicle)

Entity Attributes Description Domain Null

Staff username {PK} Username of staff account varchar(25) NO password Password of staff varchar(45) DEFAULT NULL

35 account is_deactivated Validity of account bit(1) DEFAULT NULL isManager Determine validity of this staff is manager or not bit(1) NO

The refund request is identified by a unique identifier, referred to as Request ID {PK} It includes the amount to be refunded, which is represented as a double with a default value of '0' The creation date of the refund request is recorded as a datetime, while the closure date of the refund request is also noted as a datetime, with a default value of NULL.

The order ID {PK} serves as a unique identifier for each parking order The total parking fee is recorded as a double value, while the check-in date and time for the vehicle is stored as a bigint The check-out date and time is also captured as a bigint, with the option for it to be null Additionally, the duration of the parking order is noted as a bigint, and there is a designated field for allowed parking details.

Begin time that vehicle is allowed to park bigint(20) DEFAULT NULL allowed_parking_ to

End time that vehicle is allowed to park bigint(20) DEFAULT NULL min_hour Minimun hours to estimate parking fee int(11) DEFAULT ‘0’

Order status id {PK} Identifier of order status int(11) NO name Name of order status varchar(45) DEFAULT NULL description Description of order status varchar(255) DEFAULT NULL

User id {PK} Unique identifier of each user int(11) NO

Phonenumber Phone number of user varchar(15) NO password Password of user varchar(60) NO money Amount of money in

The user’s wallet includes essential information such as the user's first name and last name, both stored as varchar(45) with default values of NULL The system tracks the validity of the user's phone number through an SMS notification field, represented as a bit(1) with a default of '0', indicating whether the account is activated Additionally, each location is identified by a unique Location ID, marked as the primary key, and includes the location name and description, both stored as varchar(255) with default values of NULL The validity of the location is also monitored through an is_activated field, represented as a bit(1) with a default of '0'.

The vehicle's unique identifier number is represented as a varchar(12), while the license plate ID is stored as a varchar(10) with a default value of NULL The brand of the vehicle is categorized as varchar(45), and its size is defined using varchar(255) Additionally, the expiration date of the vehicle is recorded as a bigint(20) with a default value of NULL Lastly, the validity of the vehicle is indicated by a bit(1) field, which defaults to '0' if not verified.

The vehicle type is identified by a unique identifier (id) and includes a name, which is a varchar with a maximum length of 45 characters Additionally, the policy is recognized by its own unique identifier (id) and specifies the allowed parking duration, marked by a bigint representing the start time for vehicle parking.

37 from allowed to park allowed_parking_ to

End time that vehicle is allowed to park bigint(20) NO minHour Minimun hours to estimate parking fee int(11) NO

Order Pricing id Unique identifier of

OrderPricing int(11) NO from_hour Period of time to estimate parking fee

Int(11) NO price_per_hour Parking fee per hour double NO late_fee_per_hour Parking fee per hour when parking too long double NO

Pricing Id Unique identifier of

OrderPricing int(11) NO from_hour Period of time to estimate parking fee

Int(11) NO price_per_hour Parking fee per hour double NO late_fee_per_hour Parking fee per hour when parking too long double NO

(weak entity) min_hour Minimun hours to estimate parking fee

System Implementation & Test

Software User’s Manual

Tiêu đề	Build Applications For Supporting To Keep Vehicles Using NFC Technology
Tác giả	Mai Vu Cuong, Dang Ngoc Trung, Nguyen Quoc Bao
Người hướng dẫn	Mr. Kieu Trong Khanh, Mr. Le Vu Truong
Trường học	Fpt University
Thể loại	Capstone Project
Năm xuất bản	2018
Thành phố	Ho Chi Minh City

Định dạng
Số trang	158
Dung lượng	4,52 MB