Transport Management System For Faculty PDF

TRANSPORT MANAGEMENT
SYSTEM FOR FACULTY OF

SCIENCE
EVALUATION REPORT - GROUP 05
Project Supervisor: Ms. M.A.L. Kalyani
(Department of Computer Science)
Team Members:
• K.G.S. Madushanka (SC/2014/9209) – Team Leader

• S.A.A. Amarasinghe (SC/2014/9192)
• J.P.P.M. Jayasinghe (SC/2014/9203)
• U.S. Lakmali (SC/2014/9198)
Transportation Management System for Faculty of Science (SciTMS) Group 5
Table of Contents
Table of Figures........................................................................................................................................... 3
1. Acknowledgement.............................................................................................................................. 4
2. Introduction ......................................................................................................................................... 5
2.1 Background ....................................................................................................................................... 5
2.2 Problem Definition ..................................................................................................................... 6
2.2.1 Lecturer ................................................................................................................................ 6
2.2.2 Clerk...................................................................................................................................... 6
2.2.3 Persons who approve ......................................................................................................... 7
2.2.4 Driver .................................................................................................................................... 7
2.2.5 Security Officer .................................................................................................................... 7
2.3 Scope................................................................................................................................................ 10
3.0 Requirement Analysis and Design .................................................................................................... 11
3.1 Requirement Analysis..................................................................................................................... 11
3.2 Design .............................................................................................................................................. 13
3.2.1 Use Case Diagram for Clerk ................................................................................................... 14
3.2.2 Use Case Diagram of Department Head, Assistant Registrar/Dean and the Vice
Chancellor .......................................................................................................................................... 15
3.2.3 Use Case Diagram of the Lecturer......................................................................................... 16
3.2.4 Use Case Diagram of Driver and Security Officer ................................................................ 17
3.2.5 Entity Relationship Diagram for the System ........................................................................ 18
3.2.6 Data Flow Diagram for the System ....................................................................................... 19
3.2.6.1 Level 0 Diagram ................................................................................................................ 19
4.0 Implementation .................................................................................................................................. 20
4.1 Web Application ............................................................................................................................. 21
4.1.1 Login Page of the System ....................................................................................................... 22
4.1.2 Logging as the Clerk ............................................................................................................... 23
4.1.2.1 Assigning a vehicle ........................................................................................................... 25
4.1.2.2 Assigning a Driver............................................................................................................. 26
Department of Computer Science | Group Project 1

4.1.2.3 Send the request for approval ........................................................................................ 27

4.1.2.4 Generation of report for the driver in PDF format ............................................................. 28
4.1.3 Logging as a Department head, Assistant registrar, dean or Vice Chancellor ................ 30
4.1.4 The Real Time Validation System ............................................................................................... 32
4.1.5 The Notification System ............................................................................................................. 33
4.2 Android Application ....................................................................................................................... 34
4.2.1 Logging in as a Lecturer ......................................................................................................... 34
4.2.1.1 The Automated Notification System................................................................................... 35
4.2.2.2 Checking the progress of the request ................................................................................. 36
4.2.2 Logging in as a Driver ................................................................................................................. 37
4.2.2.1 Graphs ................................................................................................................................. 37
4.2.2.2 The Automated SMS alert system ...................................................................................... 38
4.2.3.1 Alarm Reminder System ..................................................................................................... 38
4.2.4 Customized User-Friendly Navigation Drawer ........................................................................... 39
4.2.5 Application Programming Interface ........................................................................................... 40
5.0 Testing and Evaluation....................................................................................................................... 41
6.0 Future Developments......................................................................................................................... 42
7.0 References ........................................................................................................................................... 43
8.0 Appendix ............................................................................................................................................... 44

Table of Figures
Figure 1: Use Case Diagram of Clerk ...................................................................................................... 14

