WERABE UNIVERSITY

COLLEGE OF INFORMATION TECHNOLOGY (IOT)

DEPARTMENT OF INFORMATION TECHNOLOGY

Meheja Transport Mobile Application

Group members ID
Dagim Ayele NSR/0281/13
Ermiyas Elias NSR/0398/13
Juhar Eyayew NSR/0617/13

2023
Werabe, ETHIOPIA
Certificate of Approval

WERABE UNIVERSITY

COLLEGE OF INFORMATION TECHNOLOGY (IOT)

DEPARTMENT OF INFORMATION TECHNOLOGY

Meheja Transport Mobile Application

A Project Submitted to the Department of Information Technology of Werabe University in Partial

Fulfilment of the Requirements for the Degree of Bachelor of Science in Information Technology .

Group members ID
Dagim ayele NSR/0281/13
Ermias Eliyas NSR/0398/13
Juhar eyayew NSR/0617/13

Advisor: Msc.Anbesaw

December 3, 2023

Werabe University, Ethiopia

I
Declaration
We, the undersigned, declare that this project is our original work and has not been presented for
a degree in any other university, and that all sources of materials for the industrial project we
have been duly acknowledged.

Dagim Ayele _________________

Ermiyas Elias _________________

Juhar Eyayew __________________

__________________

December 3, 2023

This project has been submitted for examination with my approval as an advisor.

______________
Msc.Anbesaw
December 3, 2023

II
Acknowledgement
we would like to take this opportunity to first and foremost thank God and his mother St. Mary for
being our strength and guide in my life. Our most sincere and heartfelt thanks go to (Msc.Anbesw)
our documentation advisor, for his unreserved and timely support in checking, commenting and
giving constructive advice all along my activities we would like to express my deepest
appreciation and indebtedness to him. Finally, we would like to close my acknowledgements by
giving deeply indebted to our group member who are not mentioned above but without them the
success of this paper is unthinkable.

III
Table of Contents
Certificate of Approval .................................................................................................................... I

Declaration......................................................................................................................................II

Acknowledgement ........................................................................................................................ III

List of Tables ...............................................................................................................................VII

List of Figures ............................................................................................................................ VIII

List of Abbreviations/Acronyms.................................................................................................... X

Abstract ......................................................................................................................................... XI

CHAPTER ONE ............................................................................................................................. 1

1. INTRODUCTION .................................................................................................................. 1

1.1. Motivation of the Project.................................................................................................. 2

1.2. Statement of the Problem ................................................................................................. 2

1.3. The Objective of the Project............................................................................................. 2

1.3.1. General objective ...................................................................................................... 2

1.4. Methodology of the Project.............................................................................................. 3

1.4.1. Data collection methodology .................................................................................... 3

1.4.2. Tool/Software utilized .............................................................................................. 3

1.4.3. System development methodology ........................................................................... 4

1.5. Scope and Delimitation of the project.............................................................................. 5

1.6. Significance of the Project ............................................................................................... 5

1.7. Organization of this Work................................................................................................ 5

CHAPTER TWO USER ................................................................................................................. 6

2. USER REQUIREMENTS AND ANALYSIS ........................................................................ 6

2.1. Overview Of Existing Systems ........................................................................................ 6

2.1.1. Actors of existing system.......................................................................................... 6

IV
 2.1.2. Description of the existing system............................................................................ 6

2.2. Overview Of Proposed Systems....................................................................................... 8

2.2.1. Actors of proposed system........................................................................................ 8

2.2.2. Description of the proposed system.......................................................................... 8

2.3. Functional Requirement (Data Collection) .................................................................... 10

2.4. Class Responsibility Collaborator (CRC) ...................................................................... 11

2.4.1. actor classes ............................................................................................................ 11

2.4.2. Business Classes ..................................................................................................... 11

2.4.3. UI Classes ............................................................................................................... 12

2.5. Supplementary Specification ......................................................................................... 12

2.5.1. Business Rules ........................................................................................................ 12

2.5.2. Nonfunctional Requirements .................................................................................. 13

2.5.3. Constraints .............................................................................................................. 14

2.6. Use Case Modeling ........................................................................................................ 15

2.6.1. Essential Use Case Modeling.................................................................................. 15

2.6.2. System Use Case Modeling .................................................................................... 16

2.6.3. System Use Case Description ................................................................................. 17

2.7. User Interface Prototyping ............................................................................................. 20

2.8. Activity Diagram............................................................................................................ 23

2.9. Sequence Diagrams ........................................................................................................ 29

CHAPTER THREE ...................................................................................................................... 33

3. SYSTEM DESIGN ............................................................................................................... 33

3.1. Layering Your Models- Class Type Architecture .......................................................... 33

3.2. Class Modeling............................................................................................................... 34

3.3. User Interface Design..................................................................................................... 37

V
 3.4. State Chart Diagram ....................................................................................................... 38

3.5. ERD & Normalization of Table ..................................................................................... 42

3.5.1. Normalized Table.................................................................................................... 42

3.5.2. Entity Relationship Diagram................................................................................... 43

3.6. Relational Persistent Modeling ...................................................................................... 45

3.7. Component Diagram ...................................................................................................... 46

3.8. Deployment Diagram ..................................................................................................... 47

Reference ...................................................................................................................................... 48

