Vous êtes sur la page 1sur 19

CHAPTER 4

SYSTEM DESIGN

4.1 Introduction

Creation of system design is important in understanding the flow of system


development. In this chapter will explain about the system design about E-Fine system
base on the requirement that has been achieved before. This chapter will briefly explain
the whole system design through use case diagrams, sequence diagrams, activity
diagrams, and database design. It also covers the explanation about the component of the
system itself, such as the actors, module, and activity that will be done in the desired
system.

4.2 System Architecture Design

E-Fine system will be run by three actors. They are Security Unit administrator,
Security Unit officer, and owner of the vehicle that called applicant. The administrator is
worked as the person who will key-in the registration of new sticker from the user which
is the owner of the vehicle. The officer works as a person who collects the mistakes that
have been done by the user. Lastly, the applicant has to register a UTM vehicle sticker
30

that has been put RFID passive tag inside every year, following the semester session for
their vehicle. It is a proved as a sign that they are always in UTM environment whether
as a lecturer, UTM staff, students, or any other worker inside UTM.

E-Fine system is divided into two general parts. They are web based system and
E-Fine application itself that will be built in PDA. The web based system can be
accessed by the administrator to manage the E-Fine system itself. The web based system
also can be accessed by the applicant to check the fine charge and submit the appeal
letter. The submission of the letter is as a consideration to decrease the charge of fine.
The charge of fine can be decreased if the appeal letter is approved during three days
after fine has been declared. Secondly, the E-Fine application that will be built in PDA is
used by the officer only. It is used to submit the type of violation into database by
GPRS/GSM. Before that, it is used to receive a code from RFID passive tag through the
RFID reader by using Bluetooth connection.

Figure 4.2.1 shows system architecture design to have a clearly understanding of


E-Fine system.
31

Figure 4.2.1 System Architecture Design


4.3 Use Case Diagram

As mentioned before, there are three actors that will run the system such as
administrator, officer, and applicant. Each use case will describe the action of each actor.
It helps to describe clearly the action of each actor.

4.3.1 Administrator

Administrator is the one who understands how the system work and manage the
system. There are five modules to be created for an admin: login, manage staff, manage
role and manage configuration. Login is needed to validate the right person to enter the
system. The admin will have a default username and password to login into the system
in the beginning. The changing into another username and password can be changed
later. Second, the admin need to manage staff. Manage staff means to register the staff in
security unit office and update the data that is related to the staff profile. It is used to
arrange the update information system, those staff is act as a delegate admin. Manage
role is needed also so that the admin can decide which one can be accessed by user only,
or staff only. Lastly, manage configuration is defined by admin to create how the system
can work properly. It is related to connect the system with database, manage how long
the time that is needed during login situation, or any other connection that related to the
system. Figure 4.3.1 shows the use case of administrator.
32

uc Use Case Model

Login

Manage Staff

Manage Role

Admin

Manage Configuration

Figure 4.3.1 Use Case Diagram of Administrator

4.3.2 User

User that is mentioned here consists of two types: staff universities and students.
Figure 4.3.2 shows the module that can be done by user. Firstly, the user has to register
their vehicle to get the RFID UTM sticker. The registration follows the session of
semester per year. They fill the form and submit to security unit staff to get the sticker.
The information in that form is entered into the system by security unit staff that we
called as a delegate administrator. The user can access the web based system after the
account has been registered to check whether any summons that they have to pay or not.
The user can appeal to that summons during 3 days after summons has been made. Also
they can change their password after they get the account.
33

uc Use Case Model

Login

View Summons

User Appeal

Change Ow n
Passw ord

Figure 4.3.2 Use Case Diagram of E-Fine Applicant

4.3.3 Delegate Administrator

The guard that acts as delegate administrator is the one who has task in the
security unit office. It is different from the administrator side. As a delegate
administrator there are some tasks to do: login, register user, view summons, update
status summons, update status appeal, update charge and change own password. Login is
same as another actors that need to login with their username and password account. It is
needed to make sure that the system in a secure system. After login into the system, the
delegate admin will register the user first. Moreover, the delegate admin can view
summons, update status summons to check whether the summons has been paid or not,
update status appeal to decide whether the appeal is accepted or not, and update charge
34

whether the charge is decreased after appeal is accepted. Lastly, the delegate admin can
also change their password. Figure 4.3.3 shows the activity clearly.

uc Use Case Model

Login
Register User

View Summons

Update Status
Summons

Delegate Admin

Update Status Appeal

Update Charge

Change Ow n
Passw ord

Figure 4.3.3 Use Case Diagram of Delegate Admin

4.3.4 Guard on Duty

Guard on duty is the one who goes around to check the traffic condition. They
use PDA. The tasks that they need to do are to create a summons if there is any violation
happened. It is done by getting the RFID tag number from vehicle sticker, transfer to
35

PDA and choose the type of violation. Finally, they need to print the summons receipt as
evidence that summons has been made by the user. Figure 4.3.4 shows the module.

uc Use Case Model

Login

Get RFID Tag No.

Guard On Duty Choose Violation

Print Summons
Receipt

Figure 4.3.4 Use Case Diagram of Guard on Duty

4.4 Sequence Diagram

Sequence diagram shows interaction between each entity with their function
based on certain scenario. This sequence diagram is important in understanding the flow
of the system. It is representative of each use case diagram that has been described
before. There are nine general diagrams that will be detailed in this section.
36

4.4.1 Login

Figure 4.4.1 shows the sequence diagram from login use case. This is a kind of
login flow that is done by user. The user enter the username and password from their
account. The system checks it into database whether it is valid or not. After validation
the system will allow the user to enter the main menu.

sd Interaction

LoginForm Database MainMenu

User

enterAccount(ID,password)

checkID&password()

validate()
enterSystem()

