CAR RENTAL SYSTEM

APPLICATION DEVELOPMENT – II

SOFTWARE DESIGN SPECIFICATION

Submitted in partial fulfilment for the award of the degree

Of

M.Tech
In
Information Technology
By

AMIT KUMAR
16MIN0810

School of Information Technology and Engineering

March, 2019
 Software Design Document

DOCUMENT APPROVAL
The following Software Design Specification has been accepted and approved by the
following:

Signature Printed Name Title Date

2
 Software Design Document

Table of Contents

1. INTRODUCTION ............................................................................................................................................ 4
1.1 Description about APD 1 .................................................................................................................... 4
1.2 Purpose................................................................................................................................................. 4
1.3 Scope..................................................................................................................................................... 5
1.4 Overview .............................................................................................................................................. 5
1.5 Reference Material .............................................................................................................................. 6
1.6 Definitions and Acronyms .................................................................................................................. 6
2. SYSTEM OVERVIEW .................................................................................................................................... 6
3. SYSTEM ARCHITECTURE .......................................................................................................................... 7
3.1 Architectural Design.................................................................................................................................. 7
3.2 Decomposition Description ..................................................................................................................... 15
3.3 Design Rationale ...................................................................................................................................... 16
4. DATA DESIGN .............................................................................................................................................. 17
4.1 Data Description ...................................................................................................................................... 17
4.2 Data Dictionary ........................................................................................................................................ 17
5. COMPONENT DESIGN ............................................................................................................................... 20
6. HUMAN INTERFACE DESIGN .................................................................................................................. 22
6.1 Overview of User Interface ..................................................................................................................... 22
6.2 Screen Images .......................................................................................................................................... 24
6.3 Screen Objects and Actions .................................................................................................................... 29
7. REQUIREMENT MATRIX .......................................................................................................................... 30
7.1 Hardware Interfaces................................................................................................................................ 30
7.2 Software Interfaces .................................................................................................................................. 31
7.3 Communications Interfaces .................................................................................................................... 33
8. APPENDICES ................................................................................................................................................ 33

3
 Software Design Document

1. INTRODUCTION

This Software design specification specifies the design specifications of the vehicle rental
application, which will be useful to the real time customers. The developers and clients to know
more about the architecture and the designs of the systems or units that are interrelated to each
other will use this document. This will helps the developers to identify the connectivity
between the two layers, which are dependent, with each other.

The module connectivity with the help of ESB layers (which access middleware) is needed to
ensure flawless transactions performed by each Individual Customer.

Car rental application is specifically developed for use who want to rent there vehicle, and
user who want to get a vehicle for rent.

1.1 Description about APD 1

The purpose of the APD 1 SRS document is to collect and analyze all assorted ideas that have
come up to define the system, its requirements with respect to users who will be using this
system. Also, we shall predict and sort out how we hope this system will be used in order to
gain a better understanding of the project, outline concepts that may be developed later, and
document the ideas that are being considered, but may be discarded as the product develops.

In short, the purpose of SRS document is to provide a detailed overview of our software
product, its parameters and goals. This document describes the project's target audience and its
user interface, hardware and software requirements for using the Car Rental System and
Website.

1.2 Purpose

The traditional way of renting a vehicle was to enter the details and record them. Every time
the user needs a vehicle for rent, he has to identify shops, which provide the service, has to
visit each shop to check the available vehicles and there rate. It may be a hard-hitting task for

4
 Software Design Document

the users and service providers too. The project gives real life understanding of Internet rental
system and activities performed by various roles in the supply chain.

Here, we provide automation for rental system through Internet. Internet rental system project
captures activities performed by different roles in real life vehicle renting which provides
enhanced techniques for maintaining the required in- formation up-to-date, which results in
efficiency. The project gives real life understanding of rental system and activities performed
by various roles in the supply chain to make their life easier.

The essence of the document helps the engineer (System Developer) to make sure the
qualitative build of the application as well as the reliability, which does not make end users
being burdened at times. This project will allow the developers to know about the data flow
from unit to each other and how the data is being processed.