VI
List of Tables
Table 1Actor CRC ........................................................................................................................ 11
Table 2 Admin CRC ..................................................................................................................... 11
Table 3 Driver CRC ...................................................................................................................... 11
Table 4 Payment CRC .................................................................................................................. 11
Table 6 Ride status CRC............................................................................................................... 11
Table 7 Rete CRC ......................................................................................................................... 12
Table 8 payment UI CRC ............................................................................................................. 12
Table 9 Ride book CRC................................................................................................................ 12
Table 10 use case ID ..................................................................................................................... 17
Table 11 registration use Case Description .................................................................................. 18
Table 12 Ride Book use Case Description ................................................................................... 18
Table 13 Rate Driver use Case Description.................................................................................. 19
Table 14 Rate passenger use Case Description............................................................................. 19
Table 15 Login use Case Description ........................................................................................... 20
Table 16 Account normalized....................................................................................................... 42
Table 17 Passenger normalized .................................................................................................... 42
Table 18 Driver normalized .......................................................................................................... 42
Table 19 Payment normalized ...................................................................................................... 42
Table 20 Ride status normalized.................................................................................................. 42
Table 21 Rate normalized ............................................................................................................. 43
Table 22 Ride book....................................................................................................................... 43

VII
List of Figures
Fig. 1 General overview of waterfall model .................................................................................. 4
Fig. 2 Essential Use case Diagram............................................................................................... 15
Fig. 3 System use case symbols................................................................................................... 16
Fig. 4 System use case Diagram .................................................................................................. 17
Fig. 5 Meheja opening page......................................................................................................... 21
Fig. 6 Registration form prototype............................................................................................... 21
Fig. 7 Ride booking Prototype .................................................................................................... 22
Fig. 8 Payment UI prototype....................................................................................................... 22
Fig. 9 Registration Activity diagram ........................................................................................... 24
Fig. 10 Login Activity diagram ................................................................................................... 24
Fig. 11 Passenger Ride booking Activity diagram ...................................................................... 25
Fig. 13 Payment Activity diagram ............................................................................................... 26
Fig. 14 Rating Activity diagram .................................................................................................. 27
Fig. 15 Update fee Activity diagram........................................................................................... 27
Fig. 16 Admin create account Activity diagram.......................................................................... 28
Fig. 17 Approve payment Activity diagram ................................................................................ 28
Fig. 18 Login sequence diagram................................................................................................. 29
Fig. 19 registration sequence diagram ......................................................................................... 30
Fig. 20 rate sequence Diagram..................................................................................................... 31
Fig. 21 Update fee sequence diagram .......................................................................................... 32
Fig. 22 Class Type Architecture .................................................................................................. 34
Fig. 23 Class Diagram.................................................................................................................. 36
Fig. 24 UI flow Diagram.............................................................................................................. 37
Fig. 25 Login state chart Diagram ............................................................................................... 38
Fig. 26 Registration state chart Diagram ..................................................................................... 38
Fig. 27 Payment state chart Diagram........................................................................................... 39
Fig. 28 Rete state chart Diagram................................................................................................. 40
Fig. 29update fee state chart Diagram ......................................................................................... 40
Fig. 30 payment Approval state chart Diagram ........................................................................... 41
Fig. 31 ERD Diagram .................................................................................................................. 44

VIII
Fig. 32 persistence Diagram ........................................................................................................ 45
Fig. 33 Component Diagram........................................................................................................ 47
Fig. 34 Deployment Diagram ...................................................................................................... 48

IX
List of Abbreviations/Acronyms
BR Business Rules
CRC Class responsibility Diagram
ER Entity Relationship
ERD Entity Relationship Diagram
IT Information technology
KM Kilo Meter
GPS Global positioning System
PDF Portable File Format
RDBMS Relational Database Management System
RPM Relational Persistent Modeling
SQL Structured query language
UI User interface
UML Unified Modeling Language

X
Abstract
Mobile-based Transportation service system (Meheja app) is an application that tracks nearest
vehicles driver that is found around the customer and give vehicles service for the customer that
sends request, Tracking System involves in the mobile phone of both driver and customer, real
time GPS tracking device to enable the system to track near driver and to know the location of
customer. There will be two applications that are for the driver and for the customer, there will be
Administrator that uses the web application in the server in order to manage user and view
feedback. Driver and customer carry real time GPS devices on their phones. By The positions to
the server are periodically updated. The server will monitor the location and will store its data in
the database. It is a real-time system as this method automatically sends the information on the
GPS system to a central computer or Android-based smartphone. This document explains the
existing system study, the drawback of the existing system, proposed solution, preferred solution,
overview of the new system, system requirements (functional and non-functional requirements),
system UML modeling (use case diagram, class diagram, persistence diagram, and deployment),
proposed solution architecture, subsystem decomposition. So that this project declares solutions
for this identified problem. This project converts the existing manual system vehicles into
Meheja mobile-based system that gives beneficiaries for the customer and driver to easily
interact to the system. The necessary data is gathered by interviewing the customer which is
found in Harar and also referring the written document that related to our topics.

XI
CHAPTER ONE
1. INTRODUCTION
1.1 Background
Transportation is a major necessity in many people's live, especially to facilitating people in
conducted their daily activities such as going to school, office, vacation, and others. With the
speed of technology development in this era and the so-called, the internet has allowed us to
receive information easily and quickly. In the world of today, online transportation has
become a phenomenon with the purpose of creating a convenient way for people to get
access to transportation.

Efficiency is an important element in the widespread use of the internet. Activities within the
network enable individuals to learn more about the world. On one hand, the impact of
increasingly open internet access has been primarily used for economic exchanges. Current
technological development has brought changes and development in the of transportation. Online
transportation service has become a means of transportation development which able to attract
people's interest. The emergence of online transportation service has created a convenient way
for people to obtain access to transportation[1].

Meheja mobile-based taxi service provider is a mobile-based system that is designed in order to
facilitate the transportation system in Werabe by bringing a technological system to use the
taxi service which is new to Werabe town.

Introducing this kind of system to the town could bring development to the technology and it can
increase the transportation facility in the day-to-day life of the people because nowadays
technology play a great role in the development of one country, our project contributes to the
development of Werabe on the transport sector this led to the attraction of tourist and
other organization to the town.

The system's design and development started with a smartphone application that was simple to
download and set up. The application was made accessible to a wide range of users by being
available for Android platforms. Passengers can easily navigate through various features and
functionalities thanks to the app's intuitive and friendly user interface.