Figure 2: Use case diagram of the people who approve the request ......................................................... 15
Figure 3 : Use Case Diagram of the Lecturer......................................................................................... 16
Figure 4 : Use Case Diagram for Driver & Security Officer .................................................................. 17
Figure 5: Entity Relationship Diagram for the system ................................................................................ 18
Figure 6 : Login page of the System....................................................................................................... 22
Figure 7 : The home page of clerk.......................................................................................................... 23
Figure 8 : The clerk's interface to see all the requests ......................................................................... 24
Figure 9: Interface of request information to assign a driver and a vehicle............................................... 25
Figure 10 : Interface for assigning a vehicle................................................................................................ 26
Figure 11 : Interface of assigning a vehicle ................................................................................................. 26
Figure 12 : Interface for assigning a driver ................................................................................................. 27
Figure 13 : Interface for sending the request for approval ........................................................................ 28
Figure 14 : Interface of all drivers ............................................................................................................... 29
Figure 15: Interface of the Dean ................................................................................................................. 30
Figure 16: Interface of approving a request ............................................................................................... 31
Figure 17: A message box pops up to mention the reason ........................................................................ 31
Figure 18 : wrong email .............................................................................................................................. 32
Figure 19: Correct email.............................................................................................................................. 32
Figure 20: Password missing ....................................................................................................................... 32
Figure 21: Email mismatch .......................................................................................................................... 32
Figure 22: Wrong email format................................................................................................................... 32
Figure 23: Notification is shown in the Dean's page after assigning and accepted by the AR ................... 33
Figure 24: Login of the SciTMS client application ....................................................................................... 34
Figure 25: Received Notification ................................................................................................................. 35
Figure 26: Interface of the android application to check the progress ...................................................... 36
Figure 27: Login of SciTMS driver application ............................................................................................. 37
Figure 28:Graphs of the driver application ................................................................................................. 37
Figure 29: Messages that are received to the lecturer ............................................................................... 38
Figure 30: The interface for the driver to set alarm ................................................................................... 38
Figure 31: The customized user-friendly navigation drawer ...................................................................... 39
Figure 32: How API works ........................................................................................................................... 40
Figure 33: API test using Postman .............................................................................................................. 41

1. Acknowledgement
For the experience, we got and the things we have learned by doing this group project,
we are very much thankful to the Department of Computer Science. The experience we
got by gathering requirements, designing the software and implementing it and the
problems we faced and the new things we learned by solving them are valuable for the
next steps of our lives.
We have to acknowledge our supervisor Ms. M.A.L. Kalyani who helped us in many ways
providing advices and showing the weaknesses of our system time to time. And also Dr.
Tharaka S. Ilayperuma, Ms. M. A. L. Kalyani, Ms. S. M. Vidanagamachchi who were in the
presentation panels which were held in the middle of the semester provided us the
valuable comments and feedbacks to improve our project. Finally, we are very much
thankful to the persons who supported us to make this project a success.

2. Introduction
2.1 Background
Managing transportation in a University is a major thing that influences the processes of

the university. Every day, a considerable amount of vehicle check-ins and check-outs are
done by the security section at the university gate. It is essential for lecturers and the
administrative staff to go out of the University for important purposes. Managing various
visits of the staff members and lecturers of the university undergoes a considerable
process. The person who handles the assigning of vehicles and drivers for the incoming
requests does the main part of the system along with the persons who permits the visits.
It is not an easy task to assign vehicles and drivers to incoming requests. As a lot of visits
happen.
The existing Transformation Management System of the University is completely manual.

The system is based on paper works and communications between the users of the system.
After a person made a request, the clerk of the particular faculty does the driver assigning
and the vehicle assigning for a particular request after the head of the department has
given the approval for the request. After assigning a vehicle and a driver, the clerk has to
communicate with the driver after getting the approval for the request. The persons that
gives the approvals for the requests are, Vice chancellor, Dean, Assistant Registrar and the
Department Head. The approvals are given according to the destination of the request.
The person who approve depends on the destination. The clerk has to do the
communication with the driver and the persons which gives the approvals. The clerk also
has to inform the user that the request is accepted.
The security personals also play a role in the existing system. They do the recording of
meter readings of the vehicles and times every time a vehicle goes out and comes in the
University. They take the responsibility of verifying whether the request is approved by the
suitable person.
There are many identified problems to be discussed in the existing system of the University
for managing the transformation. By identifying those weaknesses, a web based
Transformation Management System is proposed to the Faculty of Science by us. It does
the management of the vehicles in the University in an efficiently way, consuming less
time. Its purpose is to provide a system for doing this vehicle management more efficiently
and accurately.