1.3 Scope

Software Name: Car Rental System (CRS)

The CRS caters the basic rental services value transactions vehicle registration, booking, cancel
booking, searching for available vehicles and payment methods.

The scope of this project is System Design, which is the process of gathering and interpreting
facts, diagnosing the facts in order to create a new and efficient system. System design is a
creative process the essential feature of a creative process is the association of previously
unconnected concepts. Design requires a complete understanding of the problem. The system
study has set certain well-defined objectivities for the efficient and effective functioning of the
system.

1.4 Overview

The System overview section provides an overall description of the Car functionality, design
and implementation of the project.

The System architecture section provides description the program structure and the relationship
between the modules to achieve the goal of the system.

The data design section provides a detailed description of domain of the system, which is
transformed into data structures.

5
 Software Design Document

The last section provides a detailed description about the each component.

1.5 Reference Material

http://www.apartmentguide.com/blog/apartment-application-items-you-need/

https://www.clearcarrental.com/terms-conditions

https://olao.od.nih.gov/division-logistics-services/transportation-management-
branch/government-vehicles-daily-use-rental

https://en.wikipedia.org/wiki/Rental_agreement

1.6 Definitions and Acronyms

Software Design Specification (SDS)

Enterprise Service BUS (ESB)

Software Development Life Cycle (SDLC)

2. SYSTEM OVERVIEW

System Design is the process of gathering and interpreting facts, diagnosing the facts in order
to create a new and efficient system. System design is a creative process the essential feature
of a creative process is the association of previously unconnected concepts. Design requires a
complete understanding of the problem. The system study has set certain well-defined
objectivities for the efficient and effective functioning of the system. The primary objectives
are furnished below:

 To develop and implement a completely automated system.

 To provide the users with attractive and user-friendly input screens.
 To enforce security, integrity, consistency, accuracy and validity of data.
 To provide the maintenance of master databases.

6
 Software Design Document

3. SYSTEM ARCHITECTURE
3.1 Architectural Design

The Car Rental System is a web-based client/server software application system, which will be
applied on a distributed computing environment. The technique of layered architecture can
provide one basis for geographic distribution. From function and performance viewpoints,
specification of functions within distinct layers allows us to keep similar actions closely
aligned. Layering design can improve simplicity, understandability and maintainability of the
system. We identified the following various sub-systems of the Car rental system: User
Interface subsystem, Event Handler subsystem, Client subsystem, Server subsystem, Database
subsystem. User Interface subsystem provides a user friendly graphical user interface for the
customer to provide and retrieve information. Event Handler subsystem isolates the User
Interface subsystem from the Client subsystem. It separates the physical events from the logical
events. This enables much easier debugging during implementation and during upgrading the
system when new features are added. Client subsystem interacts with the Server subsystem to
fetch various objects based on user requests. It is also responsible to continuously update the
objects resident on the client machine based on the events received from the Event Manager,
which is located in the Server system. Server subsystem serves various clients' requests by
fetching objects from the database. It receives "pushed" events from the Database and updates
the objects resident on the Client subsystem and Server subsystem. For the client side update,
the Event manager communicates with the Client subsystem. And. the Event Manager is
responsible for the server side update. The Event Manager plays a key role in maintaining
consistency of data between the Client, the Server and the Database. Database subsystem
serves objects requested by the customer. It also pushes events to the Event Manager as new
events are recorded on the database.

To understand the need and benefits offered by CRS application we need to know and
understand traditional form of renting vehicles, its limitations and shortcomings.

The user need to visit a rental shop to book a vehicle, he needs to agree to the terms and
conditions. He need to select a vehicle of his choice and budget and make the payment.
Customer has to wait in a queue for his turn for performing any activity.

The customer has to visit the shop to get the vehicle details, rate and availability. Customer
needs to fill up various forms before his query is resolved.

7
 Software Design Document

The CRS application will be developed using ASP.Net, SQL Server and JavaScript.