1
The app offered riders a practical way to make ride requests. Users only needed to open the app,
enter their pickup and drop-off locations, and select their preferred mode of transportation
including formal taxis and Bajaj from a variety of choices. The app incorporates real-time GPS
technology, allowing for accurate location tracking and effective matching of passengers with
available drivers nearby.

Meheja mobile-based taxi service will improve the current transportation system off to the next
level by adding a mobile-based technological system that uses digital map and track nearby
vehicles that can arrive in the location where the customer is using the system.

1.1. Motivation of the Project

We are motivated to Meheja Transport System is to address existing difficulties in Werabe
transportation system and create a comprehensive solution that improve the way people travel by
providing a dependable and controlled transportation network through the use of technology.
Furthermore, Meheja's distinct selling point is that it focuses on serving locations outside of
Addis Ababa. providing efficient and reliable rides to passengers in regional cities and towns
while also addressing pricing inconsistencies, safety concerns, communication inefficiencies, and
a lack of a reliable payment system that plague the current transportation system.

1.2. Statement of the Problem

The Werabe city mostly used Bajaj transportation system as a primary means of transportation, there
is no modern way to book a ride with them except by calling the driver if you have their number.

For the vast majority of people, who lack access to cars and must physically look for a taxi service,
this presents a problem.

Furthermore, Werabe does not have access to ride-hailing apps, which makes it challenging
for residents to locate other transit options. Additionally, it might be difficult to commute even
by cab in tiny communities like Werabe because there aren't many routes available, which
frequently forces people to walk.

1.3. The Objective of the Project

1.3.1. General objective
The general objective of this project is to design and develop a mobile application that provides
ride booking services to users with available transportation services in werabe.

2
 1.3.2. Specific objectives
The specific objectives of this project are:

Ø To enable book rides with Bajaj in Werabe via a smartphone using Meheja application.
Ø Provide a simple and intuitive user interface for seamless booking and ride management
Ø Implement a driver registration and verification system
Ø To Establish a real-time ride tracking and navigation system
Ø To implement an automated fare calculation and payment system.

1.4. Methodology of the Project

1.4.1. Data collection methodology
Data collection is a crucial aspect of any research it is the process of gathering information or data
from various sources in a systematic and structured manner. Data can be collected through various
methods such as surveys, interviews, brainstorming and observations. The following data
collection methods have been used to understand how the current system functions and what
issues exist.

Ø Observation: we will try to observe the current transportation system of Harar from that
we try to gather some data that are related to our project and enable us to understand and
list out how transportation is going in the town.
Ø Brainstorming: - we will use our previous experience on the developing of other
systems, thinking and reasoning of real-world problems.

1.4.2. Tool/Software utilized

Microsoft Edge Browser and Google Chrome browser

used for real-time on document, diagram and files editing together.

Draw.io

Used to create different types of diagrams, including activity diagrams, sequence diagrams,
deployment diagrams, and state charts…

Figma

This application is used to develop and create UI prototypes. Group members use Figma to
collaborate on the project's user interface prototype design.

3
 1.4.3. System development methodology
We have decided to use the Waterfall model as our software development technique. The waterfall
model uses a logical progression of SDLC steps for a project, similar to the direction water flows
over the edge of a cliff. It sets distinct endpoints or goals for each phase of development. Those
endpoints or goals can't be revisited after their completion[2]

Fig. 1 General overview of waterfall model

The stages of "The Waterfall Model" are:
Ø Requirement Analysis & Definition: This phase is focused on possible requirements of the
system for the development are captured. Requirements are gathered subsequent to the
end user consultation.
Ø System & Software Design: The requirement specifications are studied in detail in this
phase and the design of the system is prepared. The design specifications are the base for
the implementation and unit testing model phase.
Ø Implementation & Unit Testing: The system is developed into small coding units. These
units are later integrated in the subsequent phase. Every unit is tested for its functionality.
Ø Integration & System Testing: The modules that are divided into units are integrated into
a complete system and tested for proper coordination among modules and system
behaves as per the specifications
Ø operations & Maintenance: It is a never-ending phase. once the system is running in
production environment, problems come up. The issues that are related to the system are
solved only after deployment of the system. The problems arise from time to time and
need to be solved" hence this phase is referred as maintenance[3]

4
 1.5. Scope and Delimitation of the project
Usually, in werabe city, the system is able Registration of Customers which means the driver can
send his details to the customer including taxi current status, Registration of Drivers which
means the passengers can book with required details of them and send to the driver and they
could check a confirmation message whether their request is accepted or denied by the driver
and Meheja application included. The restriction of this proposed system is it does not work if
the driver is not online and real time GPS is mandatory to calculate and guide travel.

1.6. Significance of the Project

Ø This Meheja Application provides many significant advancements in transportation
industry for werabe city.
Ø It will provide easily accessible transport service because we can book ride from where
we are despite of location and time.
Ø It will minimize faire disagreement the system calculates total fee.
Ø It will minimize the extra effort to get transport service by using Meheja and increase our
productivity by reducing effort and time wastage
Ø Using Meheja app the user can easily book or cancel booking.
Ø Provide Cashless payment options

1.7. Organization of this Work

The project organized three chapters: the first chapter about introduction, statement of problem,
objective, significance and scope. The second chapter deals with user requirement analysis which
means UML diagram. The system design like architecture, deployment, component diagram on
chapter three

5
CHAPTER TWO USER
2. USER REQUIREMENTS AND ANALYSIS
2.1. Overview Of Existing Systems
2.1.1. Actors of existing system
Passengers: Individuals seeking transportation from one location to another.
Drivers: Individuals who provide transportation services using their taxis or Bajaj vehicles.
2.1.2. Description of the existing system
The traditional way of taking a ride in werabe involves manually searching for taxis or Bajaj,
negotiating fares, and relying on physical or phone call communication and transactions between
passengers and drivers.