The system is web based and it also consists of an Android application for the driver and
the person who want to request a vehicle, let’s say the requester. The requester has the
ability to request a vehicle using his/her android application and see time to time whether
the request is approved or not. The web based system is basically for the clerk of the
Faculty of Science and the persons who gives the approvals for the visit. The driver can
see for what visits that he has been scheduled using his android application. The security
officer at the gate gets their part of the system too, they can use the web based system to
update the meter readings and times that a vehicle goes out and comes in.
2.2 Problem Definition
The main users of our system are the lecturer of the vehicle, the clerk, the persons who
approve the request, driver and the security personal. Let’s consider each of them,
2.2.1 Lecturer
The requester is the person who want the vehicle to the visit. He has to fill a form
to request a vehicle from the faculty in the manual system. He has to make the
request at least 2 days before to get a vehicle. He has no proper way of knowing
whether the request is approved or not. Sometimes it takes 3 days or more to get
the request which has to be accepted by the Vice Chancellor.
2.2.2 Clerk
The clerk plays the major role in the system. The clerk is the one who assigns
vehicles and drivers to a request that has been approved by the department head.
The clerk has to find the available drivers and the vehicles in the faculty to assign
them to the request. The clerk always works with paper works and it is difficult to
him/her to work with papers all the time.

2.2.3 Persons who approve
After the requester filling out the request form, he/she has to get the approval by
the department head. The department head is the first person that gives the
approval for a vehicle request. Then after the clerk assigning a vehicle and a driver
to the request, according to the destination, he has to send the form to the
Assistant Registrar/Dean of the Faculty/Vice Chancellor to get the approval. The
approving process varies according to the destination.
• Visits inside Matara District

o Assistant Registrar should approve.
• Visits inside Galle District
o Assistant Registrar, the Dean of the Faculty should approve.
• Visits above Galle District
o Assistant Registrar, the Dean of the Faculty and the Vice
Chancellor should approve.
These persons view the request form and approve/reject the request looking at the
details mentioned.
2.2.4 Driver
In the manual system, the driver plays several roles that he should not play.
Sometimes the driver is the man who hands over the request forms to the due
persons. The driver only need to play the role of the driver. The driver’s job is to
get the particular person to the required destination and bring him/her back to the
University safely.
2.2.5 Security Officer
The security officer gets the meter reading and the time when the vehicle checks
in and checks out.

Having analyzing the manual system, we have identified many weaknesses and problems.
SciTMS provides solutions for all those problems. The problems we identify are mentioned
below.
• Inefficient and time consuming
The method of requesting a vehicle is not so efficient in the existing system.

The person who needs the vehicle has to make the request before at least
two days (before at least 4 days for the requests which needs the approval
of the Vice Chancellor). The clerk has to find an available vehicle and a driver
to assign looking at the paper works.
• The excessive use of paperwork

The use of paperwork in the existing system is time consuming and it also
leads to many problems. The probability of losing is high. If a disaster
happens, there’s no way to recover the lost data. It also requires more
physical storage space to store increasing paper works. Finding a specific
information is hard. The clerk has to go through all the documents in order
to find the information he/she needs. Also, there is a possibility of losing the
documents.
• Communication weaknesses
After a request is approved by the department head, the form has to be
handed over to the clerk in order to do the rest of the process. Even after
the clerk has assigned a driver and a vehicle, the clerk has to hand over the
form to the relevant person to get the approval. Handing over the form is
not an efficient way of doing this. Sometimes the driver is the person who
hands over the form to relevant person.

• Lack of security
In the existing system, a document can be misplaced easily. Intentionally or
non-intentionally. The security of the existing system cannot be guaranteed.
With SciTMS, we provide solutions which efficiently overcomes the mentioned problems.
• No paper works needed

With the implemented system, there is no need of any paperwork. All the
functionalities are done by a complete web based system and an android
application that is given to specific users of the system.
• Automated environment
Many of the inefficient processes of the existing system are automated by
the proposed system. The users do not have to take much effort to do the
functionalities of the system as the system functions in an efficient way other
than the existing system. Also, the users can overcome the communication
weaknesses of the existing system. There will be no misunderstandings and
there won’t be any mistakes.
• Proper communication
The communications are reliable in the implemented system because all the
communications are properly handled. No miscommunication will happen
as the communications are fully automated. There is no need of sending
messages in traditional ways to inform the users of the system about the
processes.