Login:

This module provides the user to login with their Username and Password. If it is the first time,
they can register.

Registration:

This module allows the users and service providers to register if they have not registered. User
has to provide the licence details and upload a scanned copy to verify his identity. Service
provider must enter the vehicle details and contact information.

Booking:

This module allows user to book vehicles, which are available.

Vehicle Information:

This module provides the details of vehicles registered. Service provider has the option to
view/edit and remove the vehicles registered.

Funds Transfer:

This module provides the option to transfer the amount to service provider after booking
confirmation.

Contact Us:

This module provides the UI to log a complaint or to ask about any application related queries.

8
 Software Design Document

Use case Diagram:

9
 Software Design Document

USE CASE ANALYSIS:-

SERVICE PROVIDER:-

1) LOGIN: The service provider can log in to the system by giving correct user name and

password.

2) REGISTERATION: The service provider can register if they are not registered in the system.

3) VIEW BOOKING DETAILS: The service provider can view the booking details.

4) CANCEL BOOKING DETAILS: The service provider can cancel booking of vehicle if the

vehicle is not available.

5) VEHICLE DETAILS MODIFICATION: The service provider can update stored

information of vehicles, which belong to them.

10
 Software Design Document

USER

1) LOGIN: The users can log in to the system by giving correct user name and password.

2) REGISTERATION: The users can register if he has not registered in the system.

3) VIEW AVAILABLE VEHICLES: The user can view the list of available vehicles, which

are available for booking.

4) CANCEL BOOKING: The user can cancel a booking, which is made by him.

5) MAKE PAYMENT: The users can make payment online or make payment directly to the

service provider.

11
 Software Design Document

THE THREE-TIER ARCHITECTURE

12
 Software Design Document

ENTITIES & THEIR ATTRIBUTES

CUSTOMER

VEHICLE

13
 Software Design Document

BOOKING

PAYMENT

14
 Software Design Document

3.2 Decomposition Description

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data

through an information system. DFDs can also be used for the visualization of data processing
(structured design).
On a DFD, data items flow from an external data source or an internal data store to an
internal data store or an external data sink, via an internal process. A DFD provides no
information about the timing of processes, or about whether processes will operate in sequence
or in parallel.
Data flow diagram notations:

Entity

Process

Data flow

Level 1 – DFD:

15
 Software Design Document

DFD for Making Booking:

3.3 Design Rationale

Choice of Architecture

The Car rental system has to respond to asynchronous events from the customers and the
database. The customers are allowed to view available vehicles, add vehicles modify vehicle
details, book available vehicle, change address and password thus to interact with the system.
The dynamic nature of the various objects contribute the system's dynamic characteristics. A
combination of interactive and dynamic architecture best addresses these requirements.

Scalability

One of the key issues for any online system is its ability to scale up. The Car rental system
should be capable of handling increasing number of users with minimum effect on the response
time. By maintaining a set of active objects on the client machine, the response time is vastly
improved as most of the user requests are served locally. At the same time, the Car rental

16
 Software Design Document

system could handle more number of connections in a given time. The overheads involved in
such client side processing are negligible compared to the features it provides.

Concurrency

The Car rental system receives asynchronous events that need to be addressed simultaneously.
The system is divided into suitable independent sub-systems to handle such concurrent events.

Dynamic Update of Data

Data displayed on the client machine has to be continuously updated as new events are recorded
on the database. The event manager that receives the "pushed" event from the database in turn
interacts with the controller to incrementally refresh the displayed information on the User
interface.

Consistency of data

One of the key issues in the design is the need to maintain consistency of data between the
Client, Server and the Database. The controller and event manager coordinate to maintain
consistency of data across the system.

Persistence

In an effort to provide fault tolerance to the Car system, all active transactions are stored and
continuously updated in the database. In case of a system crash, the transaction objects with
the latest balance could be retrieved.

4. DATA DESIGN
4.1 Data Description