Passenger's Point of View scenario 1:

i. The passenger obtains the contact number of a taxi or Bajaj driver through word-of-oral
recommendations or directories.
ii. The passenger manually dials the driver's phone number.
iii. The passenger explains their location and desired destination to the driver over the phone.
iv. The passenger negotiates the fare and confirms the pickup time and location with the
driver. v. Both the passenger and driver rely on verbal communication and trust to
ensure the
agreement is understood.
vi. The passenger waits at the agreed pickup location until the driver arrives.
vii. Upon arrival, the passenger boards the vehicle and pays the negotiated fare in cash.
viii. The passenger communicates any changes or additional stops directly with the driver
during the journey.
ix. Once the destination is reached, the passenger disembarks from the vehicle, and the
transaction is completed.

Passenger's Point of View scenario 2:

i. The passenger needs to search for a taxi or Bajaj by walking or standing on the roadside.
ii. Spotting an available vehicle, the passenger needs to wave or signal to get the driver's
attention.
iii. The passenger negotiates the fare directly with the driver, often facing challenges and
potential price inflation.
6
 iv. After agreeing on the fare, the passenger boards the vehicle and communicates the desired
destination.
v. Throughout the journey, the passenger has limited visibility and control over the route
taken by the driver.
vi. Upon reaching the destination, the passenger pays the negotiated fare in cash.
vii. The passenger disembarks from the vehicle and the transaction is completed.

Driver's Point of View scenario 1:

i. The driver advertises their contact number through various means or receives referrals
from previous customers.
ii. The driver receives a phone call from a passenger inquiring about a ride.
iii. The driver listens to the passenger's location and desired destination.
iv. The driver negotiates the fare with the passenger over the phone, considering factors such
as distance and time.
v. Once an agreement is reached, the driver confirms the pickup time and location with the
passenger.
vi. The driver navigates to the pickup location based on the information provided by the
passenger.
vii. Upon arrival, the driver picks up the passenger and begins the journey.
viii. The driver follows the directions given by the passenger or relies on their knowledge of
the area.
ix. The driver collects the negotiated fare in cash from the passenger upon reaching the
destination.
x. The driver drops off the passenger and concludes the transaction.

Driver's Point of View scenario 2:

i. The driver drives around different areas in werabe in search of potential customers.
ii. Observing a passenger signalling for a ride, the driver stops the vehicle to pick them up.
iii. The driver engages in negotiation with the passenger to agree on the fare, considering
factors such as distance and time of day.
iv. After reaching an agreement, the driver allows the passenger to board the vehicle.

7
 v. Throughout the journey, the driver follows the directions provided by the passenger or
relies on their knowledge of the area.
vi. Upon reaching the destination, the driver collects the negotiated fare in cash from the
passenger.
vii. The driver drops off the passenger and continues searching for new customers.

2.2. Overview Of Proposed Systems

2.2.1. Actors of proposed system
Passengers: Individuals seeking transportation from one location to another.
Drivers: Individuals who provide transportation services using their taxis or Bajaj vehicles.
System Admin: information technology (IT) professionals who make sure an organization’s
computer systems are functioning and meet the needs of the organization.

2.2.2. Description of the proposed system

The Meheja ride-hailing app operates in Werabe, Ethiopia, providing convenient and reliable
transportation services to the local population. Whether residents or visitors, individuals in
Werabe can easily download the Meheja app on their mobile devices and access a wide
range of transportation options. From formal taxis to Bajaj and other locally available
means of transportation, the app caters to the diverse needs of passengers in Werabe. By
utilizing real-time GPS technology, the app efficiently matches passengers with available drivers
in the area, ensuring prompt pickups and efficient travel routes. With its presence in Werabe,
Meheja aims to enhance mobility and accessibility for the community, making transportation
more accessible, affordable, and convenient for all.

Passenger's Point of View:

i. Download the Meheja app from the respective app store and create an account.
ii. Open the app and log in with the registered credentials.
iii. Set the pickup location by either manually entering the address or using the GPS feature
to automatically detect the current location.
iv. Choose the desired destination by entering the address or selecting from saved locations.
v. Select the preferred type of ride (e.g., formal taxi, Bajaj, etc.) and any additional ride
options if available.
vi. Review the estimated fare and driver details, including name, vehicle type, and rating.

8
vii. Confirm the ride request and wait for a driver to accept the request.
viii. Once a driver accepts the request, the passenger will receive driver contact information
and real-time updates on the driver's location.
ix. Track the driver's arrival on the map and be ready at the pickup location.
x. Enjoy the ride and reach the destination safely.
xi. Pay for the ride using the preferred payment option, such as cash or online payment,
through the app.
xii. Provide feedback and rate the driver's service for future reference.

Driver's Point of View:

i. Download and install the Meheja driver app from the respective app store.
ii. Register with the Meheja app as a driver by providing the required information and
completing the verification process.
iii. Log in to the driver app using the registered credentials.
iv. Enable the driver availability status to start receiving ride requests.
v. Receive incoming ride requests with pickup and drop-off locations displayed on the app.
vi. Accept or decline the ride request based on availability and proximity.
vii. If accepted, the driver will see the passenger's details, including name, pickup location,
and contact information.
viii. Navigate to the pickup location using the app's built-in GPS or preferred navigation
system. ix. Arrive at the pickup location and confirm passenger identity.
i) Start the trip on the app and provide a smooth and comfortable ride to the destination.
x. End the trip in the app after reaching the drop-off location.
xi. Accept payment from the passenger either in cash or through the app's online payment
system.
xii. Receive feedback and ratings from the passenger for future reference.

System admin point of view

i. Account Creation: The admin creates user accounts for drivers who want to join the
platform. This includes confirming driver credentials, gathering required information such
as identification documents and car registration details.

9
 ii. Updated Fees means: any Fees, as amended, which will apply to the provision of the
