Professional Documents
Culture Documents
Transport Management System For Faculty of Science: Evaluation Report - Group 05
Transport Management System For Faculty of Science: Evaluation Report - Group 05
Team Members:
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
Table of Figures
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
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.
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.
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.
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.
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.
• 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.
• 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.
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,
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.
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 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.
Assign Driver
<<include>>
Assign Vehicle
<<include>>
View Request
<<include>>
Select Approvals
<<include>>
View Available
Vehicles
Select Approvals
View Available
Drivers
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
Make Request
View Profile
Retrieve meter
Check in <<include>>
readings and time
Retrieve meter
Check out <<include>>
readings and time
View Profile
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.
In the implementation phase, the previously decided programming languages are used.
These are the technologies we used to implement the system.
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.
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,
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.
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.
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.
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.
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
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.
Then the clerk can send the request (which a driver and a vehicle is assigned) to get the
approvals.
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.
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.
This is the interface of the Assitant registrar, Dean and the Vice Chancellor to approve or rejece a
request.
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.
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.
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.
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,
Those are some advantages of using Android as the language for implementing the
mobile 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.
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.
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 28:Graphs of
the driver application
4.2.3.1 Alarm Reminder System Figure 29: Messages that are received to the
lecturer
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.
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.
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.
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.
• 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.
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.
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.
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
Draw Graph
Request Model
Send Notification
Send Request
Request Adapter
API Service
Authenticate User
Shared Preference
Web Application
Approved Request Notification for User
Advanced Search