The database subsystem stores al1 the data that the system can provide to its users and the inter-
relationship between the data. Upon user requests, the event handler subsystem may
accordingly search database for information, update data, or save new data into the database
through Client subsystem and Server subsystem. The Database subsystem is connected to
Server subsystem by ODBC as middle ware. Through the query, it can get data from or save
data to database. The query is attached with each component if that component need to access
database.

4.2 Data Dictionary

Table: Customer

17
 Software Design Document

Table contains the details of service provider and user.

Field Name Datatype Description

Cust_ID INT Numeric value sequentially

generated by the system.

Cust_Name VARCHAR Name of the user/service

provider.

Address VARCHAR Address of the user/service

provider.

Cust_Mobile VARCHAR Mobile number.

Cust_Email VARCHAR Email id of the user/service

provider.

Cust_PSW VARCHAR Password.

Cust_Type VARCHAR Type of customer.

(user/service provider)

Table: Vehicle

The table contains the details of registered vehicles

Field Name Datatype Description

Vehicle_ID INT Numeric value generated by

system.

Cust_ID INT Specifies the customer id of

vehicle owner.

Vehicle_Make VARCHAR Vehicle make name.

Vehicle_Model VARCHAR Vehicle model name.

Vehicle_Reg_No INT Vehicle registration number.

18
 Software Design Document

Vehicle_Ava_From_Date DATE TIME Specifies the vehicle

availability start date.

Vehicle_Ava_To_Date DATE TIME Specifies the vehicle

availability end date.

Vehicle_Daily_Rate FLOAT Daily rate.

Table: Booking
This table contains the details of the bookings made by user.

Field Name Datatype Description

Booking_ID INT System generated id for

booking.

Cust_ID INT Customer id of customer

who booked the vehicle.

Vehicle_ID INT Vehicle id of vehicle booked

by the customer.

Booking_Date DATE Date of booking the vehicle.

Booking_From_Date DATE Starting date from which

customer has booked the
vehicle.

Booking_To_Date DATE End date until which

customer has booked the
vehicle.

Payment_Type CHAR Mode of payment.

(Cash/Card)

Payment_ID INT ID used to track the details of

payment.

Table: Payment
This table provides the details of the payments done online.

19
 Software Design Document

Field Name Datatype Description

Payment_ID INT System generated id. It is a

unique value.

Booking_ID INT Booking id for which

payment is made.

Card_Type VARCHAR Type of card. (credit/debit)

Card_No VARCHAR Card number.

Payment_Date DATE Date of the payment made.

Amount FLOAT Amount payed.

5. COMPONENT DESIGN
This section contains the description of each module in subsystems. It explains the overall
function and purpose of that module.

User Interface Module

The User Interface module is composed of al1 levels of user interfaces on the client site, which
are the first and the only means for the user and the Car Rental system to communicate with
each other. Inside this module, not only can al1 interfaces be developed using the same set of
tools and be supported by the same interface applications, but also are al1 interfaces tightly and
dynamically inter-related with each other. Any particular sequential combination of a set of
user interfaces actually represents the sequence of user inputs and system responses. Outside
this module, from a bird's view of the system, this user interface module as a whole performs
the sole function of accepting user input on one side and passing the user message to every
module in Event Handler subsystem on the other side or vice versa.

Modules in Application Subsystem

In the Car rental system, we can cal1 Event Handier subsystem, Client subsystem and Server
subsystem as Application subsystem. Through user interface, user triggers an event by clicking
mouse or typing input on keyboard and different modules in Event Handler subsystem, Client
subsystem and Server subsystem can handle and response the different fired events.

The Application subsystem contains two major modules as depicted below:

20
 Software Design Document

The Security Module:

This module performs the security check for user access to the system information and services.
It verifies the user input, and passes the checked result to the User Interface subsystem by
displaying the different pages according to the different checking result. This module is the
bridge between user interface module and other modules.

Customer Service Module:

This module provides services including registering vehicle details, booking vehicles, and view
booked vehicle details, change addresses and passwords. This module provides services for
current customers of Car rental system with user IDs and passwords.

