RideBuddy

Hamza Hussain BCS153094

Majid BCS153002
Sheema Rashid BSE153169

Supervised By
Mr. Qamar Mahmood

Spring 2019

BS Computer Science

Department of Computer Science

Capital University of Science & Technology, Islamabad

i
 DECLARATION

We, hereby, declare that “No portion of the work referred to, in this project has been submitted in
support of an application for another degree or qualification of this or any other university/institute or
other institution of learning”. It is further declared that this undergraduate project, neither as a whole
nor as a part there of has been copied out from any sources, wherever references have been provided.

MEMBERS’ SIGNATURES

ii
 TABLE OF CONTENTS

Chapter 1 .............................................................................................................................................. 6
Introduction ........................................................................................................................................... 6
1.1. Project Introduction ................................................................................................................... 6
1.2 Existing Examples / Solutions ................................................................................................. 6
1.2.1 Carpool ........................................................................................................................................ 6
1.2.2 NextCar........................................................................................................................................ 8
1.2.3 Careem ........................................................................................................................................ 9
1.2.4 Uber ........................................................................................................................................... 12
1.2.5 Comparison of Proposed System with Existing Solutions .......................................................... 14
1.3. Business Scope .................................................................................................................. 15
1.4. Useful Tools and Technologies .......................................................................................... 15
1.5. Project Work Break Down and Software Architecture ........................................................ 16
1.6. Project Time Line ................................................................................................................ 18
Chapter 2 ............................................................................................................................................ 20
2. Requirement Specification and Analysis ......................................................................................... 20
2.1. Requirement Specification ....................................................................................................... 20
2.2. Functional Requirements ......................................................................................................... 20
2.3. Non-Functional Requirements .................................................................................................. 22
2.3. System Use Case Modeling ..................................................................................................... 23
2.4. System Sequence diagrams .................................................................................................... 32
2.5. Domain Model .......................................................................................................................... 38
Chapter 3 ............................................................................................................................................ 39
System Design.................................................................................................................................... 39
3.1. Software Architecture ............................................................................................................... 39
3.3 Class Diagram ........................................................................................................................... 43
3.4 Sequence Diagram ................................................................................................................... 45
3.5 Entity Relationship Diagram ...................................................................................................... 57
3.5.1 Database Schema .................................................................................................................. 58

iii
 3.6 User Interface Design................................................................................................................ 59
Chapter 4 ............................................................................................................................................ 61
Software Development ....................................................................................................................... 61
4.1. Coding Standards .................................................................................................................... 61
4.2. Development Environment ....................................................................................................... 62
4.3. Software Description ................................................................................................................ 62
Chapter 5 ............................................................................................................................................ 65
5.2.1. Monkey:................................................................................................................................. 65

Chapter 6 ........................................................................................................................ 4
6.1. Installation / Deployment Process Description ......................................................... 4

iv
 List Of Tables

Table 2.1 Functional Requirements 21

Table 2.2 Non Functional Requirements 22

Table 2.3SignUp UseCase Description 27

Table 2.4 Login UseCase Description 28

Table 2.5 Upload Schedule UseCase Description 28

Table 2.6 Ride UseCase Description 30

Table 2.7 Chat UseCase Description 31

Table 2.8 Select from Available Schedules UseCase Description 32

Table 3.1 40

Table 5.1 UserSignUp TestCase 66

Table 5.2 User SignIn TestCase 1

Table 5.3 Calling a Ride TestCase 2

v
 Chapter 1
Introduction
This chapter provides a brief summary of project scope, project specification, a comparison study with the
available existing solutions and existing tools and technologies may be used for the development of this project.
This chapter also includes a project work breakdown structure and a proposed timeline.

1.1. Project Introduction

Everyone wants to travel comfortably without having to pay much. With the emerging costs of petrol and gas
most people have resorted to travelling on the public transport. The public transports in our country provide a
very discomforting travel experience overall. We are planning to design an application through which people can
share their ride with other people provided that they share the same schedule and live near each other. Once the
user installs our application, they would have to register and provide details; such as timetable, location and if
they are a vehicle owner or a client. Afterwards the user will be shown other users having similar profile and they
can contact each other for sharing the ride.

There are many possible scenarios in which two or more people maybe living in the same vicinity and going to
the same place at same time to run their errands without knowing that they share the same ride schedule. For
instance, there are many offices in same locality and almost all the offices have working hours from 9 to 5. So if
two people are living in the same vicinity and going to different offices which are located at the same place they
can share their ride. Another example could be students going to the same university in different departments
without knowing the fact that another nearby student of the same university has the same timetable. Therefore,
we believe that this application could be really helpful for the people who want to cut down their budget of
transport and travel comfortably at the same time.

1.2 Existing Examples / Solutions

1.2.1 Carpool