Figure 4.4.1 Login

4.4.2 Manage Role

Manage role means manage which authority that has to be assigned to the admin
itself, user and staff in office. For example, the admin can do everything into the system,
the delegate admin can update the status of summons, or the user only can view the
summons, can not delete it. The activity shows in figure 4.4.2.
37

The admin select the role that is needed to be assigned then assigned in to the
appropriate user. The system will give a confirmation to the admin if the role has been
successful assigned. Finally the system will save and update it to the database.

sd Interaction

Role Database

Admin

selectRole(user)

assign()
confirm()

save&update()

Figure 4.4.2 Manage Role

4.4.3 User Registration

The system only can be applied to the user that has been registered. The user has
to register to get the UTM RFID sticker in Security Unit office. The guard that acts as
delegate admin will register the user. Figure 4.4.3 shows the interaction.

The delegate admin select the registration form in main menu. The system then
will request the form that has been stored in database. The database accept the request
and display the form. Then the delegate admin fill the form and it will be checked
automatically. If there is any information that is not complete, the system will display it
38

to the delegate admin. But if it is completed, the system will save and update to the
database.

sd Interaction

Registration Form Database

Delegate Admin

selectRegistrationForm()

requestForm()

displayForm()

fillForm()

check()
save&update()

Figure 4.4.3 User Registration

4.4.4 Get RFID Tag Number

Figure 4.4.4 shows how to get the RFID tag number between PDA and RFID
reader activity. The bluetooth technology communication will be used here. To have a
connection, each device has to establish the connection first so then transferring data can
be done between them.
39

sd Interaction

PDA RFID Reader

Guard On Duty

requestRFIDTagNo()

openBluetooothConnection()

openAccept()

getRFIDTagNo()

display()

Figure 4.4.4 Get RFID Tag Number

4.4.5 Create Summons

The guard that is going around can create the summons on the spot. After get the
RFID tag number, the guard choose what type of violation that has been done. Both of
RFID tag number and type of violation will be submitted at that time into database.
Figure 4.4.5 shows the interaction.
40

sd Interaction

Main Menu Database

Guard On Duty

selectViolation()

submitSummons(RFIDtagNo,violationType)

Figure 4.4.5 Create Summons

4.4.6 Print

The guard can print the receipt as evidence of summons that has been created.
There are two details that are going to be printed: vehicle plat number and violation
type. After submit the summons, summons information that consists of plat number of
vehicle and violation type is appeared on the screen. Then the guard will print it. Figure
4.4.6 shows the interaction in the print activity.
41

sd Interaction

Main Menu Summons Info Database

Guard Around

selectSummons()

viewPlatNo&Violation()

requestPlatNo()

display()

print(violationType,platNo)

Figure 4.4.6 Print

4.4.7 View Summons

Summons can be viewed by the actors. The user can check what type of violation
that has been made. Figure 4.4.7 shows the activity.

sd Interaction

SummonsMenu Database

User

selectSummons(summonsID)

requestSummons()

display()

Figure 4.4.7 View Summons


42

4.4.8 Appeal

The user can appeal by online during 3 days after getting summons. After 3 days
then an appeal is can not be done anymore. An appeal form is provided to fill in by the
user. Figure 4.4.8 shows appeal flow.

sd Interaction

AppealForm Database

User

selectAppealForm()

fillForm()

save()

Figure 4.4.8 Appeal

4.4.9 Update Charge

Update charge is done after the delegate admin accept the appeal. It reduces
summons charge from the usual price which is RM 25 to be come less than RM 25 based
on the violation type that has been done. Figure 4.4.9 shows the update charge activity.
43

sd Interaction

Charge Info Database

Delegate Admin

viewCharge()

requestChargeInfo()

display()

editCharge()

save&update()

Figure 4.4.9 Update Charge

4.5 Database Design

Database is used to store all the data that is required in the system. It includes all
of the requirements about the actors and data input. MySQL is one of database
management system (DBMS) that will be used in this system. The database design has
to be done before created the system. It is used to reduce the redundancy in the system.
Figure 4.5 describes each entity and relation between them.
44

Figure 4.5 Database Design


45

4.6 Interface Design

Interface design is needed to describe how is the system will look like. In this
section there are two designs for E-Fine system: design that appears in the PDA
application and web page content design.

4.6.1 PDA Application Design

PDA application is one part that is going to be built in developing E-Fine system.
The design is a plan to build the real system. The design includes login page and main
menu of the system. It designs more simple since the PDA has small screens and to
reduce the number of clicking function. It is going to build for the aim of convenience
by the guard that used to take a summons around. Figure 4.6.1 shows the interface in
PDA.

Figure 4.6.1 PDA Application Design


46

4.6.2 Web Page Navigation

Web page is another part that is going to be built in E-Fine system. The web page
navigation design has to be done before do develop the system. It is used to understand
briefly how the web page will be built. It will make the development phase can be easier
to be built.

There are 4 web pages that are going to be built. It consists of login page, and 3
different pages for each actors which is admin, delegate admin, and user. All of the
actors will have the same function which is login before entering the system. After
entering the system then the web page will appear based on different type of actors.
Figure 4.6.2 will show clearly about the web page content.

Figure 4.6.2 Web Page Navigation

4.7 Chapter Summary


47

System design is one phase of prototyping methodology that has to be done in


developing the E-Fine system. The existence of this phase is to describe how the system
that wanted to be built looks like. It helps any level of user to understand about the
system and easier to redesign if there is any requirement that is not fulfil before the
implementation phase is being done.

In this chapter, the system design has been completed in order to fulfil
preparation before building the implementation phase. It consists of system architecture
design for the overall design, database design, use case diagrams, sequence diagrams,
and activity diagrams. Hopefully the design can be described clearly about the E-Fine
system.