• Accuracy of the system

The main functions of the existing system are done accurately in the
implemented system. There is no need of double checking the processes of
the system. The system takes care of the functions that are needed to be
done.
• User friendly interfaces

Simple and understandable interfaces are used in the implemented system.
Users can do the basic functionalities using the simple interfaces provided
in the implemented system.
2.3 Scope
The Transportation Management System for the Faculty of Science is proposed in the first
place to implement a system for automating the existing method of managing transports
of the faculty. The main focus of this system is to manage the transportation of the Faculty
of Science (or any other faculty). The implemented system provides many beneficiaries to
the users. Following are some of the facilities added,
o Notification System to automate the communication

o SMS Alert System
o Alarm Remainder System for the Driver
o Generating PDF reports for the Drivers
o Realtime validation
o Graphs to show analytic data.

All the lecturers and the academic staff who need transportation for academic and other
purposes are benefited from the implemented system. This includes the Vice
Chancellor/Dean and the Assistant Registrar too. All the above persons are well facilitated
with requesting a vehicle any time to their official purposes.
The users of SciTMS are benefited in many ways other than using the existing system. A
person who requests for a vehicle do not need to fill out paper works to request a vehicle.
The clerk does not need to take much effort to assign vehicles and drivers to pending
requests. The clerk also does not need to hand over the request to appropriate person to
get the approval for the request. On the other hand, the department head/assistant
registrar/dean/vice chancellor who gives the approval can see the details of the request
accurately before approving.
We automated certain functions of the existing system. We automated the whole

communication process of the existing system. The clerk does not have to find the
requests and assign vehicles one by one checking whether the vehicles/drivers are
available or not. Also, the persons that approves the request are benefited. When a request
is needed to be approved, they are shown the accurate data of the appropriate request.
There is no chance of happening mistakes. The approvals can be given easily by checking
the correct data. With a single click, they can approve a request. Also, the security officer
does not have to take use paper works to record the meter readings and times when a
vehicle goes out and comes in.
3.0 Requirement Analysis and Design
3.1 Requirement Analysis
Our main method of requirement gathering is interviewing. We interviewed the clerk of

the Faculty of Science first. By interviewing her, we elicited the basic requirements of the
process of assigning a vehicle and a driver to a request.

Then we interviewed the Dean of the Faculty of Science and got the information about
what are the reasons of rejecting a request and more about the approving process.
We also interviewed the Department Head of the Department of Mathematics to know

what are the reasons to accept a request and reject a request and other details of the
process.
We also interviewed a driver of the Faculty to know what are the tasks he had to do in this
process.
There were some unclear requirements there too. So, we got them cleared by meeting the
clerk again and asking questions.
Finally, we were able to provide a better solution for the problems we identified through
requirement analysis process.

3.2 Design
We started designing the system by analyzing the requirements, using UML diagrams we
represented the functionality and how the data flows in the system. And an ER diagram to
represent the database of the system. Following are the diagrams.
1. Use Case Diagrams
2. ER Diagram of the Database
3. Data Flow Diagram

3.2.1 Use Case Diagram for Clerk
Assign Driver
<<include>>
Assign Vehicle
<<include>>
View Request
<<include>>
Select Approvals
<<include>>
View Available
Vehicles
Select Approvals
View Available
Drivers
Figure 1: Use Case Diagram of Clerk

3.2.2 Use Case Diagram of Department Head, Assistant Registrar/Dean and the Vice
Chancellor
Reject Request
<<include>>
View Request
<<include>>
Approve Request
Figure 2: Use case diagram of the people who approve the request

3.2.3 Use Case Diagram of the Lecturer
Make Request
View Profile
Check for Approval
Figure 3 : Use Case Diagram of the Lecturer

3.2.4 Use Case Diagram of Driver and Security Officer
Retrieve meter
Check in <<include>>
readings and time
Retrieve meter
Check out <<include>>
readings and time
View Profile
Set Reminders <<include>> View Tours
Figure 4 : Use Case Diagram for Driver & Security Officer