Carpool is web-based application. Below are the screenshots of the details a user needs to provide to search for
another transporter who is going to the same destination.

Figure 1.1 shows the information gathering page of a registered user on the web-based application Carpool

6
 Figure 1.1 Information Gathering of a Registered User

Figure 1.2 shows the Schedule settings in application Carpool

7
 Figure 1.2 Getting Daily Basis Schedule of User

Figure 1.3 shows a form getting the contact information of the user

Figure 1.3 Getting Contact Information of the User

Features
1. Allows the client to give their detailed information so that best match could be
selected for rider

2. User can mark a specific period of time on the calendar and enter their daily
schedule and the rider is allocated according to that schedule if available.

3. The website is operational only in Pakistan

1.2.2 NextCar

NextCar is another ride sharing application in Pakistan. It has a web version as well as android version. Below
are the screenshots of the website and android version of the application.

Figure 1.4 shows that in the “Next” application attempting to register a new account generates an error message.

8
 Figure 1.4 SignUp Activity is Broken

We were unable to try the application because it crashed, therefore we were unable to mention any features of
this application. We also viewed the user reviews on google play app store in which the users had given this
application negative remarks.

1.2.3 Careem

Careem is an android based application. Basically, Careem is not a ride sharing application, it comes in the
category of online cab booking. But since it has a similar functionality such as charging a client for dropping them
off at a particular place we decided to include this app in the comparison.

Below are the screenshots that depicts the basic working of the application. Figure 5 shows that the user can
selects their pickup location as their current location or chose another location for pickup and enter their drop off
location through map.

9
 Figure 1.5 Drop Off Location Activity

Figure 1.6 shows that after tapping "Confirm pickup" the app searches for the nearest driver and connects him
to the user

10
 Figure 1.6 Confirm PickUp Activity

Features

1. The application is available on iOS as well as android

2. The application gives an estimate of the fare

3. Estimate of time is provided

4. Route is shown on the map

5. User can rate the driver after completing the ride

6. This app is available in some countries around the world

11
1.2.4 Uber

Uber is an android based application. Basically, Uber is not a ride sharing application, it comes in the category of
online cab booking. But since it has a similar functionality such as charging a client for dropping them off at a
particular place we decided to include this app in the comparison. Below are the screenshots that depicts the basic
working of the application. Figure 7 shows that user can give rating to the last trip he had

Figure 1.7 Feedback Activity

Figure 1.8 shows that after selection of pickup and destination location, the user is shown route on the map and
the cab fare is calculated and shown to the user

12
 Figure 1.8 Confirm Ride Activity

Features

1. The application is available on iOS as well as android

2. The application gives an estimate of the fare

3. Estimate of time is provided

4. Route is shown on the map

5. User can rate the driver after completing the ride

6. This app is available in many countries around the world

13
1.2.5 Comparison of Proposed System with Existing Solutions
Table 1 shows the Comparison between the four applications discussed above and the proposed system.

Initial two rows represent Vehicle owner to client sharing that is a module which lets a vehicle owner to share
his ride with a non-vehicle owner. And it also represents Vehicle owner to vehicle owner ride sharing that is a
module which lets a vehicle owner to share rides with another vehicle owner, the app will not restrict a vehicle
owner to be the one driving every time.

Table 1 Comparison of Proposed System with Existing Solutions

Our
Sr Characteristics Carpool NextCar Careem Uber proposed
no. system
Android
1 application
✓ ✓ ✓ ✓
Vehicle owner
2 to non-vehicle ✓ ✓ ✓
owner sharing

Vehicle owner
3 to vehicle ✓
owner ride
sharing

4 User feedback
✓ ✓ ✓
Schedule
5 based ride ✓ ✓
sharing

Client
6 registration ✓ ✓ ✓ ✓ ✓

Owner
7 registration
✓ ✓ ✓ ✓ ✓
Option for
8. saving pickup ✓
location

14
 Multiple clients
9 sharing one ✓
ride

1.3. Business Scope

After the success of cab applications, people have become aware of the fact that there is a possibility of the
existence of a mobile application through which rides can be booked. Therefore, we have decided to further
extend the idea to minimize an individual’s cost even more by creating a ride sharing application.
The application saves money for the vehicle owner as well as the ride sharer. The vehicle owner can share the
fare with the ride sharer. This will be beneficial for the ride sharer as it would still be cheaper than any cab service.
In this way a person who owns multiple cars can hire drivers and earn some money on the side too by driving
clients to their destinations.

Unlike any cab application this application saves more money for the driver because they have to go to that
particular destination regardless of the fact that they can get any sharer or not, but in a cab application the driver
only has to drop the client at a particular destination and then the return journey comes out of their own pocket.

1.4. Useful Tools and Technologies

In this project we will be using java as our language since android applications can be developed on java. The
tools that we plan to use in this project are:

Android Studio provides portability to build applications.

SQLite Browser is used to view your databases that you create within Android

Studio.

Firebase is used to get services from google to manage your databases.

15
 Visual Studio amongst other can be used to create a web API using C#

1.5. Project Work Break Down and Software Architecture

The project break down structure show the complete project divided into sub tasks and given each subtasks to
different members.

Figure 1.9 Project Work Breakdown

Figure 1.9 shows the pictorial representation of our project breakdown

16
 Figure 1.10

Figure 1.10 shows the Software Architecture of our proposed system

17
1.6. Project Time Line
Figure 1.11 shows the project timeline for Part-1. M1 is used to denote Vehicle owner to ride
sharer module

Figure 1.11 Project Timeline Part- 1

Figure 1.12 shows the project timeline for Part-2. M2 is used to denote Vehicle owner to vehicle
owner module and M3 is used to denote

18
Figure 1.12 Project Timeline part-2

19
 Chapter 2
2. Requirement Specification and Analysis
This chapter will discuss the requirement specifications of the software. In this chapter functional, non-
functional requirements, use cases, use case descriptions, and system sequence diagrams are presented to
specify the requirements of the software.

2.1. Requirement Specification

Functional requirements are documented to list all set of operations and functionalities which software must
perform. Whereas non-functional requirements describe some constraints on functional requirements to ensure
the quality of the software. Use case diagram shows possible interactions between actor and system to get some
result from the system. System sequence diagram represents the events that occur while interaction of actor with
system in a specific use case.

2.2. Functional Requirements

In table 2.1 each functional requirement is assigned a serial number which will be used as reference. Type
represents the priority of functional requirement. Status gives the information weather the requirement is
completed, pending or is currently selected for development.

20
Module S. No Functional Requirement Type Status

Ride sharer 1 The ride sharer can sign up as ride sharer. Core Implemented

2 The ride sharer can login as ride sharer Core Implemented

3 The ride sharer can upload schedule. Core Implemented

4 The ride sharer can view the available schedules Core Implemented
of vehicle owners.

Vehicle owner 5 The vehicle owner can sign up as vehicle owner Core Implemented

6 The vehicle owner can login as vehicle owner Core Implemented

7 The vehicle owner can upload schedule. Core Implemented

8 The vehicle owner can view the available Core Implemented

schedules of Ride sharers and vehicle owners.

9 The vehicle owner can ride with other Vehicle Core Implemented
Owners.

10 The vehicle owner can ride with other ride Core Implemented
sharers.

11 The vehicle owner can chat with ride sharer that Core Implemented
are sharing same schedule.

12 The vehicle owner can chat with ride sharers Core Implemented
that are sharing the same schedule.

System 13 System will calculate and generate fare and its Core Implemented
Requirement distribution.
Table 2.1 Functional Requirements

21
2.3. Non-Functional Requirements
Non-functional requirements may specify some constraints that how a specific or set of functionalities should
be achieved for the software.

S. No Non-Functional Requirement Category

1 Login should take 3 seconds • Performance

• Efficiency
• Effectivity

2 Sign up should take 5 seconds to • Performance

register the user • Efficiency
• Effectivity

3 Minimum Password length should • Security

be 6 digits

4 Each session should be off 3 minutes • Performance

Table 2.2 Non Functional Requirements

5 The system will be accessible for 24 • Reliability

hours • Availability
6 The system will be functional only with • Availability
the availability of internet

7 User receive email for the confirmation • Usability

of their registration and sign up • Data integrity
• Maintainability
8 Vehicle owner receive email for the • • Usability
confirmation of their registration and
• Data integrity
sign up Maintainability
9 The vehicle owner can give ratings only • Reliability
at the end of session. • Availability

22
2.3. System Use Case Modeling
Use case is set of activities performed by an actor on system to get some results. Use case documents the all
possible ways a system can be used. System sequence diagram is documentation of set of events to occur while
interacting with the system.

Below is the Use case diagram for the whole system

Figure 2.1 System UseCase Diagram

The above figure shows the System UseCase Diagram , that represents the functionality of the whole system
by actors ( Ride Sharer and Vehicle Owner).

23
 Figure 2.2 Vehicle Owner UseCase Diagram

The above figure shows the Vehicle Owner UseCase Diagram , that represents the functionality of Vehicle
Owner

24
 Figure 2.3 Ride Sharer UseCase Diagram

The above figure shows the RideSharer UseCase Diagram , that represents the functionality of RideSharer.

25
Use Case 1: SignUp:

Use Case ID: Uc1

Use Case Name: Sign Up

Created By: Sheema Rashid Last Updated By: Sheema Rashid

Date Created: 24/03/2019 Last Revision Date: 07/07/2019

Actors: Vehicle Owner, Rider Sharer

