WOLKITE UNIVERSITY

A Car Rental System

A Class Project Documentation Submitted to Course Instructor
For
Software Design Architecture Course
Group 8 Members ID
1. Habtamu Ababu CIR/170/06
2. Muhdin Akmel CIR/277/06
3. Kindu Teklu CIR/207/06
4. Dinaol Dejene CIR/115/06
5. Tigist Desta CIR/355/06
Supervised by Muluken
Collage of Computing and Informatics
Wolkite University, Wolkite, Ethiopia.

1
Contents
1. Introduction.........................................................................................................................................3
1.1. Overview.....................................................................................................................................3
1.1. Purpose........................................................................................................................................4
1.2. Intended Audience.......................................................................................................................4
1.3. Scope...........................................................................................................................................4
1.4. Definitions, acronyms and abbreviations.....................................................................................5
1.5. References...................................................................................................................................5
1.6. Document Structure.....................................................................................................................5
2. Design Considerations.........................................................................................................................6
2.1. Design Goals...............................................................................................................................6
2.1.1. Integrity...............................................................................................................................6
2.1.2. Accessibility........................................................................................................................6
2.1.3. Scalability............................................................................................................................6
2.1.4. Availability...........................................................................................................................6
2.1.5. Throughput..........................................................................................................................6
2.1.6. Maintainability....................................................................................................................7
2.1.7. Reliability.............................................................................................................................7
2.1.8. Reusability...........................................................................................................................7
2.1.9. Portability............................................................................................................................7
2.1.10. Traceability of requirements................................................................................................7
2.1.11. Fault tolerance.....................................................................................................................7
2.1.12. High performance................................................................................................................7
2.1.13. Well-defined interfaces........................................................................................................7
2.1.14. Ease of learning, remembering and use...............................................................................8
2.1.15. Readability...........................................................................................................................8
2.1.16. Increase productivity...........................................................................................................8
2.2. Design Trade-offs........................................................................................................................8
2.2.1. Functionality v. Usability.....................................................................................................8
2.2.2. Performance v. portability....................................................................................................8
2.2.3. Security v. Usability............................................................................................................8

2
 2.3. Assumptions and Dependencies...................................................................................................9
2.3.1. Related software or hardware:.............................................................................................9
2.3.2. Operating systems:...............................................................................................................9
2.3.3. End-user characteristics:......................................................................................................9
2.4. General Constraints...................................................................................................................10
2.4.1. End-user environment:.......................................................................................................10
2.4.2. Availability or volatility of resources:................................................................................10
2.4.3. Standards compliance:.......................................................................................................10
2.4.4. Interface/protocol requirements:........................................................................................10
2.4.5. Security requirements........................................................................................................11
The SDMS shall utilize HTTPS communication to ensure data confidentiality.................................11
2.4.6. Memory and other capacity limitations:.............................................................................11
2.4.7. Performance requirements:................................................................................................11
3. System Decomposition......................................................................................................................11
3.1. Architecture of the System.........................................................................................................12
3.2. System Decomposition..............................................................................................................12
3.3. Layers & Partitions....................................................................................................................13
3.4. Persistent data management.......................................................................................................13
4. Access control and security...............................................................................................................14
5. User interface design.........................................................................................................................15
6. Design details....................................................................................................................................25
6.1. Class diagram............................................................................................................................25
6.2. Detail design..............................................................................................................................26

Table 1 access control...............................................................................................................................15

Table 2 control input.................................................................................................................................23
Table 3 admin class....................................................................................................................................25
Table 4 class mov't manager.....................................................................................................................26
Table 5 class mechanic..............................................................................................................................27
Table 6 class finance manager...................................................................................................................27

3
Figure 1 architecture.................................................................................................................................12
Figure 2 database......................................................................................................................................14
Figure 3 admin home.................................................................................................................................16
Figure 4 customer registration..................................................................................................................17
Figure 5 booking........................................................................................................................................18
Figure 6 admin login..................................................................................................................................19
Figure 7 admin home.................................................................................................................................20
Figure 8 HR manager home.......................................................................................................................21
Figure 9 mechanic home...........................................................................................................................22
Figure 10 movement manager home........................................................................................................23
Figure 11 class diagram.............................................................................................................................25