Services.
iii. Payment Approval: The admin evaluates and approves payment requests like Cashin and
withdrawal.

2.3. Functional Requirement (Data Collection)

Functional requirement defines what the systems do or the actual functionality of our system. It
is a function or feature that must be included in our system to satisfy the need and be acceptable
to the user. When the users introduce him/her to the system through a user password and
username, the system will assign the corresponding privilege to the user. Thus;

The following are functional requirement in our system.

Ø The application shall register new driver or customer to the system.

Ø The application shall have a login system, which allows driver and customer to
authenticate him or herself.
Ø The application shall have a GPS navigation system, which will be integrated into the
application to find the current location of the authenticated customer so that after selecting
the suggested position, drivers shall be guided to the selected place without the need to
change to another GPS navigation application.
Ø The system offers a tariff settlement application interface. The administrator can update
the tariff after filling out the form and sending it to the system.
Ø The customer shall be allowed to send a request for nearest transport service provider.
Ø The customer should be allowed to choose Vehicle type.
Ø The customer should be allowed to set destination location.
Ø The customer should be allowed to give feedback for the trip and rate for the driver.
Ø The application shall search for nearest taxi service in the Werabe town, for
customers. Ø The driver should be allowed to accept customer request.
Ø Emergency panic button: users and drivers can quickly request an ambulance in case of an
accident and report theft incidents to notify the police for emergency assistance.

10
 2.4. Class Responsibility Collaborator (CRC)
2.4.1. actor classes
Table 1Actor CRC Table 2 Admin CRC

Passenger <<Actor>> Admin <<Actor>>

Phone number Driver Username Passenger
Balance Admin Gender Driver
Register () Payment<<UI>> Password Register <<UI>>
Ride booking () Ride First_Name Ratedriver <<UI>>
Rate driver () booking<<UI>> Last_Name Ride
Pay payment () Registration<<UI>> User type booking<<UI>>
create _account
update _fee()
payment
_approval()

Table 3 Driver CRC

Driver <<Actor>>
Phone_number Passenger
Password Admin
Gender Payment<<UI>>
First_Name Ride
Last_Name booking<<UI>>
Balance: float Ratepassenger
Rate: float <<UI>>
License Ride
Num: float _status<<UI>>
Targa num
Receive _Payment ()
Rate passenger ()

2.4.2. Business Classes

Table 4 Payment CRC
Payment Table 5 Ride status CRC
Payment _id Passenger
Reason: string Driver Ride status
Issues_date admin Initial _time Passenger
+date/time Payment<<UI>> end_time Driver
Pay_ driver ()
Start ride ()
Varifay _payment ()
Stop ride ()
End ride ()

11
Table 6 Rete CRC

Rate driver
Rate Passenger
Comment Driver
Rate() Rate<<UI>>
2.4.3. UI Classes
Table 7 payment UI CRC

Payment<<UI>>
Payment_id Passenger
Peyer_phonenumber Driver
Receiver_phonenumber Table 8 Ride book CRC
reason Ride_booking<<UI>>
Issues_date
star Passenger
rate Driver
Setdestination()

2.5. Supplementary Specification

2.5.1. Business Rules
BR001: User Authentication

Only registered users with required validity can access the proposed system. Before granting
access usernames and passwords must be verified.

BR002: Ride Request Validation

When requesting a ride, the user must provide valid pick-up and drop-off locations. The pick-up
location must be within the service area.

BR003: Driver Availability

Only registered and available drivers can accept ride requests. Drivers must be in active status and
within service coverage.

BR004: Fare Calculation

Fares are calculated based on factors such as distance, time and surcharges (fare increases, tolls,
etc.). Fare calculation should be transparent and easy for users to understand.

BR005: Payment Processing

12
User payment data must be securely stored and processed for each trip. Payments must be
processed correctly, securely and quickly. Users should be able to choose from a variety of
payment methods (Cash, Online Meheja payment.).

BR006: Feedback and Rating

Users should be able to rate and provide feedback on their driving experience.

BR007: Security and Safety

User personal information should be protected and treated in accordance with the Privacy Policy.
Drivers and passengers must follow safety guidelines and regulations while driving.

BR008: Dispute Resolution and Customer Support

User must have access to customer support for ride issues and disputes. Disputes must be resolved
in a timely and fair manner to ensure customer satisfaction.

2.5.2. Non-functional Requirements

Non-functional requirements specify the quality attributes of the system, hence their second name
quality attributes.

· Ride History: Keep track of previous rides for both passengers and drivers, including
date, time, pickup, and destination.
· Estimated Arrival Time and Fare Calculation: Determine and show the estimated
arrival time and fare for each journey based on distance, traffic, and other relevant factors.
· Real-time Tracking: Allow passengers to track the designated driver's location in real-
time during the ride.
· Scalability and Modifiability: Create the system in a modular and scalable fashion,
enabling for easy modification and deployment to other Ethiopian cities and towns. This
means that the system may be customized to match the specific needs and peculiarities of
each place.
· Security: To make the system secure the software development team protect the most
valuable assets.

13
 · Efficiency: To ensure the efficiency of the system we minimize large size data or
resources i.e., image, map on the system. The resources required for the new system will
be low, the coordinates (latitude and longitude). In the meantime, the system able to
operate fast.
· Usability: in today generation most of the peoples use smartphone most of them are
android based therefor our system operates on an Android-based smartphone so the user
has the knowledge to operate android application in case our system does not need extra
knowledge to use it furthermore and the user does not need to learn the system.
· Error handling: Our system handles the error by showing the message” invalid input”
when the user enters invalid input. When the users of the system interact with the system
errors may appear. To control these inaccuracies the system will generate
different messages. When users of the system input wrong usernames or passwords, the
system pops up failure message which tells them that either user name or password is not
correct