The following sections introduce the internal component organization of these modules in the
Application subsystem.

Security Module

21
 Software Design Document

The Security Module is shown in above Figure. It is to check user whether has desired right to
get the services requested. If the services, which user asks for need security check, the user
interface will show a security check interface, ask user to input user identified id and password.
The user interface passes the message to Security module. There are two phases. In phase 1,
the format of id and password are checked without involving database. ID should consist of
seven digits and password should consisted of string less than eight characters. If input format
is correct, mer check involved data stored database is implemented in phase II. If the user
passes through the security check correctly, the security module passes the control to other
module corresponding to the service user requested. Otherwise, the security module will pass
a message to user interface, and inform that the user has no right to get the services.

6. HUMAN INTERFACE DESIGN

6.1 Overview of User Interface
The purpose of this section is to provide a detailed specification of the Internet Car Rental
System user interface. These requirements will detail the outwardly observable behavior of the
program. The user interface provides the means for the user, to interact with the program. This
User Interface Specification is intended to convey the general idea for the user interface design
and the operational concept for the software. This document will be updated with additional
detail as our analysis and design activities progress.

The User Interface Specification (UIS) consists of one main graphical user interface (GUI),
which consists with different operations enlisted in the options.
The customer must first register then only the customer can open a new account in the system.

22
 Software Design Document

He/She must fill all the details in the form, as well as choose a password in order to login after
the registration.

The system verifies customers input in the field of account no and password, and displays an
error message if the customer enters incorrect information. Thus, if the customer provides an
appropriate data, then he will be allowed to log in.

User interacts with the system

The sequence diagram shows how the customer can register in the CRS system in order to login
the system. When the customer submits all the details in the form then the system automatically
sends to the database.

23
 Software Design Document

6.2 Screen Images

Home Page:

24
 Software Design Document

Login Page:

User Registration Page:

25
 Software Design Document

Service Provider Registration Page

User Search Vehicle

26
 Software Design Document

27
 Software Design Document

Service Provider Vehicle Details Page.

28
 Software Design Document

Contact Us

6.3 Screen Objects and Actions

Login Page:
Username: Username of the user.

Password: Password of the user.

Login: Validates the user name and password entered and allows the user to view home page
if validation is success.

User Registration Page:

User name: Username of the user.

Address: Address of the user.

Email: Email of the user.

Mobile: Mobile number of the user.

Password: Password of the user.

Confirm Password: Confirm password entered.

Register: Validates the details and registers the details in database.

29
 Software Design Document

User Search Vehicle:

From Date: User enters from date.

To Date: User enters to date.

Search: Displays the details based on from date and to date.

Contact Us:

Name: User enters the name.

Email: Email of the user.

Subject: Subject of the message.

Message: Message, which needs to be send.

Send Message: Validates the details and sends the message.

Edit Vehicle Details:

Vehicle Make: User enters the vehicle make.

Vehicle Model: User enters the vehicle model.

Available From: Selects the available from date.

Available To: Selects available to date.

Rate: Enters the rate.

Save Changes: Validate the data and saves the changes in database.

Cancel: Shows the view page.

7. REQUIREMENT MATRIX
7.1 Hardware Interfaces
Since web portal have any designated hardware, it does not have any direct hardware interfaces.
The GUI (Graphical User Interface) is managed web browser and the hardware connection to
the database server is managed by the underlying operating system.

30
 Software Design Document

7.2 Software Interfaces

ASP.Net
ASP.NET is the next version of Active Server Pages (ASP). A unified Web development
platform provides the services necessary for developers to build enterprise-class Web
applications. While ASP.NET is largely syntax compatible, it also provides a new
programming model and infrastructure for more secure, scalable, and stable applications.
ASP.NET is a compiled, NET-based environment, we can author applications in any .NET
compatible language, including Visual Basic .NET, C#, and JScript .NET. Additionally, the
entire .NET Framework is available to any ASP.NET application.