4
1. Introduction
1.1. Overview
This system will allow for three types of users: staff members, customers, and administrator.
Guests will be able to browse location, availability, price, and model. Members customers will
have their personal information stored (i.e. name, address, and other information.) and will have
access to any specials. The administrator can change or update car models, prices & add or
remove employees.
1.1. Purpose
The main purpose, to make this system is to over come of problems of database handling,
maintain registers of members, bookings, and information about worker and customers of the
company.
This system is developed to solve the problems that usually happen when citizens and tourists
want to rent a car all activities are done manually which is no record have done on computerize
or on mobile technology. So, they have many problems using this existing way of process. A
web application is an application that is accessed over a network such as the Internet or an
intranet. Therefor with this new method, the process will be more efficient and the safety of
hiring car is secure. It's also the best way to increase the quality of management and can reduce
the time constraints.
1.2. Intended Audience
This SRS is meant basically for our 2nd semister final project report of Software Design and
architecture course. Besides, it is obviously targeted for the managers of the agency;, the client,
to get and overall description and advantage of the proposed system over the existing manual
system.
1.3. Scope
The users of this application are customers who want to rent car, and the staffs. The system has a
few functions which stated as below
1. Able to recommend car to be rented by the users based on the three
requirements which are budget, number of passenger(s) and distance.
2. Provide car catalog for users as an alternative for them to select car if
they want to choose car by their OWIL

5
 3. Functioned in adding, deleting, updating and searching the data or
information depends on the security level.
4. Allows the organization to search user information from the database
based on the user's identification card number.
5. Produce reports of payment receipt, renting information and car
reservation information.
1.4. Definitions, acronyms and abbreviations
 CS: Customer Service Module
 WP: Customer Web Portal
 FM: Fleet Management
 RA: Reports and Analytics
 MVC: model view controller
 Emp: Employee:
 Man: Manager
 Cus: Customer:
 Admin: System Administrator

1.5. References
Books used as reference :
 Software engineering – R.S.Pressman
 PHP For Dummies
 PHP Begineers by McGrawhill Peblication
 JavaScript By McGrawhi;; Publication

1.6. Document Structure

The system is devided in to three phases
 The first phase involves the grouping of car rental locations into pools, allowing ca rental
locations within a pool to share a fleet of vehicles.

6
  In the second phase, the types and quantities of vehicles to be acquired and returned to
the car manufacturer and the geographical redistribution of vehicles among pools over the
long term planning horizon are defined for each pool
 The final phase involves the daily operations in which the deployment of the fleet within
each pool among its location defined.
2. Design Considerations
Different design goals, tradeoffs, dependencies and constraints from the client, end user and
developers perspectives are addressed as follows.
2.1. Design Goals
The major design goal of the system includes:
2.1.1. Integrity
The system Commits transactions that are completed and/or rollback unfinished or time-out
transactions. It validates the type of data that is going to be processed. It defines what the fields
can accept as input, like text, image, file, video and other types. Then it should have processed
the users want based on the input data. The system should integrate these inputs with database.
 the system performs data validation while entering the data that makes data consistency.
 The system also performs skip logic questions.
 Extensive data validation and review will be performed both before data are uploaded to
the system and as part of upload process this supports the system to keep data integrity.
2.1.2. Accessibility
This system is available for 24 hours aday since it is web based system. So it can be accessed
everywhere and time.
2.1.3. Scalability
The system can be modifed to higher system by adding some components or by using as one
component in an other system.
2.1.4. Availability
This system is business solution so that it is critical to keep availablity in high priority. The
system should always be available for access at 24 hrs, 7 days a week. Also in the occurance of
any major system malfunctioning, the system should be available in 1 working days, so that the
business process is not severely affected.

7
 2.1.5. Throughput
Throughput of the system should be considerably adequate to provide a continuous service for
the customers. The number of transaction the system performs at a given branch of the company
should be at least 500 per second.
2.1.6. Maintainability
The system can be maintained by the system maintenance team of the system developers.
2.1.7. Reliability
The reliability of the system will be satisfied by using
 Mean Time between Failures: MTBF value of the system should be very high value
ranging from 6-12 months.
 Mean Time to Repair: MTTR value of the system should be very low. The estimated
value for this system is 3-5 hours. The development should be focused to reduce the
current value as much as possible.
 Accuracy: The system is responsible for business transactions. The accuracy of the