Description: The Ride Sharer and the Vehicle owner can sign Up by the first
time he /she used the system by providing a username, password,
mobile number and address.

Trigger: Signup button

Preconditions: Ride Sharer and the Vehicle owner provide username, password,
mobile number and address to signup and click on sign button.

Post conditions: Ride Sharer and the Vehicle owner will be signed up and will be
able to use the system.

Normal Flow: Ride Sharer, Vehicle owner System

1: Ride Sharer and the Vehicle 2 The system provides Ride

owner clicks signup button to Sharer and the Vehicle owner
request for sign up sign-up form.

3: Ride Sharer and the Vehicle

owner fills in form by providing
username, password, address and 4: System signs up the Ride
mobile number. Sharer and the Vehicle owner.

Alternative Flows: Ride Sharer and the Vehicle owner cancels the current form.

Exceptions: 1.The database is not responding.

26
 2. The Ride Sharer and the Vehicle owner has not filled the
form correctly.

3. The system is not responding.

Table 2.3SignUp UseCase Description

Use Case2: Login:

Use Case ID: Uc2

Use Case Name: Login

Created By: Sheema Rashid Last Updated By: Sheema Rashid

Date Created: 24/03/2019 Last Revision Date: 07/07/2019

Actors: Vehicle Owner, Rider Sharer

Description: Ride Sharer and Vehicle owner will Login into the system by
providing Username and password.

Trigger: Login button

Preconditions: Ride Sharer and Vehicle owner provides username, password and
then click on the sign in button.

Post conditions: Ride Sharer and the Vehicle will be signed in to the system.

Normal Flow: Ride Sharer, Vehicle owner System

1: Ride Sharer and Vehicle 2: The system will provide

owner will click Login button Login form.
to request for Login

3: Ride Sharer and Vehicle

owner will fill form by 4: System will allow to log in
providing username, to the system.
password.

5: Ride Sharer and Vehicle

owner will be Login in for the
system.

Alternative Flows: Ride Sharer and the Vehicle owner cancels the current form.

27
 Exceptions: 1.The database is not responding.

2. The Ride Sharer and the Vehicle owner has not filled the
form correctly.

3. The system is not responding.

Table 2.4 Login UseCase Description

Use Case3: Upload Schedule:

Use Case ID: Uc3

Use Case Name: Upload Schedule

Created By: Sheema Rashid Last Updated By: Sheema Rashid

Date Created: 24/03/2019 Last Revision Date: 07/07/2019

Actors: Vehicle Owner, Rider Sharer

Description: Ride Sharer and Vehicle owner can upload their weekly schedules.

Trigger: Upload button

Preconditions: Ride Sharer and Vehicle owner must be Logged in

Post conditions: The schedule of Ride Sharer and the Vehicle owner will be
successfully uploaded into the app.

Normal Flow: Ride Sharer, Vehicle owner System

1: Ride Sharer and Vehicle 2: System will accept the

owner will enter their schedule and upload it
schedules.

Alternative Flows: Nil

Exceptions: 1. The system is not responding.

Table 2.5 Upload Schedule UseCase Description

28
Use Case4: Ride:

Use Case ID: Uc4

Use Case Name: Ride

Created By: Sheema Rashid Last Updated By: Sheema Rashid

Date Created: 24/03/2019 Last Revision Date: 07/07/2019

Actors: Vehicle Owner, Rider Sharer

Description: Vehicle owner can ride with the Ride sharer or with the Vehicle
Owner as well.

Trigger: Ride Button

Preconditions: Vehicle owner must be Logged in

Post conditions: Vehicle owner will select from the different schedules to take a
ride with the matching schedule’s person.

Normal Flow: Ride Sharer, Vehicle owner System

1: Vehicle owner, Ride Sharer 2: System will send a request

will select from the different to the vehicle owner/Ride
vehicle owners or Ride Sharer for a ride.
Sharers that are having same

schedule to take a ride with

him.

Alternative Flows: Vehicle owner/ Ride Sharer keep the request partially complete.

29
 Exceptions: 1. The system is not responding.

Table 2.6 Ride UseCase Description

Use Case5: Chat:

Use Case ID: Uc5

Use Case Name: Chat

Created By: Sheema Rashid Last Updated By: Sheema Rashid

Date Created: 24/03/2019 Last Revision Date: 07/07/2019

Actors: Vehicle Owner, Ride Sharer

Description: Vehicle Owner, Ride Sharer can chat with other users that are
sharing same schedule. And he/she can chat with ride sharers.

Trigger: Chat Box

Preconditions: Schedule have been uploaded.

Post conditions: Vehicle Owner will start sending messages.

Normal Flow: Vehicle Owner, Ride Sharer System

1: Vehicle Owner/ Ride Sharer 2: System will contain the