2.5.3. Constraints
Availability: The availability of Vehicle must be managed in real-time to ensure that customers
can book a ride whenever they need one

Capacity: The number of passengers and the amount of luggage that a Vehicle can carry must be
taken into account when booking a ride.

Location: The system must be able to accurately determine the pick-up and drop-off locations for
each ride.

Time: The system must be able to handle time-sensitive bookings, such as scheduling rides in
advance.

Payment: The system must support various payment methods, including credit cards, cash, and
mobile payments.

14
 2.6. Use Case Modelling
2.6.1. Essential Use Case Modelling
An essential use case is a structured narrative, expressed in the language of the application domain
and of users, comprising a simplified, generalized, abstract, technology-free and implementation
independent description of one task or interaction that is complete, meaningful, and well-defined
from the point of view of users in some role or roles in relation to a system and that embodies the
purpose or intentions underlying the interaction[4].

Fig. 2 Essential Use case Diagram

15
 2.6.2. System Use Case Modelling
A use case is a concept used in software development, product design, and other fields to describe
how a system can be used to achieve specific goals or tasks. It outlines the interactions between
users or actors and the system to achieve a specific outcome[5].

Fig. 3 System use case symbols

Anatomy of Use Cases: Basic Diagrams

Ø Actors are represented as stick figures

Ø Use Cases as ellipses
Ø Lines represent associations between these things
Ø Use Case diagrams show who is involved with what

Use Cases Basics

Ø Actors: An Actor is external to a system, interacts with the system, may be a

human user or another system, and has a goals and responsibilities to satisfy in
interacting with the system.
Ø Use Cases: identify functional requirements, which are described as a sequence of
steps describe actions performed by a system capture interactions between the
system and actors.
Ø Relationships: Actors are connected to the use cases with which they interact by a
line which represents a relationship between the actors and the use cases.
Ø System Boundaries: Identify an implicit separation between actors (external to the
system) and use cases (internal to the system)[6].

16
Fig. 4 System use case Diagram
2.6.3. System Use Case Description
A use case is a written description of how users will perform tasks on your website. It outlines,
from a user’s point of view, a system’s behaviour as it responds to a request. Each use case
is represented as a sequence of simple steps, beginning with a user's goal and ending when that
goal is fulfilled[6].

Table 9 use case ID

Use case name use case Id

Register us01
Ride Book us02
Rate Driver us03
Rate Passenger us04
Login us05

17
Table 10 registration use Case Description

Use case name Register

Use case ID us01
Participating actors Passenger
Pre-condition The passenger must have volunteer to use this system

Post condition The passenger has registered

Include None

Extend None

Basic flow 1. Passenger open registration form

2. System gives registration form
3. Passenger fill the form
4. Passenger submit the form
5. System checks the inputs and sends registration successful
message. 6. End use case
Exceptional flow A5. System displays error message and ask to re-try
A6. The passenger corrects entered form
A7. System checks the inputs and sends registration successful message.
A8. End use case

Table 11 Ride Book use Case Description

Use case name Ride Book

Use case ID us02
Description Ride booking
Participating Passenger, Driver, System
actors
Pre-condition Ø The passenger must have Meheja Application and desire to be
somewhere
Ø Passenger and driver must be registered
Post condition users Ride will be booked

Include None

Extend None

Basic flow 1. Passenger and Driver open Meheja application

2. A) passenger select destination
B) Driver Go online
3. System Find GPS location

18
 4. Passenger selects vehicle type
5. Passenger send request
6. System finds nearest diver
7. System send request to Driver
8. Driver Accepts request
9. System registers booked Ride.
10. Use case end.
Exceptional flow A8 Driver Rejects request
A9 System transfer request to next nearest Driver
A10. End use case

Table 12 Rate Driver use Case Description

Use case name Rate Driver

Use case ID us03
Description Passenger rates Driver 1-5 starts for their time together
Participating actors Passenger
Pre-condition The passenger must have taken service from driver

Post condition Rate Driver

Include None

Extend None

Basic flow 1. System sends rating page for passenger

2. Passenger fill rating
3. System sends accepted message
4. End use case
Exceptional flow A2. Driver cancel rating page
A3. End use case
Table 13 Rate passenger use Case Description

Use case name Rate passenger

Use case ID us04
Description Driver rates passenger 1-5 starts for their time together
Participating actors Driver
Pre-condition The passenger must have taken service from driver

Post condition Rate the passenger

Include None

Extend None

19
 Basic flow 1. System sends rating page for passenger
2. Passenger fill rating
3. System sends accepted message
4. End use case
Exceptional flow A2. Passenger cancel rating page
A3. End use case
Table 14 Login use Case Description

Use case name Log in

Use case ID us05
Description Users’ login for verify their identity to pay services fee or
withdrawal or admin wait to enter the system.
Participating actors Driver, Passenger and admin
Pre-condition User must be registered and have an account

Post condition User identify their identity

Include None

Extend Log out

Basic flow 1 The User wants login to system

2 The User enters in to the system
3 The system displays home page
4.The User click login link
5. The system display login form.
6 The User enters username and password
7 The system verifies username and password
8 The system displays Appropriate page
9.End use case
Exceptional flow A6 The User entered incorrect user name and password
A7 The System determines User entered incorrect username
and password
A8 The system displays failure message to prisoner
A9 The system returns to step 5
A10 End use case

2.7. User Interface Prototyping

User interface prototyping is an important step in the design process that involves creating a
preliminary version of the user interface to gather feedback, test usability, and validate design
decisions before moving forward with development. Prototyping allows designers and

20
stakeholders to visualize and interact with the proposed interface, allowing for a better
understanding of its functionality, layout, and user flow.

Fig. 5 Meheja opening page

Fig. 6 Registration form prototype

21
Fig. 7 Ride booking Prototype

Fig. 8 Payment UI prototype

22
 2.8. Activity Diagram