system will be critical and it will be tested with great measures.
2.1.8. Reusability
The system is reusable with different systems, like online banking and it can be one components
to develop other systems.
2.1.9. Portability
The system can adapt and run in different environment and it can be moved from one place to
another place.
2.1.10. Traceability of requirements
The system should developers should have to know better about the flow of information, levels
of users, priority of user types, non-functional requirements that must be implemented. And they
have to implement on the system.
2.1.11. Fault tolerance
Error should be considerably minimized and an appropriate error message that guides the user to
recover from an error should be provided. Validation of user’s input is highly essential. Also the
standard time taken to recover from an error should be 15 to 20 seconds.
The system tolerates some faults like username and other inputs, and it gives related feedbacks
for the error encountered like” enter correct user name or password”.

8
 2.1.12. High performance
The system gives high performance of handling, send, receive and display data.
2.1.13. Well-defined interfaces
The system has well-defined interfaces, it tells users where they are now, what they are going to
do, it has some well-known interfaces that are familiar for users.
2.1.14. Ease of learning, remembering and use
Consider the level of knowledge possessed by the users of this system, a simple but quality user
interface should be developed to make it easy to use, understand and required less training.
The system is easy to learning, since it’s interfaces are familiar to users, it needs no prior
knowledge of programming language and computer staffs, only knowledge of English language
is needed. It is easy for use.
2.1.15. Readability
The system can be understood by the users without prior knowledge of programing language, it
needs only English language for communication with the system.
2.1.16. Increase productivity
The system encourages productivity of different products by advertising new products and
support customers to be attracted, it accepts feedback and improve by the system maintenance
team.
2.2. Design Trade-offs
2.2.1. Functionality v. Usability
The system implements high Usability in order to keep users attracted, it avoid some
functionalities that are not basic for the system to be accomplished.
2.2.2. Performance v. portability
it resolves locking issues and handle concurrent use of the system on 24/7 basis. Send, receive
and display user messages to assist the overall user experience. In order to keep these two
measure, the team used SQL server.
SQL SERVER is fully portable to more than 80 distinct hardware and operating systems
platforms, including UNIX, MSDOS, OS/2, Macintosh and dozens of proprietary platforms.
This portability gives complete freedom to choose the database server platform that meets the
system requirements

9
 2.2.3. Security v. Usability
Data error from the user’s end and from the back-end database-processing end must be
gracefully handled. There will be data validation and error-handling routines as part of the online
registration system.
The propose system provides three tier login concept. It means that different users will login with
different permission or privilege. Therefore, the users are able to access different functionality of
the proposed system.
We focus on providing a clean and consistent interface through java GUI that will appeal to the
user, it also be used to allow for immediate responses for user actions.
2.3. Assumptions and Dependencies
The software tools required for the system development are available to the developer.
The requirements gathered are correct and achievable.
The final deliverable of the project can be hosted in a server.
2.3.1. Related software or hardware:
Different software and hardware are used in relation to this system. End users will use text
editors, PDF, hard copies and image viewers. And java GUI, Photoshop, E-drawmax and
JavaScript will be used for the development.
2.3.2. Operating systems:
The system will be constrained by operating software of the host system and will need to
be able to function on the different internet servers
1. The system will need to function on major internet operating software including
Internet explorer, Firefox, Chrome, Safari, Opera, and Android.
2. The system will be constrained operating software of the host computer like
windows, Linux, android.
2.3.3. End-user characteristics:
There are two types of users in from each subsystem of the system.
 Customers:
Most probably new to the system.
Do not require any technical expertise.
Simple knowledge to use internet.
 System employees: - have High technical expertise, Experience and domain knowledge

10
 Well aware of system functionalities
2.4. General Constraints
There are some basic constraints encountered during the implementation of this system and they
are evaluated by the system developer team in some methods as follows:
2.4.1. End-user environment:
Here it is difficult to understand and full-filling their needs is so difficult, also there is lack of
project management to gather information and analyse the requirements these problems have
some influences on the system designing quality.
2.4.2. Availability or volatility of resources:
During requirement gathering there was problem of resources in order to analyse and document
it. Resources differ day to another. Then it was somewhat difficult to design the system based on
this information.
2.4.3. Standards compliance:
The input and output file formats should conform to the basic interface standards for user
understanding. All language used in the software (including manuals and documentation) should
comply with the current Ethiopian guidelines for decency and equal opportunities.
2.4.4. Interface/protocol requirements:
There are many types of interface that affects the system, this are:
2.4.4.1 User interface:
This system is affected by its user interface, since it doesn’t support languages other than
English.
It has been required that every form’s interface should be user friendly and simple to use.
Besides, there should be facility of accessing the system through keyboard along with the mouse
i.e. keyboard shortcuts.
2.4.4.2 Hardware interface
The system will have 3 terminals per one branch store, with each one having a touch screen
monitor, keyboard, visa card scanner and acash register. And also it will have a 45 minute
battery backup at each terminal and 2 hr battery backup at the server at headquarter of the
company.