will open the chat box and type message and will enable “send”
a message. option .

3:Vehicle Owner/ Ride Sharer 4:System will send the message

will send the message. to the specified user.

Alternative Flows: Nil

30
 Exceptions: 1. The system is not responding.

2. The database is not responding.

3. Send option is not enabled .

Table 2.7 Chat UseCase Description

Use Case6: Select from Available Schedules:

Use Case ID: Uc6

Use Case Name: Select from available schedules.

Created By: Sheema Rashid Last Updated By: Sheema Rashid

Date Created: 24/03/2019 Last Revision Date: 07/07/2019

Actors: Vehicle Owner, Ride Sharer

Description: Vehicle Owner and Ride Sharer can select from available
schedule.

Trigger: Upload button

Preconditions: Ride Sharer and Vehicle owner must be Logged in

Post conditions: The schedule of Ride Sharer and the Vehicle owner will be
successfully uploaded into the app.

31
 Normal Flow: Vehicle Owner , Ride Sharer System

1: Ride Sharer and Vehicle 2: System will show available

owner will enter their schedules. schedules. .

3:Vehicle Owner and Ride

Sharer will select from the
available Schedules. 4: System will upload that
schedule.

Alternative Flows: Nil

Exceptions: 1. The system is not responding.

2. The database is not responding.

3. Zero number of Schedules are available.

Table 2.8 Select from Available Schedules UseCase Description

2.4. System Sequence diagrams

System Sequence diagrams show the user and system interaction. System Sequence Diagram is a Sequence
Diagram that shows, for a particular scenario of a use case, the events that actors generate, and possible inter-
system events

2.4.1 SignUp

Figure 2.4 System Sequence Diagram(SignUp)

32
The above figure shows the Sign-Up scenario for Vehicle Owner, the Vehicle Owner requests to sign up and the
system registers the Vehicle Owner successfully

Figure 2.5 System Sequence Diagram(SignUp)

The above figure 2.5 shows the Sign-Up scenario for RideShare, the Ride Sharer requests to sign up and the
system registers the Ride Sharer successfully

2.4.2 Login

33
 Figure 2.6 System Sequence Diagram(Login)

The above figure shows the Login scenario for Ride Sharer, the actor requests to Login and the system logs in
the Ride Sharer successfully

Figure 2.7 System Sequence Diagram(Login)

The above figure shows the Login scenario for Vehicle Owner, the actor requests to Login and the system logs
in the Vehicle Owner successfully

2.4.3 Upload Schedule

34
 Figure 2.8 System Sequence Diagram(Upload Schedule)

The above figure 2.8 shows the upload schedule scenario for Ride Sharer, the actor wants to upload his schedule
and the systems accepts the schedule of the Ride Sharer.

Figure 2.9 System Sequence FDiagram(Upload Schedule)

The above figure shows the upload schedule scenario for Vehicle Owner, the actor wants to upload his schedule
and the systems accepts the schedule of the Vehicle Owner.
2.4.4 Select from Available Schedule

Figure 2.10 System Sequence Diagram(Select from Available Schedule)

35
The above figure 2.10 shows the Select from available schedules scenario for Ride Sharer, the actor wants to
just select from the available schedules and the system uploads that schedule for the Ride Sharer.

Figure 2.11 System Sequence Diagram(Select from Available Schedules)

The above figure shows the Select from available schedules scenario for Vehicle Owner, the actor wants to just
select from the available schedules and the system uploads that schedule for the Vehicle Owner.

2.4.5 Ride

Figure 2.12 System Sequence Diagram(Ride)

36
The above figure shows the Ride scenario for Ride Sharer, the actor wants to Ride in a vehicle and the system
allows the Ride Sharer to take a ride.

Figure 2.13 System Sequence Diagram(Ride)

The above figure shows the Ride scenario for Vehicle Owner, the actor wants to Ride in a vehicle and the
system allows the Vehicle Owner to take a ride.

2.4.6 Chat

Figure 2.14 System Sequence Diagram(Chat)

37
The above figure shows the Chat scenario for Vehicle Owner, the actor wants to chat with other users and the
system successfully sends the message.

Figure 2.15 System Sequence Diagram(Chat)

The above figure shows the Chat scenario for Ride Sharer, the actor wants to chat with other users and the
system successfully sends the message.

2.5. Domain Model

The basic concepts o of our App that is shown in the following figure representing a domain model.

There are several classes in the domain model representing the conceptual model of the system .A class User have
several data members , i,e mobileNumber, name. Similarly VehicleOwner , RideSharer, Ride, Schedule and
feedback classes have their own data members.
Now these classes are associated with one another in the following way.

 VehicleOwner and RideSharer are inheriting the data members of class User.

 Similarly, one vehilceOwner is associated with multiple rides. Which means that a vehicle owner can