3.2.5 Entity Relationship Diagram for the System
Figure 5: Entity Relationship Diagram for the system

3.2.6 Data Flow Diagram for the System
3.2.6.1 Level 0 Diagram

4.0 Implementation
First of all, we had to decide what programming languages should we use to design and
implement this system. After discussing with all team members, we came to a conclusion
of using the “Laravel PHP Framework” to build our web application. Other than we had to
see whether we use raw PHP or a framework comparing with the time period we had given
to deliver the product. Laravel consists of necessary capabilities of with a vast amount of
built in functions. And there are many external libraries for the Laravel Framework that
can be installed on the web. That was an advantage of using Laravel Framework instead
of raw PHP.
We chose “Android” as the platform to implement our mobile applications because it is

the most popular mobile platform of Sri Lanka nowadays other than Apple and Windows.
And there is also a rich IDE (Android Studio) which can be used to implement android
applications. It supplies all the requirements to implement an android application from
the lowest level. It provides access to almost all the functionalities in an android mobile
device to the programmer. In android studio, Java programming language is used in
Android application implementation, which is a known programming language of all our
group members.
In advance of Laravel Framework and Android, we used HTML, CSS, Bootstrap,

JavaScript, Blade, and MySQL to implement our system.
Google “Firebase” is also used for the notification system.
In the implementation phase, the previously decided programming languages are used.
These are the technologies we used to implement the system.
o Programming Languages : PHP 7, HTML5, CSS, Bootstrap, JavaScript, jQuery,

Ajax, Blade, Native Java
o Database Technologies : MySQL v5.6, Eloquent ORM
o IDEs : Android Studio 2.3
o Web server : Apache server
o Web Application Libraries : Dingo, Laravel-fcm, JSON Web Token Auth, Twilio,
consoletvs charts, Laravel dompdf
o Android Libraries : Retrofit, Okhttp3, gson, support design,
MPAndroidChart

o Text Editors : Sublime Text 3, Atom, Visual Studio Code
The web application and the Android application need to be working together to
demonstrate the flow of the system. But in the following part, the two applications are
separately described.
4.1 Web Application
We used Laravel PHP Framework and the Apache server to implement the web application
because it has a rich documentation and ability to use a variety of libraries. As the database
technology, we used MySQL which comes with WAMP. Both of them are open source and
free. We could easily download them and use. We also had to build our own “Application
Programming Interface(API)” to handle the data passing between the web application and
the Android application. Ajax and jQuery languages are used for the notification system
and we added the “DINGO API” library to the Laravel Framework to get the API up and
running. “Google Firebase”, Google’s mobile platform is used in the notification system.
Following are some other advantages of using the mentioned languages,
o Bootstrap CSS styles are responsive, can be used in any device.

o Laravel Framework works according to “Model-View-Controller (MVC)”
architecture which is very easy to understand.
o Application Programming Interface can be easily implemented using “Dingo”
library in Laravel.
o Multiple authentication can be achieved easily with Laravel.
o Advanced functions like PDF generation can be done with Laravel.
o The ability of Ajax to refresh a web page in the background.
Those are some advantages of using those languages.

4.1.1 Login Page of the System
Figure 6 : Login page of the System
This is the login page for the system. A basic idea about the system is given in the page with a
brief description below the form box. The login is capable of authenticating multiple users. All
the uses of the system (i. e: Lecturer, Department Head, Assistant Registrar, Dean, Vice
Chancellor) can enter the system by the same login.

4.1.2 Logging as the Clerk
After a lecturer have sent a request asking for a vehicle to the clerk, the clerk has to assign a
driver and a vehicle for the request and send the request for approval. The request is approved
by the department head of the lecturer prior to the assigning a driver and a vehicle.
Figure 7 : The home page of clerk
This is the home page of clerk. The clerk can see some summarized information in this page
about the work he/she do.
Ex: Available vehicles, available drivers, pending requests that are waiting to be assigned.
The sidebar on the left side is used to navigate through the pages that are belong to the clerk.

Figure 8 : The clerk's interface to see all the requests
The clerk can see all the requests by navigating to the Requests page. He/She also can see the
requests which are approved by the department head of the department of the lecturer who
requested the vehicle. And also, the requests which got all the approvals are displayed.
The clerk can assign a vehicle and a driver to a selected request by clicking the view button at
the end of every request.
After clicking the view button on the end of the request in the table, the clerk gets the interface
that shows the information of the request to assign a driver to the request.