Activity diagram is another important behavioural diagram in UML diagram to describe dynamic
aspects of the system. Activity diagram is essentially an advanced version of flow chart that
modelling the flow from one activity to another activity.

Activity Diagrams describe how activities are coordinated to provide a service which can be at
different levels of abstraction. Typically, an event needs to be achieved by some operations,
particularly where the operation is intended to achieve a number of different things that require
coordination, or how the events in a single use case relate to one another, in particular, use cases
where activities may overlap and require coordination. It is also suitable for modelling how
a collection of use cases coordinates to represent business workflows

Ø Identify candidate use cases, through the examination of business workflows

Ø Identify pre- and post-conditions (the context) for use cases
Ø Model workflows between/within use cases
Ø Model complex workflows in operations on objects
Ø Model in detail complex activities in a high-level activity Diagram[7]

23
Fig. 9 Registration Activity diagram Fig. 10 Login Activity diagram

24
Fig. 11 Passenger Ride booking Activity diagram

25
Fig. 12 Payment Activity diagram

26
Fig. 13 Rating Activity diagram Fig. 14 Update fee Activity diagram

27
Fig. 15 Admin create account Activity Fig. 16 Approve payment Activity diagram
diagram

28
 2.9. Sequence Diagrams
A sequence diagram is the most commonly used interaction diagram. Interaction diagrams an
interaction diagram is used to show the interactive behaviour of a system. Since visualizing the
interactions in a system can be a cumbersome task, we use different types of interaction diagrams
to capture various features and aspects of interaction in a system. Sequence Diagrams A
sequence diagram simply depicts interaction between objects in a sequential order, the order in
which these interactions take place. We can also use the terms event diagrams or event scenarios
to refer to a sequence diagram. Sequence diagrams describe how and in what order the objects
in a system function[8].

Fig. 17 Login sequence diagram

29
Fig. 18 registration sequence diagram

30
Fig. 19 rate sequence Diagram

31
Fig. 20 Update fee sequence diagram

32
CHAPTER THREE
3. SYSTEM DESIGN
3.1. Layering Your Models- Class Type Architecture
Layering your models based on class type architecture is a common approach in software
development, where different layers of the application are responsible for specific tasks and have
well-defined responsibilities.

The class-type architecture

It is based on the Layer pattern the basic idea that a class within a given layer may interact with
other classes in that layer or with classes in an adjacent layer. By layering your source code in
this manner, you make it easier to maintain and to enhance because the coupling within
your application is greatly reduced[9].

Presentation / User-Interface layer

The presentation layer, also called the UI layer, handles the interactions that users have with the
software. It's the most visible layer and defines the application's overall look and presentation to
the end-users. This is the tier that's most accessible, which anyone can use from their client
device, like a desktop, laptop, mobile phone or tablet[10].

Controller layer
The Controller layer is the conductor of operations for a request. It controls the transaction scope
and manages the session related information for the request. The controller first dispatches to a
command and then calls the appropriate view processing logic to render the response.
Business layer
The business layer, also called the domain layer, is where the application's business logic
operates. Business logic is a collection of rules that tell the system how to run an application,
based on the organization's guidelines. This layer essentially determines the behaviour of the
entire application. After one action finishes, it tells the application what to do next.
Persistence layer
The persistence layer, also called the data access layer, acts as a protective layer. It contains the
code that's necessary to access the database layer. This layer also holds the set of codes that allow
you to manipulate various aspects of the database, such as connection details and SQL
statements[10].

33
Fig. 21 Class Type Architecture
3.2. Class Modelling
Class diagrams are useful in many stages of system design. In the analysis stage, a class diagram
can help you to understand the requirements of your problem domain and to identify its
components. In an object-oriented software project, the class diagrams that you create during the
early stages of the project contain classes that often translate into actual software classes and
objects when you write code[11].

34
Inheritance

Inheritance is also called generalization and is used to describe the relationship between parent
and child classes. A parent class is also called a base class, and a subclass is also called a derived
class. In the inheritance relationship, the subclass inherits all the functions of the parent class,
and the parent class has all the attributes, methods, and subclasses. Subclasses contain
additional information in addition to the same information as the parent class.

Composition relationship

Composition: The relationship between the whole and the part, but the whole and the part cannot
be separated. The combination relationship represents the relationship between the whole and
part of the class, and the overall and part have consistent lifetime. The two are inseparable and
coexist.

Aggregation Relationship

The relationship between the whole and part, and the whole and part can be separated. Aggregate
relations represent the relationship between the whole and part of the class, member objects are
part of the overall object, but the member object can exist independently from the overall
object[12].

Modelling Methods During Design:

When modelling classes during the design phase, it's important to consider the methods that will
be used to interact with the class. Methods are functions that are associated with a class, and they
define the behavior of the class.

Modeling Attributes During Design:

Attributes are the data that are associated with a class. When modeling classes during the design
phase, it's important to consider the attributes that will be associated with the class, as they define
the state of the class.

35
Fig. 22 Class Diagram

36
 3.3. User Interface Design

Fig. 23 UI flow Diagram

37
 3.4. State Chart Diagram
State chart diagram is one of the five UML diagrams used to model the dynamic nature of a system.
They define different states of an object during its lifetime and these states are changed by
events. State chart diagrams are useful to model the reactive systems. Reactive systems can be
defined as a system that responds to external or internal events[13].

Fig. 24 Login state chart Diagram Fig. 25 Registration state chart Diagram

38
Fig. 26 Payment state chart Diagram

39
Fig. 27 Rete state chart Diagram Fig. 28 update fee state chart Diagram

40
Fig. 29 payment Approval state chart Diagram

41
 3.5. ERD & Normalization of Table
3.5.1. Normalized Table
Normalization is a process of organizing data in a database. The first normal form is the first step
in the normalization process. A table is in first normal form if it contains no repeating groups.

The rule of second normal form on a database can be described as:

Ø Fulfil the requirements of first normal form

Ø Each non-key attribute must be functionally dependent on the primary key

Third normal form is the final stage of the most common normalization process. The rule for this
is:

Ø Fulfils the requirements of second normal form

Ø Has no transitive functional dependency[14]

Table 15 Account normalized

Account
First name Gender last name username password User_type

Table 16 Passenger normalized

Passenger
rate Balance Phone
number

Table 17 Driver normalized

Driver
rate Balance Phone number License
number

Table 18 Payment normalized

Payment
reason payment_id issue_date city road_type Price_per_KM

Table 19 Ride status normalized

ride_status
Initial_time end_time

42
Table 20 Rate normalized
Rate
rate comment

Table 21 Ride book

Ride Booking
star initial location destination

3.5.2. Entity Relationship Diagram

An Entity Relationship (ER) Diagram is a type of flowchart that illustrates how “entities” such as
people, objects or concepts relate to each other within a system. ER Diagrams are most often
used to design or debug relational databases in the fields of software engineering, business
information systems, education and research. Also known as ERDs or ER Models, they use a
defined set of symbols such as rectangles, diamonds, ovals and connecting lines to depict the
interconnectedness of entities, relationships and their attributes. They mirror grammatical
structure, with entities as nouns and relationships as verbs.[15]

43
Fig. 30 ERD Diagram

44
 3.6. Relational Persistent Modeling
Relational Persistent Modeling (RPM) is an approach to data Modeling and database design that
combines the principles of relational databases with the benefits of object-oriented programming
and persistence. RPM is primarily used in software development to bridge the gap between
object-oriented programming languages and relational databases.

In RPM, data is represented using classes or objects, similar to object-oriented programming.

These objects have attributes and behaviors, and they can be related to each other through
associations or relationships. The classes and their relationships are then mapped to relational
database tables and columns, allowing the data to be stored and queried using a relational
database management system (RDBMS).

Fig. 31 persistence Diagram

45
 3.7. Component Diagram
Component diagrams are used in modeling the physical aspects of object-oriented systems that are
used for visualizing, specifying, and documenting component-based systems and also for
constructing executable systems through forward and reverse engineering. Component diagrams
are essentially class diagrams that focus on a system's components that often used to model the
static implementation view of a system[16].

46
Fig. 32 Component Diagram
3.8. Deployment Diagram
Deployment diagram is a diagram that shows the configuration of run time processing nodes and
the components that live on them. Deployment diagrams is a kind of structure diagram used in
modeling the physical aspects of an object-oriented system. They are often be used to model the
static deployment view of a system (topology of the hardware)[17].

47
Fig. 33 Deployment Diagram

Reference
[1] “(PDF) Development of Online Transportation Services.”
https://www.researchgate.net/publication/334455899_Development_of_Online_Transport
ation_Services (accessed Jul. 04, 2023).
[2] “What is the Waterfall Model? - Definition and Guide.”
https://www.techtarget.com/searchsoftwarequality/definition/waterfall-model (accessed
Jul. 07, 2023).

48
[3] “(PDF) WATERFALL MODEL | Gourab Dutta - Academia.edu.”
https://www.academia.edu/38314403/WATERFALL_MODEL (accessed Jul. 07, 2023).
[4] “Essential Use Cases.” http://www.mcs.vuw.ac.nz/research/object/Papers/euc-
html/node4.html (accessed Jul. 07, 2023).
[5] “What Is a Use Case & How To Write One | Wrike.” https://www.wrike.com/blog/what-
is-a-use-case/#What-is-a-use-case-Use-cases-explained (accessed Jul. 07, 2023).
[6] M. Felici, “Use Cases,” 2004.
[7] “What is Activity Diagram?” https://www.visual-paradigm.com/guide/uml-unified-
modeling-language/what-is-activity-diagram/ (accessed Jul. 07, 2023).
[8] “Unified Modeling Language (UML) | Sequence Diagrams - GeeksforGeeks.”
https://www.geeksforgeeks.org/unified-modeling-language-uml-sequence-diagrams/
(accessed Jul. 07, 2023).
[9] “The Design of a Robust Persistence Layer For Relational Databases Building Object
Applications That Work Process Patterns Design of a Persistence Layer Series,” 1997,
Accessed: Jul. 07, 2023. [Online]. Available:
http://www.ambysoft.com/persistenceLayer.pdf
[10] “What Are the 5 Primary Layers in Software Architecture? | Indeed.com.”
https://www.indeed.com/career-advice/career-development/what-are-the-layers-in-
software-architecture (accessed Jul. 07, 2023).
[11] “Class diagrams - IBM Documentation.” https://www.ibm.com/docs/en/rsm/7.5.0?
topic=structure-class-diagrams (accessed Jul. 07, 2023).
[12] “What are the six types of relationships in UML class diagrams? - Visual Paradigm Blog.”
https://blog.visual-paradigm.com/what-are-the-six-types-of-relationships-in-uml-class-
diagrams/ (accessed Jul. 07, 2023).
[13] “UML - Statechart Diagrams.”
https://www.tutorialspoint.com/uml/uml_statechart_diagram.htm (accessed Jul. 07, 2023).
[14] “A Step-By-Step Guide to Normalization in DBMS With Examples.”
https://www.databasestar.com/database-normalization/ (accessed Jul. 07, 2023).
[15] “ER Diagram (ERD) - Definition & Overview | Lucidchart.”
https://www.lucidchart.com/pages/er-diagrams (accessed Jul. 07, 2023).
[16] “What is Component Diagram?” https://www.visual-paradigm.com/guide/uml-unified-
modeling-language/what-is-component-diagram/ (accessed Jul. 07, 2023).
[17] “What is Deployment Diagram?” https://www.visual-paradigm.com/guide/uml-unified-
modeling-language/what-is-deployment-diagram/ (accessed Jul. 07, 2023).

49
50