11
 2.4.4.3 Software interface:
There could be necessity of using the stored data for some kind of report that is not supported by
proposed system. So the proposed system is required to export its data as a text file so that some
other application software can import the data.
An intelligent text message sender API which is able to send programmable text messages will
be integrated with the system to enable the text message sending functionality
2.4.4.4 Communication interface:
The system will be hosted on a free hosting site (Heroku).
2.4.5. Security requirements
The system shall utilize HTTPS communication to ensure data confidentiality.
The system should not allow unauthorized access to any module of the system. Besides, it shold
maintain the privilage granted to users at various user level.
2.4.6. Memory and other capacity limitations:
The system needs very large database that used to handle every activity log for security and
privatization service, but it is somewhat difficult to have this type of database that store every
activity log in storyline forever. So it stores the information for a number of years, after that it
delete the activities.
2.4.7. Performance requirements:
As it is going to be used by all the concerned employees within the organization, the system
should have a good performance in terms of speed and accuracy. The proposed system should be
accurate and fast enough to handle huge data. It should provide fast communication between
server and clients.

3. System Decomposition
3.1. Architecture of the System
The architecture of the system is model View Controller, MVC

12
Figure 1 architecture
3.2. System Decomposition

There are many sub systems in this car rental system. Some of them are explained below:
 Employee hiring : This subsystem guaranteed only for the administrator of the system.
He can hire any employee for the company
 Customer registration: Customers should be registered in order to book for renting cars or
rent their car.
During registration all the fields should be filled first. There is no filed that can be null.
 Booking: It support customers to book for cars after they have registered.
Here customers can select their interested car for how long and negotiate with the
payment cost.
 Remove account: Administrator can remove accounts from the database.

13
 3.3. Layers & Partitions
Write description and design routine diagram about the layers and partitions of the system based
on your architecture.
The system is partitioned based on the access level and role of the user.
The system has two parts
 Customer part: A user from the customer part don’t have any influence on the system.
They can register, change password, book.
 Employee part : The employee part manages the overall flow of the system. they control
the system functionality.
Employee can hire employee, register, delete account,
The system has also layered based on the role of the end user.
 Finance manager: It can control data about the finance like car billing, purchasing car and
employee salary
 Mechanic:: The mechanic can control data related to the cars and drivers, car status,
schedule, driver detail,
 HR-manager: it is concerned with the management of timing of the employees. It checks
if employees are at work.
 Movement manager: this employee is concerned with the route information and car
allocation, he controls the allocation of cars, distribution of cars over geographical areas,
update route distance.
 Administrator: he can control the employees within the system.
3.4. Persistent data management
In order to store information persistently we map objects into tables and the attributes into fields
to the specific table based on the objects found on the system. This part is to describe and show
the necessary relationships among the tables, which are selected to store the data persistently in
the system.
the database diagram is as follows:

14
 class habt

car rental system registration

- address «column»
- age * user name
- bill no. id
- driver li scence no.
- e-mai l
- fi rst nam e employee
- last nam e hiring
- phone-num
- role «column»
- sex * fi rst name
- user name last name
role
+ add user(): void
+ booking(): void
+ delete account(): voi d booking
+ employee registration(): void
+ register()
+ register car(): voi d
+ view booking(): void

car
registration

Figure 2 database

4. Access control and security

Subsystem Operations Actors

SA Mechanic finance Mov’t manager HR- manager
User changeemail()     
Management changephone()     
Register_employee() 
editprofile()     
passchange()     
updatePermission() 
userControl() 

15
 view_profile_detail()     
viewPermission() 

View_booking()  
Delete_account() 
Table 1 access control

5. User interface design

Screenshots of the main user interfaces of Car rental system
 Home Interface of the system
When any users are logging to the system this feature is appeared and the user should select what
is his role on the system. Then he can be redirected to the role feature.

Figure 3 admin home

16
  Customer home
When the customer home is appeared it is necessary to register or login using his user
name and password if he is already registered.

Figure 4 customer registration

17
  Booking
Here the user can book by filling the appropriate fields. He can select his interested car, if
he doesn’t have driver license he can choose a driver.