Figure 9: Interface of request information to assign a driver and a vehicle
4.1.2.1 Assigning a vehicle
Then the interfaces of assigning a driver, assigning a vehicle are the page shows all the available
drivers in the faculty at the moment.

Figure
Figure 10
11 :: Interface
Interface for
of assigning
assigning aa vehicle
vehicle
4.1.2.2 Assigning a Driver
Then the clerk gets the page to assign a driver to the request. This page shows all the available
drivers in the faculty. After assigning a driver and a vehicle, the clerk has to check the destination
of the request to select the appropriate persons to approve the request.

Figure 12 : Interface for assigning a driver
4.1.2.3 Send the request for approval
Then the clerk can send the request (which a driver and a vehicle is assigned) to get the
approvals.

Figure 13 : Interface for sending the request for approval
4.1.2.4 Generation of report for the driver in PDF format
The clerk can also do the report generating for the drivers in the system. The system provides the facility
to generate a PDF document including some basic information of the drivers travel history. The clerk can
choose an appropriate time period and generate the PDF that contains the data of the specified time
period only.
The PDF report contains the following information,
• Name of the driver

• Address of the driver
• Mobile number of the driver
• Email address of the driver
• In the specified date period,
o Total distance travelled
o Number of journeys
o The name and the distance of the longest journey

Figure 14 : Interface of all drivers
Figure 12: The view of the PDF record

4.1.3 Logging as a Department head, Assistant registrar, dean or Vice Chancellor
After the clerk selecting the appropriate persons to approve after looking at the destination of
the request, the request is sent to those people. Let’s assume the destination is Colombo. Then
the request has to be accepted by all the 3 persons (i.e.: Assistant registrar, dean and the vice
chancellor). The request is received by the Assistant registrar first, a notification will be sent to
her page so that she can know a new request has arrived. Only after she approved the request, it
is then sent to the dean of the faculty. He can also approve of reject looking at the information
of the request. After the dean has approved the request only, the request is sent to the Vice
Chancellor’s page for approval. After the approval of the Vice Chancellor. What happens next is
discussed further in the topic about the android application.
All the requests are shown on every interface. Even the rejected requests. The authority can
select any past request from the table by filtering according to the name, date, and the
destination of the request.
Figure 15: Interface of the Dean

Figure 16: Interface of approving a request
This is the interface of the Assitant registrar, Dean and the Vice Chancellor to approve or rejece a
request.
Figure 17: A message box pops up to mention the reason
When a request is rejected by a person, the reason must be entered so that the lecturer who requested
the vehicle gets to know why the request was rejected.

4.1.4 The Real Time Validation System
Both client side and the server-side validation is used in the system so that the wrong data
are not entered to the system in any way. For the client-side validation, we used Parsley
java script validation library. For the server-side validation, the inbuilt Laravel server-side
validation system is used.
Figure 18 : wrong email
Figure 19: Correct email
Figure 21: Email mismatch Figure 20: Password missing
Figure 22: Wrong email format

4.1.5 The Web based Notification System
The system uses a notification system to make the communication of the process more efficient.
Whenever the clerk sends the request for approval, whenever a request is approved, a notification is sent
to the persons who approve the request and the lecturer who requested the vehicle.
Figure 23: Notification is shown in the Dean's page after assigning and accepted by the AR
After clicking on the notification, the request can be viewed and accept/approve if the user is the
department head, Assistant registrar, Dean or the Vice Chancellor.
Otherwise if the notification is received by the lecturer who requested the vehicle, he can see the details
of it.

4.2 Android Application
We used the most popular mobile platform of the world now, Android to implement the
mobile application for the system. There are many reasons of using Android,
o Most of the people has an Android powered phone.

o Android is easy to work with.
o There is a rich IDE (Android Studio) for programming Android applications.
o Google Firebase can be easily integrated with Android Studio.
o There are many libraries that supports Android Studio.
o Vast amount of inbuilt methods.
Those are some advantages of using Android as the language for implementing the
mobile application.
4.2.1 Logging in as a Lecturer
A lecturer can make a request to get a vehicle for the official