take multiple rides , he/she is not restricted to only one ride.

 Schedule is associated with both, the rideSharer and the VehicleOwner which means that both the roles
must have to enter their schedules.

38
 Figure 2.16 Domain Model

The above figure shows the Initial Conceptual Model of the System including the conceptual classes of the
whole system.

Chapter 3
System Design

In this chapter we explain architecture styles, architecture patterns and design pattern. For
architecture style we use Layered architecture style and MVC architecture pattern and singleton
design pattern.

3.1. Software Architecture

Layer Description

39
 Presentation Layer This layer will be used for the interaction with the user
through a graphical user interface.

Business Logic Layer This layer contains the business logic. All the
constraints and majority of the functions reside under
this layer.

Database Layer This layer contains the database of the application

being developed.

Table 3.1

Presentation Layer:
Occupies the top level and displays information related to services available on our App. This tier
communicates with other tiers by sending results to the browser/Mobile Interface and other tiers.

Business Logic Layer:

Application Layer also called the middle tier, logic tier, business logic or logic tier, this tier is pulled
from the presentation tier. It controls application functionality by performing detailed processing.

Database Layer:
Database layer includes database servers where information is stored and retrieved. Data in this tier is kept
independent of application servers or business logic.

40
 Figure 3.1 Architecture Diagram

The above architecture diagram shows the presentation layer in which mobile interface and web interfaces are
present. Below is the business logic is present where the modules of the app is shown. at the last the Database
layer is present for the preservation of the data. Below are the internal architecture diagrams of the modules
separately.

41
 Figure 3.2 Module Vehicle Owner Architecture Diagram

Figure above shows the internal architecture of module vehicle owner where several work packages are present.
A work package is a task that is performed in a specific period of time that implements certain functionalities.

42
 Figure 3.3 Module Ride Sharer Architecture Diagram

Figure above shows the internal architecture of module Ride Sharer where several work packages are present. A
work package is a task that is performed in a specific period of time that implements certain functionalities.

3.3 Class Diagram

The class diagram describes the attributes and operations of a class and the constraints imposed on the system.
The class diagrams are widely used in the modelling of object-oriented systems because they are the only UML
diagrams, which can be mapped directly with object-oriented languages. The class diagram shown below is for
only the selected requirements. Below diagram have following relationships

• Inheritance relationship has been defined i.e. the classes VehicleOwner and
RideSharer are inheriting the attributes and setters and getters of class User.

• Composition relationship has been defined b/w Ride and VehicleOwner

43
 • Composition relationship has been defined b/w RideSharer and Schedule.

• Composition relationship has been defined b/w Vehicle Owner and Schedule.

• Composition relationship has been defined b/w Ride and RideSharer.

Figure 3.4 Class Diagram

Figure above shows the classes, their attributes, their functions and the relationship among them.

44
3.4 Sequence Diagram
Sequence Diagram model the flow of logic within your system in a visual manner enabling you both to
document and validate your logic, and are commonly used for both analysis and design purposes.

The below Sequence Diagram tells about the system flow of actions. Involved classes are VehicleOwner,
RideSharer, Schedule, Ride and User.

Figure 3.5 Sequence Diagram(SignIn)

Figure above shows the SignIn scenario of Ride Sharer. The interaction between classes during the SignIn
process is shown in diagram.

45
 Figure 3.6 Sequence Diagram(SignIn)

Figure above shows the SignIn scenario of Vehicle Owner. The interaction between classes during the SignIn
process is shown in diagram.

46
 Figure 3.7 Sequence Diagram(SignUp)

Figure above shows the SignUp scenario of Ride Sharer. The interaction between classes during the SignUp
process is shown in diagram.

47
 Figure 3.8 Sequence Diagram(SignUp)

Figure above shows the SignUp scenario of Vehicle Owner. The interaction between classes
during the SignUp process is shown in diagram.

48
 Figure 3.9 Sequence Diagram(Upload Schedule)

Figure above shows the Upload Schedule scenario of Vehicle Owner. The interaction between
classes during the Upload Schedule process is shown in diagram.

49
 Figure 3.10 Sequence Diagram(Upload Schedule)

Figure above shows the Upload Schedule scenario of RideSharer. The interaction between classes
during the Upload Schedule process is shown in diagram.

50
 Figure 3.11 Sequence Diagram(Select from Available Schedule)

Figure above shows the select from available schedules scenario of Ride Sharer. The interaction
between classes during the select from available schedules process is shown in diagram.

51
 Figure 3.12 Sequence Diagram(Select from Available Schedules)

Figure above shows the select from available schedules scenario of Vehicle Owner. The interaction between
classes during the select from available schedules process is shown in diagram.

52
 Figure 3.13 Sequence Diagram(Chat)

Figure above shows the Chat of Vehicle Owner. The interaction between classes during the Chat process is
shown in diagram.