Figure 5 booking

18
  Administrator home
Before the admin is going to home page he should enter his user name and password
So the login page is popped up. Then after he log in using his password, the system
displays what he can do on the page. He can control the employees, view booking.

Figure 6 admin login

19
Figure 7 admin home

20
  HR_manager: The human resource manager can view and control the shift schedule of
employees and check employees work time.

Figure 8 HR manager home

21
  Mechanic
The mechanic can see the driver details, check cars status, and report to the finance
manager for spare part billing.

Figure 9 mechanic home

 Movement manager: He can see driver and car details, update route distance.View and
control car allocation.

22
Figure 10 movement manager home

23
Control Name Control Type Description
txtfFullName Text Field Text Field which holds Full Name of
Assessor
passfpassword password Field A field holds password.
Txtfsize Text Field A field that holds size of the car in CC
Drltype Drop Down List A list holds possible types of car
drlNumber Dropdown list A list holds possible number of cars to be
rent
Txtflicense Text Field A field holds a license number
txtfpickupdate Text Field A field holds day of picking the car
Txtfdropoffdate Text Field A field that holds day of returning the car.
txtfE-mail Text Field A field that holds e-mail of the users
drlSex Drop Down List A list holding possible sex types
drlfAge Drop Down List A list holding valid age
txtfRegNo Text Field Text Field which holds Registration
Number of Assessor
Txtfphonenum Text Field Text Field which holds Cell Phone of
Assessor
Txtrole Text Field Text Field which holds Classification of
Work of Assessor
Table 2 control input

24
6. Design details
6.1. Class diagram

class class

admin

- password
- user id

+ register account ()
+ view details(): void

mechanic movement manager

- password finance manager - address

- user id - age
- password - e-mail
+ car details(): void - user id HR_MANAGER - F_name
+ driver details(): void
+ car biling() - id
- password - L_name
+ register account () - user id
+ update information(): void - password
+ view details(): void + emp_information() - phone_num
+ shift schedule info(): void + manage agency()
+ shift timing info(): void
+ manage customer(): void
+ update details(): void

Figure 11 class diagram

25
 6.2. Detail design
 Class admin
Class diagram Description
c la s s c la ss This class contains data about
administrator of the system, his
a dmin

- p a sswo rd boundary and level

- u se r i d

+ a d d n e w(): vo i d
+ d e l e te (): vo i d
+ re g i ste r a cco u n t ()
+ vi e w d e ta i l s(): vo i d

Method Procedure does Called by Calls

Add(new) : void Add new admin or employee Add_account Employee_role, insert
account on admin table (Employee_role)

Delete() :boolea Admin can delete account of

n employee or other administrator by
adding new administrator
View details() Administrator can view details View_details View_customer_details
about the system users (select customer )
Table 3 admin class

26
  Class movement_manager
Class diagram Description
class class This class contains what activities

mov ement manager

can be accessed by the movement
- address manager of the system.
- age
- e-m ai l
- F_nam e
- id
- L_nam e
- password
- phone_num

+ car al l ocati on(): voi d

+ update detai l s(): voi d
+ update route di stance()

Method Procedure does Called by Calls

Carr_allocation : Movement manager can allocate cars Allocate_car Allocate_Car(insert
void car allocation site)

Update details (): Movement manager can update details Update_details Insert_role, update
void about driver car allocation, schedule
Table 4 class mov't manager

 Class mechanic
Class diagram Description
class class This class contains the methods called by the
mechanic in the system.
mechanic

- password
- user i d

+ car detai l s(): voi d

+ dri ver detai l s(): voi d

27
Method Procedure does Called by Calls
Car details): void Mechanic can update car Update_car_detail Update_car_details(insert
status, new)
Driver detail (): Mechanic can update driver Update_driver, Update_driver(insert new
void details car )
Table 5 class mechanic

 Class finance_manager
Class diagram Description
class class This class contains activities that can
be done by the user called finance
finance manager

- password manager in the system.

- user i d

+ car bi l i ng()
+ regi ster account ()
+ update i nform ati on(): voi d
+ vi ew detai l s(): voi d

Method Procedure does Called by Calls

Car billing () : Finance manager can control car car_billing() Car_billing(insert
void billing new)
Update He can update cost per mile Update_cost() Update_cost(), insert
information (): new cost
void
View details() He can view details of billing and View_detail() Select view_details()
finance related posts
Table 6 class finance manager

28