purposes. With SciTMS, the lecturer can make the request using his
Android mobile phone. He just has to install the SciTMS client
application and enter the email and the password that are given to
him by the University. The figure shows the login page of the SciTMS
client application.
After the lecturer sent the request, the earlier mentioned process
happens and whenever the request is approved, a notification will be
sent to the lecturer ride away so he can know that the request is
approved.
Figure 24: Login of the SciTMS

client application

4.2.1.1 The Automated Notification System
When a sent request is approved, the lecturer who sent the request gets a notification saying that the
request he sent had been approved and you are clear to go on this date. If the request is rejected, the
notification will say, the request has been rejected with the reason for rejection. The following figures
show the received notification and the interface that is shown by the application when the notification is
clicked.
Figure 25: Received Notification

4.2.2.2 Checking the progress of the request
In the traditional system, the lecturer has to call and ask whether the request is approved or not. But
with the SciTMS Android application, the lecturer can check the progress of the request he sent any time
by logging in to the application.
Figure 26: Interface of the android application to

check the progress

4.2.2 Logging in as a Driver
An Android application is also built to the driver. It is

very convenient because the driver can use a phone
better than a computer with the job he does. The
dashboard of the Driver application provides some
summarization of the data of him. For instance, the total
distance he travelled, how many times he has travelled,
and the monthly record of monthly requests that he
worked for.
Figure 27: Login of

SciTMS driver
application
4.2.2.1 Graphs
The graphs in the

dashboard of the
driver shows his
historical data such
as the total distance
he travelled, how
many times he
travelled the
number of monthly
requests.
Figure 28:Graphs of
the driver application

4.2.2.2 The Automated SMS alert system
In addition to the notification system, improving the reliability a

SMS system is also included for the application. When a request
is accepted, along with the notification, a Short Message will
automatically be sent to the lecturer and the driver.
4.2.3.1 Alarm Reminder System Figure 29: Messages that are received to the
lecturer
Figure 30: The interface for the driver to set

alarm

As soon as he gets to know the date and time that he has to go, in case of forgetting, he can set a
reminder alarm to make it easy. The alarm rings whenever the time the driver sets the alarm.
4.2.4 Customized User-Friendly Navigation Drawer
Most of the Android applications come with a navigation drawer to navigate between the activities of
the application. Most of them are very complex and the user gets confused sometimes. For the android
applications of the SciTMS, we designed a simple and handy navigation drawer to navigate between the
activities of the application.
Figure 31: The customized user-friendly

navigation drawer

Using this drawer in the Driver’s application, we can switch between the dashboard, the requests that
has been approved by the faculty and scheduled to go and the driver’s profile.
4.2.5 Application Programming Interface
The API acts as a middle layer to make the connection between the database and the
mobile application. We implemented it using the “Dingo API” library which comes handy
with the Laravel PHP Framework. The API restricts the mobile application from accessing
the whole database, it provides only the essential data from the database to the mobile
application.
Figure 32: How API works

5.0 Testing and Evaluation
The development process of the system we used is “Agile Methodologies”. As we

subdivided our system functionality into modules, each module was tested separately for
their better functionality. Then the entire modules were integrated and tested for the full
functionality of the system.
• The web application was tested in Google Chrome, Firefox and UC Browser.
• The Android application was tested on Huawei P9(flagship), Samsung Galaxy
Grand 2(mid-range) and Sony M (low-end) Android mobile devices.
• The API was tested using POSTMAN 4.710.7. It is an API testing tool that
helps the tester to test the API in a convenient way.
Figure 33: API test using Postman

6.0 Future Developments
We hope to introduce some other features to the system.
1. Implement Android applications for Assistant Registrar, Dean of the Faculty and the
Vice Chancellor of the University so they can approve of reject a request at any
time (Even when they are not in the chair).
2. Implement a fingerprint scanner for the Android application to secure the process
of giving approval for the requests.
3. Implement a web system for generating the Audit record monthly.
o Handling audit records is a critical activity. It has to be done very carefully