53
 Figure 3.14 Sequence Diagram(Chat)

Figure above shows the Chat of Ride Sharer. The interaction between classes during the Chat process is shown
in diagram.

54
 Figure 3.15 Sequence Diagram(Ride)

Figure above shows the Ride of Ride Sharer. The interaction between classes during the Ride process is shown
in diagram.

55
 Figure 3.16 sequence Diagram(Ride)

Figure above shows the Ride of Vehicle Owner. The interaction between classes during the Ride process is
shown in diagram.

56
3.5 Entity Relationship Diagram
The entity-relationship model (or ER model) is a way of graphically representing the logical relationships of
entities (or objects) in order to create a database. An entity– relationship model (ER model) describes inter-
related things of interest in a specific domain of knowledge. An ER model is composed of entity types (which
classify the things of interest) and specifies relationships that can exist between instances of those entity types.

Figure 3.17 Entity Relationship Diagram

Figure above shows the logical data model, representing attributes and relationships among entities

57
3.5.1 Database Schema
A database schema represents the logical configuration of all or part of a relational database. It can exist both as
a visual representation and as a set of rules known as integrity constraints that govern a database.

.
Figure3.18 Database Schema

Figure above shows the logical view of the entire database.

58
3.6 User Interface Design
User Interface (UI) Design focuses on anticipating what users might need to do and ensuring that the interface
has elements that are easy to access, understand, and use to facilitate those actions. UI brings together concepts
from interaction design, visual design, and information architecture.

Figure 3.19 Splash Screen

User can login by email userName and password.

59
 Figure 3.20 Vehicle Owner SignUp Interface

User can signUp by providing phone number.

Figure 3.21 Set Schedule

60
 Chapter 4
Software Development

This chapter will provide the details about the coding standard, we adopted during implementation phase.

4.1. Coding Standards

The adopted coding standards are discussed in the following subsections. Indentation:
Four spaces are used as the unit of indentation. The indentation pattern should be consistently followed
throughout. Declaration:
One declaration per line is used to enhances the clarity of code. The order and position of declaration is as
follows:
• First the static/class variable is placed in the sequence: First public class variables,
protected,

• package/default level i.e. with no access modifier and then the private. As far as possible
static or class fields are explicitly instantiated.

• Instance variables are placed in the sequence: First public instance variables, protected,

• package level with no access modifier and then private.

• Next the class constructors are declared.

• Class methods are grouped by functionality rather than by scope or accessibility to make
reading and understanding the code easier.

• Declarations for local variables are only at the beginning of blocks e.g. at the beginning of a
try/catch construct.
Statement Standards:
Each line contains at most one statement. While compound statements are statements that contain lists of
statements enclosed in braces. The enclosed statements are indented one more level than the compound
statement. The opening brace at the end of the line that begins the compound statement. The closing brace to
begin a line and be indented to the beginning of the compound statement. Braces are used around all
statements, even single statements, when they are part of a control structure, such as an if-else or for statement.
A Boolean expression / function is compared to a Boolean constant.

61
Naming Conventions:
Naming conventions make programs more understandable by making them easier to read. Following
conventions are followed while naming a class or a member:
• We used full English descriptors that accurately describe the variable, method or class. For
example, use of names like editTextCode, editTextCode instead of names like x1, y1, or fn.

• Terminology applicable to the domain is used. Implying that if user refers to clients as Ride
Sharer, then the term RideSharer is used for the class, not Client.

• Mixed case is used to make names readable with lower case letters in general capitalizing the
first letter of class names and interface names.

4.2. Development Environment

Android Studio is the official integrated development environment (IDE) for the Android platform. It was
announced on May 16, 2013 at the Google I/O conference. Android Studio is freely available under the Apache
License 2.0.

The reason for using android studio was that it provides a very interactive and easy to understand interface to
work with android devices. In this tool, User can test the written code on android device and that results in better
outcomes.

Few alternatives for android studio are AIDE (Android IDE), Application Craft, Basic4Android and Cordova.

4.3. Software Description

The basic purpose of our application is to get two types of users registered who can help each other out. One
user is vehicle owner and the other is ride sharer. We believe that there should be a record of the performance
of vehicle owner facilitating a ride sharer which is why we have introduced user ranking report in our
application. This divides our projects into three main modules.

Main modules of our project are

• Ride Sharer module.
• Vehicle Owner module.
• User Ranking Report module.
Ride Sharer module
Input:
In this part the user will be registered as a ride sharer. User will open the application for the first time and will be taken to
the sign up screen in which he will provide the credentials required to sign up as a ride sharer.
Output:
The user gets successfully signed up and would be now able to see the map and the cars nearby

62
 Figure 4.1 Initialization Method