Developers can easily access the benefits of these technologies, which include the managed
common language runtime environment (CLR), type safety, inheritance, and so on.

ASP.NET has been designed to work seamlessly with HTML editors and other programming
tools, including Microsoft Visual Studio .NET. Not only does this make Web development
easier, but it also provides all the benefits that these tools have to offer, including a GUI that
developers can use to drop server controls onto a Web page and fully integrated debugging
support.

Developers can choose from the following two features when creating an ASP.NET
application. Web Forms and Web services, or combine these in any way they see fit. Each is
supported by the same infrastructure that allows you to use authentication schemes; cache
frequently used data, or customizes your application's configuration, to name only a few
possibilities.

Web Forms allows us to build powerful forms-based Web pages. When building these pages,
we can use ASP.NET server controls to create common UI elements, and program them for
common tasks. These controls allow we to rapidly build a Web Form

Each of these models can take full advantage of all ASP.NET features, as well as the power of
the .NET Framework and .NET Framework common language runtime.

Accessing databases from ASP.NET applications is an often-used technique for displaying data
to Web site visitors. ASP.NET makes it easier than ever to access databases for this purpose.
It also allows us to manage the database from your code.

31
 Software Design Document

Javascript

The most common use of JavaScript is to add client-side behavior to HTML pages, also known
as Dynamic HTML(DHTML). Scripts are embedded in or included from HTML pages and
interact with the Document Object Model (DOM) of the page. Some simple examples of this
usage are:

Loading new page content or submitting data to the server via Ajax without reloading the page
(for example, a social network might allow the user to post status updates without leaving the
page).

Animation of page elements, fading them in and out, resizing them, moving them, etc.
Interactive content, for example games, and playing audio and video. Validating input values
of a Web form to make sure that they are acceptable before being submitted to the server.

Transmitting information about the user's reading habits and browsing activities to various
websites. Web pages frequently do this for Web analytics, ad tracking, personalization or other
purposes.

Because JavaScript code can run locally in a user's browser (rather than on a remote server),
the browser can respond to user actions quickly, making an application more responsive.
Furthermore, JavaScript code can detect user actions that HTML alone cannot, such as
individual keystrokes. Applications such as Gmail take advantage of this: much of the user-
interface logic is written in JavaScript, and JavaScript dispatches requests for information (such
as the content of an e-mail message) to the server. The wider trend of Ajax programming
similarly exploits this strength.

A Web browser is by far the most common host environment for JavaScript. Web browsers
typically create "host objects" to represent the DOM in JavaScript. The Web server is another
common host environment. A JavaScript Web server would typically expose host objects
representing HTTP request and response objects, which a JavaScript program could then
interrogate and manipulate to dynamically generate Web pages.

SQL Database

SQL is a domain-specific language used in programming and designed for managing data held
in a relational database management system (RDBMS), or for stream processing in a relational
data stream management system (RDSMS).

32
 Software Design Document

Originally based upon relational algebra and tuple relational calculus, SQL consists of a data
definition language, data manipulation language, and data control language. The scope of SQL
includes data insert, query, update and delete, schema creation and modification, and data
access control. Although SQL is often described as, and largely is, a declarative
language (4GL), it also includes procedural elements.

SQL was one of the first commercial languages for Edgar F. Codd's relational model, as
described in his influential 1970 paper, "A Relational Model of Data for Large Shared Data
Banks." Despite not entirely adhering to the relational model as described by Codd, it became
the most widely used database language.

SQL became a standard of the American National Standards Institute (ANSI) in 1986 and of
the International Organization for Standardization (ISO) in 1987. Since then, the standard has
been revised to include a larger set of features. Despite the existence of such standards, most
SQL code is not completely portable among different database systems without adjustments.

7.3 Communications Interfaces

The communication between the different parts (UI & Database) of the system is important
since they depend on each other. However, in what way the communication is achieved is not
important for the system and is therefore handled by the underlying Database of CRS for web
application.

8. APPENDICES
NA

33