and securely. No wrong data should be submitted to the audit records.
4. Use a hardware device to read the meter reading of the vehicle automatically.
o It is not efficient for the security officer to come near the vehicle every time
to check the meter reading of the vehicle. If there is a way that the security
officer can automatically obtain the mater reading of the vehicle when the
vehicle arrives to the gate, it would be very convenient.
5. Improve the system for whole University System.
o Making the system only for the Faculty of Science was not the expectation.
The expectation was to make the whole transportation management system
of the university computerized. We expect to develop the system for the
whole university in the future.
6. Use GPS tracking to track the vehicle when it is out and monitor.
o There is no guarantee where the vehicle goes when it is out. By setting a
GPS tracker to the vehicle, the responsible persons can monitor the vehicle.

7.0 References
o https://firebase.google.com/
o https://stackoverflow.com/
o https://www.youtube.com/
o https://laravel.com/
o https://github.com/
o https://www.w3schools.com/
o https://coolors.co/
o http://laravel-recipes.com/
o http://getbootstrap.com/
o https://laravelcollective.com/

8.0 Appendix
Manifest.XML

Login Interface XML Part 1



Navigation Drawer Part 1




Draw Graph

Request Model

Send Notification

Send Request

Load Request List

Request Adapter

API Service

Authenticate User

Shared Preference
Web Application
Approved Request Notification for User

Load Unseen Notification

Choosing Person to Approve Request

Advanced Search

Transport Management System For Faculty PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Transport Management System For Faculty PDF

Uploaded by

Copyright:

Available Formats

TRANSPORT MANAGEMENT

SYSTEM FOR FACULTY OF

Project Supervisor: Ms. M.A.L. Kalyani

(Department of Computer Science)

• K.G.S. Madushanka (SC/2014/9209) – Team Leader

Department of Computer Science | Group Project 1

4.1.2.3 Send the request for approval ........................................................................................ 27

Department of Computer Science | Group Project 2

Figure 1: Use Case Diagram of Clerk ...................................................................................................... 14

Department of Computer Science | Group Project 3

Department of Computer Science | Group Project 4

Managing transportation in a University is a major thing that influences the processes of

The existing Transformation Management System of the University is completely manual.

Department of Computer Science | Group Project 5

2.2 Problem Definition

Department of Computer Science | Group Project 6

2.2.3 Persons who approve

• Visits inside Matara District

2.2.5 Security Officer

Department of Computer Science | Group Project 7

• Inefficient and time consuming

The method of requesting a vehicle is not so efficient in the existing system.

• The excessive use of paperwork

Department of Computer Science | Group Project 8

• No paper works needed

Department of Computer Science | Group Project 9

• Accuracy of the system

• User friendly interfaces

o Notification System to automate the communication

Department of Computer Science | Group Project 10

We automated certain functions of the existing system. We automated the whole

3.0 Requirement Analysis and Design

3.1 Requirement Analysis

Our main method of requirement gathering is interviewing. We interviewed the clerk of

Department of Computer Science | Group Project 11

We also interviewed the Department Head of the Department of Mathematics to know

Department of Computer Science | Group Project 12

1. Use Case Diagrams

2. ER Diagram of the Database

3. Data Flow Diagram

Department of Computer Science | Group Project 13

3.2.1 Use Case Diagram for Clerk

Figure 1: Use Case Diagram of Clerk

Department of Computer Science | Group Project 14

Department of Computer Science | Group Project 15

3.2.3 Use Case Diagram of the Lecturer

Check for Approval

Figure 3 : Use Case Diagram of the Lecturer

Department of Computer Science | Group Project 16

3.2.4 Use Case Diagram of Driver and Security Officer

Set Reminders <<include>> View Tours

Figure 4 : Use Case Diagram for Driver & Security Officer

Department of Computer Science | Group Project 17

3.2.5 Entity Relationship Diagram for the System

Figure 5: Entity Relationship Diagram for the system

Department of Computer Science | Group Project 18

3.2.6 Data Flow Diagram for the System

3.2.6.1 Level 0 Diagram

Department of Computer Science | Group Project 19

We chose “Android” as the platform to implement our mobile applications because it is

In advance of Laravel Framework and Android, we used HTML, CSS, Bootstrap,

Google “Firebase” is also used for the notification system.

o Programming Languages : PHP 7, HTML5, CSS, Bootstrap, JavaScript, jQuery,