The figure 4.1 above shows that proper naming conventions have been followed in initializing the variables. As
It can be seen that variables have meaningful names such as verification_code and phone.

Figure 4.2 Verification Method

The figure 4.2 above depicts the verification method used in our signup class. The method name is set using
standard practices and the variables used inside the method also have meaningful names.

63
 Figure 4.3 SignUp Method

The figure above shows the signup method in which the verification method is being called and the user gets

signed up after being verified.

64
 Chapter 5

Software Testing

This chapter provides a description about the adopted testing procedure. This includes the selected
testing methodology, test suite and the test results of the developed software.

5.1. Testing Methodology

We have used black box testing in our testing phase. We used black box testing because it is very
efficient and it contains following benefits. Black box testing is a method of software testing that
examines the functionality of an application without peering into its internal structures or workings.
This method of test can be applied virtually to every level of software testing: unit, integration,
system and acceptance. Black box unit testing is used in our project.

Unit testing is a software testing method by which individual units of source code, sets of one or
more computer program modules together with associated control data, usage procedures, and
operating procedures, are tested to determine whether they are fit for use:

• Black box tests are reproducible.

• Find software bugs early.
• Facilitates change.
• The environment the program is running is also tested.
• The invested effort can be used multiple times.
• More effective on larger units of code than glass box testing.
• Tester needs no knowledge of implementation, including specific programming
languages.
• Tests are done from a user's point of view.
• Will help to expose any ambiguities or inconsistencies in the specifications.

5.2. Testing Environment

5.2.1. Monkey:
Monkey is a command line tool that runs over adb shell command line. It generates n number
of random events such as random touches, gestures, system level events, etc. and sends to the
system or app which you want to test.

65
Monkey performs following functionalities.

• It helps developers perform stress as well as unit tests.

• It helps catch frequent exceptions like null pointer exceptions, unhandled
exceptions, ANR (Application not responding) etc. faster and easier.
• It also handles system level events like background application performance and
parallel running applications in a better manner.

Steps to perform:

• Install the application in an android device/emulator

• Open command prompt and navigate to the platform-tools in the android sdk • Run
the app on the device and open the activity to be tested • Run the monkey
command and let the activity test.

Date: April 12, 2019

System: Ride Buddy

Objective: Sign up Test ID: 1

Version: 1 Test Type: Unit testing
Input:
Phone Number: 923070158856
Expected Result: User will get an OTP after
which he/she will be signed in to the system.

Actual Result: passed

Table 5.1 UserSignUp TestCase

Description:
The table above depicts the test case for the signup of ride sharer in which we have taken a phone number of
“923070158856” to get a ride sharer signed up. And the test case passed successfully. The figure 5.1 below
shows the Monkey tool performing that test.

66
 Figure 5.1 SignUp TestCase(Through Monkey Tool)

Date: April 12, 2019

System: Ride Buddy

Objective: Sign in Test ID: 2

Version: 1 Test Type: Unit testing
Input:
Phone Number: 923070158856
Expected Result: User will get an OTP after
which he/she will be signed in to the system.

Actual Result: passed with the exception that

authentication gets blocked if there is unusual
activity.
Table 5.2 User SignIn TestCase
Description:
The table above depicts the test case for the sign in of ride sharer in which we have taken a phone number of
“923070158856” to get a ride sharer logged in. And the test case passed successfully.

The figure 5.2 below shows the Monkey tool performing that test.

Figure 5.2 SignIn TestCase(Through Monkey Tool)

Date: April 12, 2019

System: Ride Buddy

Objective: Sign up Test ID: 3

Version: 1 Test Type: Unit testing
Input:
Location: PWD housing society
Expected Result: User will get a list of available
vehicle owners going to the same destination

Actual Result: passed

Table 5.3 Calling a Ride TestCase
Description:
The table 5.2 depicts the test case for the calling of ride by the ride sharer in which we are inputting the location
of PWD housing society to see the number of vehicle owners going to that area. And the test case passed
successfully. The figure 5.3 below shows the Monkey tool performing that test.

Figure 5.3 Call a Ride TestCase (Through Monkey Tool)

 Chapter 6

Software Deployment

6.1. Installation / Deployment Process Description

For the deployment, we will provide user with the apk of android application. Apk is generate by process
described below

1. Change Android studio from Debug mode to Release mode.

Figure 6.1 debug variant

Figure 6.2 release variant

2. Now selected generate signed apk from Build section of android studio.
 Figure 6.3 build a signed apk

3. Create key and store in system path also set password for future.

4. Now select release mode and destination for storing apk.

Figure 6.4 apk destination path

5. Apk generate.

After Generating apk place it in apk folder and create another folder for banners of two different size. Create
another folder named it source code and out source code of application in this folder and at last put screenshots
of different sizes in screenshot folder.

Now put all these folder in project name folder and deploy it suing play store.