AMITY UNIVERSITY

DEPARTMENT OF ONLINE DISTANCE EDUCATION

PETRODA MANAGEMENT SYSTEM (PMS)

This dissertation is submitted in partial fulfilment for the requirements for the award of the bachelor’s degree in
computer applications at Amity University

SUBMITTED BY: Wilson Chirambo

 November,2023

CONTACT INFORMATION

AUTHOR DETAILS:

NAME : Wilson Chirambo

CELLPHONE : +265 456 7780

EMAIL : wilson.chirambo@yahoo.com

SIGNATURE________ ___________23/10/2023______DATE
__________________________________

PROJECT SUPERVISOR:
NAME: ______________________________________________________________________

SIGNATURE________________________ DATE____________________________________

HEAD OF DEPARTMENT

NAME _______________________________________________________________________

SIGNATURE: ____________________________DATE: ______________________________

Declaration

I Wilson Chirambo hereby declare that this dissertation represents my own work which has been done
after registration for the bachelor’s degree of Computer Applications at Amity University and has not
been previously submitted to this or any other institution for a degree or other qualifications. Where
work that form part of other research papers or any source, proper citation was included. I accept
responsibility for the conduct of the procedures that might be found to be contrary to the provided
guidelines.
Signature__________________________________________________

Date _____________________________________________________

Certificate of Approval

I hereby declare that this dissertation according to my knowledge is the students own work and effort and
it has been acknowledged where other sources of information were used. This dissertation has been
submitted with my approval as a supervisor.
Name of the Supervisor **. ****** *******
Signature of the Supervisor_______________________________________

Date of Approval ** November 2023

Dedication

I would like to dedicate this dissertation to my beloved wife Constance, my son watipa, mother and my
sister and my brothers and friends for the support render in conducting this study.

Acknowledgements

First and foremost, I thank the Almighty God for giving me good health and energy to conduct this study. I
sincerely thank my employer for providing me with the flexibility to combine work and school
requirements. I am also grateful for my supervisor for the tremendous support and guidance provided to
perfect this dissertation and lastly all those that assisted in providing me with the necessary information
for this study.

GLOSSARY
Abbreviations Description
API Application Programming Interface
HTML Hyper Mark Up Language
ICT Information and communication Technology
JS JavaScript
MySQL My Structured Query Language
PMS Petroda management system
DB Database
PMS Petroda management system
GUI Graphical user interface

Abstract

The abundant use of Mobile Applications has made them a part and parcel of our lives, be it for personal use,
corporate based task, or entertainment. “Petroda Android Application for corporate and Home Services”, is a
Corporate based mobile application for android users that brings together the client and service providers and
connects them using the house numbers and locations(maps). Clients requested for the home services and based
on the location by fetching the latitude and longitude of the client, the nearest service provider is allotted to serve
the client’s needs. this application has a wide scope for integrating maps to allow drag and drop to another
location and make this application available for other mobile operating systems other than android.

Table of contents
TABLE OF FIGURE…………………………………………………………………………………………………………………………………………
DECLARATION………………………………………………………………………………………………………………………………………………………..
ACKNOWLEDGEMENTS ...................................................................................................................................................
DEDICATION ....................................................................................................................................................................
GROSSARY……………………………………………………………………………………………………………………………………………………………
TABLE OF CONTENTS……………………………………………………………………………………………………………………………………………….
ABSTRACT……………………………………………………………………………………………………………………………………………………………
CHAPTER ONE…………………………………………………………………………………………………………………………………………………
1.0INTRODUCTION…………………………………………………………………………………………………………………………………………….
1.1Background of study………………………………………………………………………………………………………………………………………
1.2Problem Statement………………………………………………………………………………………………………………………………………..
1.3 OBJECTIVES……………………………………………………………………………………………………………………………………………………
1.3.1 Importance of Computerized system in Petroda Management Systems…………………………………………………….
1.3.2 INTRODUCTION TO PETRODA MANAGEMENT SYSTEM………………………………………………………………………………
1.4 JUSTIFICATION……………………………………………………………………………………………………………………………………………..
1.5 SCOPE……………………………………………………………………………………………………………………………………………………………
1.5.1 USER FRIENDLY ENVIRONMENT………………………………………………………………………………………………………………….
1.5.2 MINIMAL TIME CONSUMPTION………………………………………………………………………………………………………………….
1.5.3 MAINTAINING THE DATABASE………………………………………………………………………………………………………………. ….
1.6 System Setup…………………………………………………………………………………………………………………………………………………
1.6.1 Application Implementation……………………………………………………………………………………………………………………….
CHAPTER TWO…………………………………………………………………………………………………………………………………………………….
2.LITERATURE REVIEW………………………………………………………………………………………………………………………………………….
2.1 OVERALL DESCRIPTIONS………………………………………………………………………………………………………………………………….
2.2 PRODUCT PERSPECTIVE……………………………………………………………………………………………………………………………………
2.2.1 USER INTERFACES………………………………………………………………………………………………………………………………………….
2.2.2 SOFTWARE INTERFACE……………………………………………………………………………………………………………………………..……
2.2.3 COMMUNICATIONS INTERFACES…………………………………………………………………………………………………………….…….
2.2.4 MEMORY CONSTRAINTS ………………………………………………………………………………………………………………………..……..
2.3 PRODUCTION FUNCTIONS………………………………………………………………………………………………………………………………..
2.3.1 MAINTAIN DATABASE…………………………………………………………………………………………………………………………………….
2.3.2 PROVIDER REGISTRATION FORMS………………………………………………………………………………………………….………………
2.3.3 TENANTS REPORT GENERATION………………………………………………………………………………………………….…………………
2.3.4 SECURITY MANAGEMENT……………………………………………………………………………………………………………..……………….
2.4 USER CHARACTERISTICS…………………………………………………………………………………………………………………..……………….
2.4.1 MANAGER………………………………………………………………………………………………………………………………………….………….
2.4.2 SERVICE PROVIDER……………………………………………………………………………………………………………………………..…………
2.5 OVERVIEW………………………………………………………………………………………………………………………………………………………..
2.1 CONSTRAINTS…………………………………………………………………………………………………………………………………………………
2.2 ASSUMPTIONS AND DEPENDENCIES ……………………………………………………………………………………………………………..
CHAPTER THREE………………………………………………………………………………………………………………………………………………….
3.1 FEASIBILITY STUDY…………………………………………………………………………………………………………………………………………..
3.1.1 Economic Feasibility…………………………………………………………………………………………………………………………………..
3.1.2 Operational feasibility………………………………………………………………………………………………………………………………..
CHAPTER FOUR…………………………………………………………………………………………………………………………………………………..
4. SPECIFIC REQUIREMENTS……………………………………………………………………………………………………………………………….
4.1 FUNCTIONAL REQUIREMENTS (FR)……………………………………………………………………………………………………………….
4.1.1 FR FOR THE MANAGER …………………………………………………………………………………………………………………
4.1.2 FR FOR THE PROVIDER ………………………………………………………………………………………………………………….
4.1.3 FR FOR THE SYSTEM ADMINISTRATOR…………………………………………………………………………………………….
4.2.1 MAINTAINABILITY ………………………………………………………………………………………………………………………….
4.2.2 USABILITY……………………………………………………………………………………………………………………………………..
4.2.3 SECURITY ……………………………………………………………………………………………………………………………………..
4.2.4 RELIABILITY …………………………………………………………………………………………………………………………………..
TABLE OF FIGURE .......................................................................................................................................................... ix
CHAPTER ONE ................................................................................................................................................................1
1 INTRODUCTION.......................................................................................................................................................... ix
1.1 PETRODA ............................................................................................................... Error! Bookmark not defined.
1.2 OBJECTIVES ......................................................................................................................................................... xi
1.3.1 INTRODUCTION TO PETRODA ..................................................................................................................... xii
1.3.2 CURRENT SYSTEM ....................................................................................................................................... xii
1.3.3 PROBLEMS WITH THE EXISTING SYSTEM ....................................................... Error! Bookmark not defined.
1.4 PROBLEM STATEMENT ......................................................................................... Error! Bookmark not defined.
1.5 JUSTIFICATION ................................................................................................................................................... xii
1.6 Scope ................................................................................................................................................................ xiii
1.6.1 USER FRIENDLY ENVIRONMENT ................................................................................................................ xiii
1.6.2 MINIMAL TIME CONSUMPTION ................................................................................................................ xiii
1.6.3 MAINTAINING THE DATABASE ................................................................................................................... xiii
 1.7 OVERVIEW ...........................................................................................................................................................6
CHAPTER TWO ...............................................................................................................................................................3
2. OVERALL DESCRIPTIONS ............................................................................................................................................4
2.1 PRODUCT PERSPECTIVE .......................................................................................................................................4
2.1.1 USER INTERFACES .........................................................................................................................................4
2.1.2 SOFTWARE INTERFACE .................................................................................................................................4
2.1.3 COMMUNICATIONS INTERFACES ..................................................................................................................4
2.1.4 MEMORY CONSTRAINTS ...............................................................................................................................5
2.2 PRODUCTION FUNCTIONS ...................................................................................................................................5
2.2.1 MAINTAIN DATABASE ...................................................................................................................................5
2.2.2 TENANTS REGISTRATION FORMS .................................................................................................................5
2.2.3 REPORT GENERATION ..................................................................................................................................5
2.2.4 SECURITY MANAGEMENT .............................................................................................................................5
2.3 USER CHARACTERISTICS.......................................................................................................................................5
2.3.1 SYSTEM ADMINISTRATOR .............................................................................................................................5
2.3.2 TENANT .........................................................................................................................................................5
2.3.3 PROVIDER .....................................................................................................................................................5
2.4 CONSTRAINTS ......................................................................................................................................................6
CHAPTER THREE .............................................................................................................................................................6
3.0 LITERATURE REVIEW ................................................................................................. Error! Bookmark not defined.
3.1 FEASIBILITY STUDY ...............................................................................................................................................6
3.1.1 Economic Feasibility: ....................................................................................................................................6
3.1.2 Operational feasibility: .................................................................................................................................6
CHAPTER FOUR ..............................................................................................................................................................7
4. SPECIFIC REQUIREMENTS ..........................................................................................................................................7
4.1 FUNCTIONAL REQUIREMENTS (FR) ......................................................................................................................7
4.1.1 FR FOR THE SYSTEM ADMINISTRATOR .........................................................................................................7
4.1.2 FR FOR THE TENANT .....................................................................................................................................8
4.1.3 FR FOR THE PROVIDER ..................................................................................................................................8
4.2 NON FUNCTIONAL REQUIREMENTS ..................................................................................................................9
4.2.1 MAINTAINABILITY .........................................................................................................................................9
4.2.2 USABILITY ..........................................................................................................................................9
4.2.3 SECURITY .......................................................................................................................................................9
4.2.4 RELIABILITY .................................................................................................................................................10
CHAPTER FIVE ..............................................................................................................................................................10
5.0 ENTITY RELATIONSHIP DIAGRAMS (ER) .................................................................................................................10
5.1 What are Entity Relationship Diagrams? ...........................................................................................................10
5.1.1 ENTITY RELATIONSHIP DIAGRAM FOR PETRODA SYSTEM ..........................................................................12
 5.2 DATA FLOW DIAGRAMS (DFD) ...........................................................................................................................12
5.2.1 What are Data Flow Diagrams? ..................................................................................................................12
5.3 O level DFD / context diagram ...........................................................................................................................15
5.4 USE CASE DIAGRAMS .........................................................................................................................................15
5.4.1What is a UML Use Case Diagram? ..............................................................................................................15
5.4.2 Basic Use Case Diagram Symbols and Notations ........................................................................................15
5.5 EXTENDED USE CASE DIAGRAM FOR PETRODA .................................................................................................17
5.5.1 SCHEDULE APPOINTMENT ..............................................................................................................................18
5.5.4 PROVIDER & SUGGESTION ............................................................................. Error! Bookmark not defined.
5.5.5 VIEW RECORD ............................................................................................................................................19
5.5.6 FILE REPORTS ..............................................................................................................................................19
5.5.7 MANAGE USER ............................................................................................................................................19
5.6 ACTIVITY DIAGRAMS ..........................................................................................................................................20
5.6.1 What is a UML Activity Diagram? ...............................................................................................................20
5.6.2 Basic Activity Diagram Symbols and Notations ..........................................................................................20
5.7 STATECHART DIAGRAMS ...................................................................................................................................27
5.7.1 What is a UML State Chart Diagram? .........................................................................................................28
5.7.2 Basic State Chart Diagram Symbols and Notations ....................................................................................28
5.8 SEQUENCE DIAGRAM.........................................................................................................................................30
5.8.1 What is a UML Sequence Diagram? ............................................................................................................30
5.8.2 Basic Sequence Diagram Symbols and Notations .......................................................................................30
5.8.3 Add provider ...............................................................................................................................................34
5.8.4Accept provide ................................................................................................ Error! Bookmark not defined.
5.8.5 Provider availability ....................................................................................... Error! Bookmark not defined.
5.8.6 File reports ..................................................................................................... Error! Bookmark not defined.
5.8.7 Give suggestion .............................................................................................. Error! Bookmark not defined.
5.9 COLLABORATION DIAGRAMS.............................................................................................................................34
5.9.1 What is a UML Collaboration Diagram? ......................................................................................................34
5.9.2 Basic Collaboration Diagram Symbols and Notations .................................................................................34
CHAPTER SIX ................................................................................................................................................................39
6.0 Application Implementation ..................................................................................... Error! Bookmark not defined.
6.1 System Setup ........................................................................................................ Error! Bookmark not defined.
6.1.1 SYSTEM WELCOME WINDOW........................................................................ Error! Bookmark not defined.
6.1.2 SYSTEM LOG IN WINDOW ............................................................................. Error! Bookmark not defined.
6.1.3 SYSTEM DASHBOARD ..................................................................................................................................39
6.1.4 Managing Tenants. .....................................................................................................................................40
6.1.5 Managing Service Providers........................................................................................................................40
6.2 Challenges ..........................................................................................................................................................43
CHAPTER SEVEN ...........................................................................................................................................................43
7.0 Conclusion and Recommendations .......................................................................................................................43
7.1 Conclusion .........................................................................................................................................................43
7.2 Recommendations .............................................................................................................................................43
REFERENCES.................................................................................................................................................................43

TABLE OF FIGURE
Figure 1:Use case diagram for Tenant ..........................................................................................................................7
Figure 2:Use Case Diagram for Provider.......................................................................................................................8
Figure 3:Use Case Diagram for System Administrator .................................................................................................8
Figure 6:showing Relationship ERDs ..........................................................................................................................10
Figure 7: Diagram showing for petroda management System ..................................................................................12
Figure 8: Data flow diagram .......................................................................................................................................13
Figure 9:process of data flow ......................................................................................................................................13
Figure 10:Gane and Sarson process Notation ............................................................................................................13
Figure 11:Gane & Sarson Datastore Notations ..........................................................................................................14
Figure 12: data Flow through......................................................................................................................................14
Figure 13:objects outside the system .........................................................................................................................15
Figure 14: level 1 DFD .................................................................................................................................................15
Figure 15: Basic case diagram symbol .........................................................................................................................16
Figure 16:Case diagram for Petroda management ....................................................................................................17
Figure 17: Relationships & action ...............................................................................................................................21
Figure 18:creation & modification object ..................................................................................................................21
Figure 19: Represent decision .....................................................................................................................................22
Figure 20: Synchronization process .............................................................................................................................22
Figure 21: group related activities ...............................................................................................................................23
Figure 22: Activity diagram for Tenant .......................................................................................................................26
Figure 23:System welcome window .............................................................................. Error! Bookmark not defined.
Figure 24:Setting up of the database ............................................................................ Error! Bookmark not defined.
Figure 25: System log in page ......................................................................................... Error! Bookmark not defined.
Figure 26: Application Log In window ............................................................................ Error! Bookmark not defined.
Figure 27: Admin portal ...............................................................................................................................................39
Figure 28: Staff management tab. ..............................................................................................................................40
Figure 29: Registering Tenants ..................................................................................................................................40
Figure 30: Managing Tenants .....................................................................................................................................41

CHAPTER ONE

I. Introduction
1.1Background of the study

Malawi has a vast number of tertiary educations, producing many graduates. These graduates need help in getting
employed. The Malawian government has employment services centers in every district that assist aspirant
workers to obtain employment, today these employment centers are full of people every day. Each one will need
employment. This makes it very difficult for the person at the service center to make it very transparent. There is a
need for a way that gives employment when an opportunity comes to the right person, Chikwawa labour office is
one of the districts with this employment service center. Chikwawa labour offices cater for people of all
capabilities, disabled, general hands, technical college graduates, University graduates, etc. The system at the
center is done manually where the labour office assistant writes details of candidates in books and file them on
local bookshelves these have many irregulates i.e. file getting missing and getting damaged end result it would be
difficult to retrieve old information, generating statistics and reports will be so cumbersome and prone to many
errors. I intend to develop an Android application system that will do the entire recruitment process where
different organizations of individuals can request a service and be approved by the management of the
application.

1.2 PROBLEM STATEMENT

Since all the information is maintained in the registers, searching for a piece of data from those registers is a time
consuming and hectic task.
All entries are made manually which is of course a lengthy process. This again results in people standing and
waiting for their turns. The main problem with the system is that the same data is being entered in the system
again and again at different places by different people. This might result in the inconsistency of data because the
data is being entered redundantly at many places, and inconsistency of the system can cause serious problems.
The Services are to be properly documented and a proper DB would ensure that the usage of each of the provider
is according to the Tenant who have requested or what the tenant has ordered.
Data updating is a major hurdle in such an environment where there are many people that are to be serviced and
to take care that no record is tempered.
Security provision is a serious issue relating to such a huge organization to make it work efficiently. Records related
to each provider need to be kept safe.
Extracting useful information from the current system is a very difficult task.
A close analysis makes it very certain that the existing system is time consuming. There are greater chances of
inconsistency of data and the frustration of the Tenants. So it can be said that the existing system is not very
reliable and needs to be changed to give the Tenants and the manager and the service provider the higher degree
of satisfaction.
Keeping in view all the problems mentioned above, we hereby propose a new mobile application (petroda) hiring
system, to meet all the requirements of Tenants as well as the providers.

1.3 OBJECTIVES
The objective of this computerized product is to develop an android application system and automate the
PETRODA MANAGEMENT SYSTEM [PMS]. PMS automation refers to use of smartphones and tablets, associated
peripheral media such as Optical media etc. and utilization of API based products and services in the performance
of all type of home services functions and operations. smartphones can introduce a great deal of automation in
operations, functions since they are electronic, programmable and are capable of control over the process being
performed.
The Software Requirement Specification document describes requirements and functionality of the system. This
document follows the IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 830-1998).
The intended addressees for this SRS are project examiners and supervisor.
Requirement Analysis is the first technical step in the software process. A general statement of software scope is
refined into a concrete pattern that becomes the basis for all software engineering activities that follows.
1.3.1 Importance of Computerized system in Petroda Management Systems
The system has been felt to be computerization to make it more relevant and a real life project with minimal
errors. It is therefore important to computerize it because there are many limitations in the manual system, which
is more time consuming with many loopholes and the chance of errors, are apparent. Therefore, a mobile app
system having an organized database cut redundancy and eases data access.

The diligent character of mobile app system makes the system perfect, as it doesn’t suffer from human traits of
tiredness and lack concentration. Thus by computerization this project software provides considerable help to the
user by providing number checks to user so that he may get required feedback about the database. Mobile
application development of this system would be time saving and the efficient handling of the database would
prove to be an indispensable gift to the user in long run.
1.3.2 INTRODUCTION TO PETRODA MANAGEMENT SYSTEM
This document describes the requirement specification for the mobile application development software Petroda
for hiring services. PMS will mainly compose of six Features.
• Manager
• Tenants
• Service
• Provider
• Houses
• Bookings
PETRODA for the trust will be a high-performance database system designed purposely for keeping records of
Tenants, Manager/Admin, services, provider results for each Tenants and Bookings.
Manager section responsible of adding services, providers (e.g., Plumber, Electrician, RAN Engineer). The admin is
also responsible of creating services (a service can be something like House cleaning, plumbing), after creating the
service the admin/manager then assigns the provider to that service (e.g., House cleaning service can be assigned
to a provider cleaner). The Tenants must first register and login to access the app, once logged in the tenants sees
a list of services and choose the one that he/she wants (e.g. selecting a house cleaning service), after select the
service, the list of providers is then presented (providers are people you can actually do the work/service), the
tenants then chooses the provider from the list and book for that particular service and the exact date where the
service/work to be done, after a successful booking, a notification is sent to the provider notifying them that there
is a booking. Providers has the right to accept or reject the request depending on their schedule. if the request is
accepted, the tenant sees that the request has been accept. When the work is done and the tenant is satisfied, the
tenant has to mark the service done just to indicate that the provider has provided the work and its fully done, so
then tenant then proceeds to make a payment.
the manager/admin on the other side sees each and every update of services and he/she is also able to see reports
on the money made for that month, total number of tenants and providers, how many services has been
provides.the manager is also responsible for assign tenants to houses and remove also.
.

.
1.4 JUSTIFICATION
In Petroda mobile app System, presently all provider and staff management operations are being done manually.
Various Books and Registers are maintained for entries about provider and staff enquiry, registration, and fees
submission. Final report preparation is very cumbersome and time consuming, as even for a single Record, several
books have to be referred, in all immediate updating, validation, and reporting is just too large.
This result in unnecessary delay in various operation of organization and could be detrimental to the progress.

1.5 Scope
The PETRODA system is a web application running in all operating systems including mobile devices. The users of
the application are the manager, tenants, service provider and the system administrator. Petroda wants to
automate the whole system and get rid of the manual procedures.

The product will provide following functions

▪ Booking Registration Forms

• Report Generation

• Security Management
The targeted project takes in following aspects:

1.5.1 USER FRIENDLY ENVIRONMENT

User-friendly graphical interfaces are provided so that the user of the system can interact with the system and
enter data into the database. The interfaces get input from the user and save it to the database.
1.5.2 MINIMAL TIME CONSUMPTION
As dealing with a large number of providers, petroda has great need to make its system less time consuming.
Presently, they are maintaining almost all of their records in local registers, which are to be replaced by new ones
due to shortage of space and hectic maintenance procedures.

1.5.3 MAINTAINING THE DATABASE

The daily entries are recorded in the database. These are then accessed according to the requirements.

1.6 System Setup

The application needs a MySQL database to store its data. So, before we start running an application for the first
time, we need to configure our database for the application. To achieve this, the application has been designed in
such a way that the database is configured automatically in any computer running JVM node.js php and MySQL
server
 1.6.1 Application Implementation
Thus by studying the flaws in the existing system and proposing a new solution, a real time Android Application has
been built using the technologies mentioned and named it as “Petroda Android Application for corporate and
Home Services”. Following are the important screen shots of the developed application on Android Platform

Welcome window login/register page

admin/manager add provider page

Mananger welcome window
i
progress page Task progress page

Request approval page approved task by provider

1
 new user register page
Tenants/clients page

Client/Tenant remove page

System database

2
 CHAPTER TWO
2.LITERATURE REVIEW

There is a needs for an online mobile application software system whereby it can accommodate the
Tenants(clients) comfortably and avoid any confusion with the service provider(plumber, engineer) regarding their
work. There should be a system where the home services are categorized under different qualifications and the
system helps the management to claim the bills from tenants(clients) and companies.

The mobile app software system should be useful to record Service provider details along with the field of
specialization. It also should record the Tenants details and arrange the appointment of service providers. Should
also provide the management reports like schedules, appointments of service provider. And generate bills
dynamically for the dispatched service provider etc.

The administrative user should create new users and change their passwords. He should be able to add the
service provider information as well as new service provider details. Also, can add information related to service
provider availability and billing information. The administrator/manager can view the management reports.
The service provider can change their own passwords. He can view his own appointments, approve, and decline
requests and information of tenants for any day.

Manager is another person who manages the activities of the system. He can add a new service provider to the list.
He can also add new provider information. He can view the information of Tenants, and provider.

An accountant or manager can add the information related to Tenants and view all the reports. He can view the
details of in provider, out provider and dispatched provider information. He also collects the bill amount from the
tenants and enters it into the system.

convergence of information technology and communication technology has created an environment where we can
access information, get services online from anywhere anytime even at the state of mobility. Such access to
information and online services is possible just by the use of our fingertips through mobile applications. These
mobile applications can be grouped as personal, perishable, transaction oriented, location specific, corporate and
entertainment. Petroda Android Application for Home Services” is a mobile application built for Android users,
which is catered to the requirements of a client who wants to provide domestic home services online by bringing
together the users and service providers. The registered users who is a tenant can demand a service available
through the application and based on the users’ location, the nearest service provider is allotted to cater the

3
Tenant request for service. Locating the Tenant and the service provider is done by using home address and house
number that gives the exact location. The applications’ simple and straight forward interface; instant service;
feature for rating and sending feedback, makes it incredibly useful and relatively easy to use for all Tenants.

2.1 OVERALL DESCRIPTIONS

The section describes the common factors that affect the product and its requirements. It comprises of the
following sub sections.

• Product Perspective

• Product Functions

• User Characteristics

• Constraints

• Assumptions and Dependencies

2.2 PRODUCT PERSPECTIVE

The project is to provide the Chikwawa labour office, under the supervision of Petroda’s, with a system with the
help of which it can get rid of the manual procedures.
Petroda is a high performance database system designed specifically for keeping records for provider, manger,
results for each Tenants.
2.2.1 USER INTERFACES
User Interfaces are provided so that the user of the system can interact with the system and enter data into the
database. The interfaces that are provided are to get input from the user and save it to the database. These
interfaces will help in report generation

2.2.2 SOFTWARE INTERFACE

Following software interfaces will be required for the system.

• Web server

• Mysql Database

• PHP Server

• Browser Software (Internet Explorer 6.0 or above)

2.2.3 COMMUNICATIONS INTERFACES
Petroda will require an internal protocol for communication. As the protocols are automatically mounted on the
web server operating system, there is no need to install them separately.

The protocols needed are:

HTTP

4
 TCP/IP
2.2.4 MEMORY CONSTRAINTS

➢ PRIMARY MEMORY

Since the application will be hosted on a web server, any computer with any amount of RAM will be able to run
the application.
➢ SECONDARY MEMORY

Since the application will be hosted on a web server, any computer with any amount of HD Space will be able to
run the application.

2.3 PRODUCTION FUNCTIONS

2.3.1 MAINTAIN DATABASE
The daily entries are recorded in the database. These are then accessed according to the requirements.
2.3.2 PROVIDER REGISTRATION FORMS
To enter provider to the database there are Service Provider Registration Forms. The receptionist enters the data
through these entry forms.
2.3.3 TENANTS REPORT GENERATION
This is the important functionality of the system. It includes generating reports on every tenant’s result.

2.3.4 SECURITY MANAGEMENT

For the security of the data there is a login system. Four logins are created. 1) service provider. 2) Tenants. 3)
Administrator. 4) Manager. The tenant list is only allowed to register and search for a provider using entry
forms. The Provider is allowed to access and update , has the right to accept or reject the request depending on
their schedule checkup data. The Administrator has full rights to the whole system.
2.4 USER CHARACTERISTICS
The users of the system and their characteristics are as follows:

2.4.1 MANAGER
The Manager will access and update every providers checkup data,bookings, reports.
2.4.2 SERVICE PROVIDER
Providers has the right to accept or reject the request depending on their schedule.
visit schedule
Appointment Scheduling
Enquiry of Tenants
Find History of tenants Enquired
2.4.3 SYSTEM ADMINISTRATOR
System administrator will inspect the overall performance of the system. He will have the rights to grant
permissions.

5
2.5 OVERVIEW
Rest of the document is structured as follows:

• Overall description of the project including product perspective, functions, user characteristics, constraints,
assumptions and dependencies.

• Specific requirements (functional and nonfunctional) for the development of software.

2.1 CONSTRAINTS
• The user must be affiliated with petroda company. No user can login to the system without
authentication.

• Every user must know how to use a smartphone or personal computer.

• A monthly report of all processes must be generated and sent to the Manager of company.
2.2 ASSUMPTIONS AND DEPENDENCIES
• The daily reports of the processes will be generated by applying queries on the database.

• The user must know how to interact with the system.

• Database administrator will be responsible for manipulating with the database. He will manage the fields of
the database and make entries in the tables.

CHAPTER THREE

3.1 FEASIBILITY STUDY

The applications of technology to the Petroda Management allow providers’ to supply new and flexible services
that are cost-competitive with conventional mass, standardized and rigidly packaged options. Technology gives
Institute the flexibility to react to tenants demands.
3.1.1 Economic Feasibility:
The aim for our Software is to provide properties of all sizes with an affordable, effective, user-friendly petroda
Management System. The petroda application system is designed to control costs and resources, therefore
improving long-term profitability and efficiency.

Our software is an affordable Management System software package that caters to small to medium-sized
properties. It effectively manages service provider and staff Records, Registration Process and Staff records. A
reliable answer to tracking availability and property statistics.

3.1.2 Operational feasibility:

Project is not rejected simply because of operational unfeasibility but such consideration is likely to critically affect
the nature and scope of the eventual recommendations. As we know the users have very little knowledge of
computer, a user-friendly environment will be required. The system should be GUI based. This goal can be met by

6
 using a web app and mysql as the back end. A little consideration and training may enable the user to handle this
package.

For Petroda Management System apart from other facts as per operational feasibility is concerned we need to see
to it that the system to be developed should be user-friendly so that staff personnel’s who are not computer
literate find it easy to work with. As the office staff does most of the work, so they might have to be trained.

CHAPTER FOUR

4. SPECIFIC REQUIREMENTS
The use case diagrams and the non-functional requirements of system are as follows.

4.1 FUNCTIONAL REQUIREMENTS (FR)

The stake holders (actors) of system and their use case modeling are as follows.
Manager
Service provider
Database Administrator
Tenants
4.1.1 FR FOR THE MANAGER

Manager

view reports
add & remove services

add & remove

providers
Figure 1:Use case diagram for Manager

1. ADD AND REMOVE SERVICES

The manager will be responsible for adding and removing services.

2. ADD AND REMOVE PROVIDERS

This activity will let the manger to update the providers checkup information in the provider record by
adding or removing.

3. VIEW REPORTS

7
 In this activity, the manager will see the reports about the provider,tenats s and makes analysis from the
report.
4.1.2 FR FOR THE PROVIDER

view services
and bookings login
accept or reject
requesting

Figure 2:Use Case Diagram for Provider

1. ACCEPT OR REJECT REQUESTING

Providers has the right to accept or reject the request depending on their schedule.

2. VIEW SERVICES AND BOOKINGS

He will have the updated information about all the Tenats schedule visiting and bookings from the tenats.

3. LOGIN
The provider will handle the various enquiries about the Tenants s registration.

4.1.3 FR FOR THE SYSTEM ADMINISTRATOR

Administrator

Inspect Performance
add & remove services

Figure 3:Use Case Diagram for System Administrator

8
 1. INSPECT PERFORMANCE

The system administrator will be responsible for the overall inspection of the system.
2. ADD AND REMOVE SERVICES
The System Administrator has the rights to grant permissions to the respective users of the system.

4.2 NON FUNCTIONAL REQUIREMENTS

The non-functional attributes of the project are illustrated under various sections below:
4.2.1 MAINTAINABILITY
The system is developed in such a manner that its functionality can be enhanced to support further development
in the system.
4.2.2 USABILITY
The system is designed to accept only registered user. Only for users are defined. 1) manager. 2) Provider (by
name). 3) Administrator. 4) Tenants. 5) . The manager is the admin of the system. once logged in he/she is
responsible of adding service providers (e.g., Plumber, Electrician). the admin is also responsible of creating
services (a service can be something like House cleaning), after creating the service the admin then assigns the
provider to that service (e.g., House cleaning service can be assigned to a provider cleaner). The Tenants must first
register and login to access the app, once logged in the tenants sees a list of services and choose the one that
he/she wants (e.g. selecting a house cleaning service), after select the service, the list of providers is then
presented (providers are people you can actually do the work/service), the tenants then chooses the provider
from the list and book for that particular service and the exact date where the service/work to be done, after a
successful booking, a notification is sent to the provider notifying them that there is a booking. Providers has the
right to accept or reject the request depending on their schedule. if the request is accepted, the tenant sees that
the request has been accept. When the work is done and the tenant is satisfied, the tenant has to mark the service
done just to indicated that the provider has provided the work and its fully done, so then tenant then proceeds to
make a payment.

the manager/admin on the other side sees each and every update of services and he/she is also able to see reports
on the money made for that month, total number of tenants and providers, how many services has been provides.

the manager is also responsible for assign tenants to houses and remove also.
4.2.3 SECURITY
Security is provided in the system in a way that the different users will not be able to access everything in the
system. The database will not be within everyone s reach.

9
4.2.4 RELIABILITY
The system shall be reliable. If the server crashes, the data will not be lost because a backup will be maintained.

CHAPTER FIVE

5.0 ENTITY RELATIONSHIP DIAGRAMS (ER)

5.1 What are Entity Relationship Diagrams?

Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases.

Figure 4:showing Relationship ERDs

Entity Relationship Diagram Notations

Entity

An entity is an object or concept about which you want to store information.

Weak Entity
A weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be
uniquely identified by its own attributes alone.

Key attribute

A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security
number might be the employee's key attribute.

10
Multivalued attribute

A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill
values.

Derived attribute

A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the
employee's annual salary.

Relationships

Relationships illustrate how two entities share information in the database structure.

Cardinality

Cardinality specifies how many instances of an entity relate to one instance of another entity.

Ordiality is also closely linked to cardinality. While cardinality specifies the occurrences of a relationship, ordinarily
describes the relationship as either mandatory or optional. In other words, cardinality specifies the maximum
number of relationships and ordinarily specifies the absolute minimum number of relationships.

Recursive relationship

In some cases, entities can be self-linked. For example, employees can supervise other employees.

11
5.1.1 ENTITY RELATIONSHIP DIAGRAM FOR PETRODA MANAGEMENT SYSTEM

Figure 5: Diagram showing for Petroda management System

5.2 DATA FLOW DIAGRAMS (DFD)

5.2.1 What are Data Flow Diagrams?

Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.

12
Figure 6: Data flow diagram

Process
A process transforms incoming data flow into outgoing data flow.

Figure 7:process of data flow

Yourdon and Coad Process Notations

Figure 8:Gane and Sarson process Notation

Datastore Notations

Datastores are repositories of data in the system. They are sometimes also referred to as files.

13
Yourdon and Coad Datastore Notations

Figure 9:Gane & Sarson Datastore Notations

5.2.2 Dataflow Notations

Dataflow

Dataflows are pipelines through which packets of information flow. Label the arrows with the name
of the data that moves through it.

Figure 10: data Flow through

5.2.3 External Entity Notations

External Entity

External entities are objects outside the system, with which the system communicates. External
entities are sources and destinations of the system's inputs and outputs.

14
Figure 11:objects outside the system

5.3 O level DFD / context diagram

Manager details Tenants details

PETRODA MANAGEMENT
SYSSTEM
PMS details
Provider details

Figure 12: level 1 DFD

5.4 USE CASE DIAGRAMS

5.4.1What is a UML Use Case Diagram?

Use case diagrams model the functionality of a system using actors and use cases. Use cases are services or
functions provided by the system to its users.

5.4.2 Basic Use Case Diagram Symbols and Notations

System

Draw your system's boundaries using a rectangle that contains use cases. Place actors outside the system's
boundaries.

15
 Figure 13: Basic case diagram symbol

Use Case

Draw use cases using ovals. Label with ovals with verbs that represent the system's functions.

Actors

Actors are the users of a system. When one system is the actor of another system, label the actor
system with the actor stereotype.

Relationships
Illustrate relationships between an actor and a use case with a simple line. For relationships among use cases, use
arrows labeled either "uses" or "extends." A "uses" relationship indicates that one use case is needed by another
in order to perform a task. An "extends" relationship indicates alternative options under a certain use case.

16
5.5 EXTENDED USE CASE DIAGRAM FOR PETRODA MANAGEMENT

provider
add & remove
services

Tenants
Manage user

Admin review and rate

providers

view services
Manager and bookings

Figure 14:Case diagram for Petroda management

17
5.5.1 SCHEDULE APPOINTMENT

view schedule

(from included use cases)

<<extend>>

Schedule Appointment
(from PMS)

Provider

(from PMS)

(from extended use cases)

5.5.3 DISPATCH PROVIDER

<<extend>>

Generate bill Execute job.

(from included use cases ) (from extended use cases )

<<include >>

( )
Dispatch provider
( )

Service provider
Close task (from Pms)
(from HMS )

(from classes)

18
5.5.5 VIEW PROVIDER RECORD
view operation report
(from lasses )
view designation

view daily report

manage
r (From Pms ) ( )
(from PMS )

view provider record

(from PMS )

Admin ( )
( )

view report
)

5.5.6 FILE REPORTS

File operation reports

( )

File reports
File daily reports
(from PMS )
(from tenats )

Provide
r
(From PMS )

5.5.7 MANAGE USER

19
 create user
(from classes )

suspend user
(from classes )

Manage User
(from HMS )

Admin delete user

(from HMS ) (from classes )

update user

(from classes)

5.6 ACTIVITY DIAGRAMS

5.6.1 What is a UML Activity Diagram?

An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to
activity. An activity represents an operation on some class in the system that results in a change in the state of the
system. Typically, activity diagrams are used to model workflow or business processes and internal operation.
Because an activity diagram is a special kind of state chart diagram, it uses some of the same modeling
conventions.

5.6.2 Basic Activity Diagram Symbols and Notations

Action states
Action states represent the no interruptible actions of objects.

Action Flow
Action flow arrows illustrate the relationships among action states.

20
Figure 15: Relationships & action

Object Flow
Object flow refers to the creation and modification of objects by activities. An object flow arrow from an action to
an object means that the action creates or influences the object. An object flow arrow from an object to an action
indicates that the action state uses the object.

Figure 16:creation & modification object

Initial State

A filled circle followed by an arrow represents the initial action state.

Final State

An arrow pointing to a filled circle nested inside another circle represents the final action state.

Branching

21
A diamond represents a decision with alternate paths. The outgoing alternates should be labeled
with a condition or guard expression. You can also label one of the paths "else."

Figure 17: Represent decision

Synchronization

A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and
joining.

Figure 18: Synchronization process

Swim lanes
Swim lanes group related activities into one column.

22
Figure 19: group related activities

Activity diagram for Administrator:

23
 L o g in

v ie w / a d d
provid er s d e t a ils
v e
v ie w / a d d
tenant d e t a i ls
s
v ie w / a d d
a p p o in tm e n t s
d e t a ils

v ie w / a d d
Houses s
d e t a ils

v ie w / a d d
Manager r
d e t a il s

v ie w / a d d
Payment
s d e t a il s
v ie w
r e p o rts

Activity diagram for Provider:

24
 Lo gin

V ie w
d c r d et ails

V ie w
pa tie nt s de ta ils

V iew /a dd
app oint men t
det a ils

V ie w
d isc ha rge
det a ils

V ie w
r ep orts

V ie w
r ep orts

Activity diagram for nurse:

25
 L o g in

V i e w /a d d
d o c to r s d e t a i l s

V ie w
p a ti e n t s d e ta i l s

V ie w
a p p o in t m e n t
d e t a il s

V i e w /a d d
ro o m
d e t a il s

V ie w
d i s c h a rg e

V ie w
in s u ra n ce

V ie w
r e p o rt s

Figure 20: Activity diagram for nursing

26
Activity diagram for Accountant:

Lo gin

V ie w
pa tie nts de ta ils

V ie w
d isc ha rge

V iew / ad d
in su ran ce

V ie w
r ep orts

5.7 STATECHART DIAGRAMS

27
5.7.1 What is a UML State Chart Diagram?
A state chart diagram shows the behavior of classes in response to external stimuli. This diagram models the
dynamic flow of control from state to state within a system.

5.7.2 Basic State Chart Diagram Symbols and Notations

States
States represent situations during the life of an object. You can easily illustrate a state in Smart Draw by using a
rectangle with rounded corners.

Transition
A solid arrow represents the path between different states of an object. Label the transition with the
event that triggered it and the action that results from it.

Initial State
A filled circle followed by an arrow represents the object's initial state. Learn how
to rotate objects.

Final State

An arrow pointing to a filled circle nested inside another circle represents the object's final state.

Synchronization and Splitting of Control

A short heavy bar with two transitions entering it represents a synchronization of control. A short
heavy bar with two transitions leaving it represents a splitting of control that creates multiple states.

28
TENANT:

PROVIDER:

Takes Details of Tenant

Checks availability of Tenant

gives appointment

gives bill

takes bill amount

MANAGER:

29
 Check for available Task

Assign provider.

Dispatch provider

Check payment datails

5.8 SEQUENCE DIAGRAM

5.8.1 What is a UML Sequence Diagram?

Sequence diagrams describe interactions among classes in terms of an exchange of messages over
time.

5.8.2 Basic Sequence Diagram Symbols and Notations

Class roles
Class roles describe the way an object will behave in context. Use the UML object symbol to illustrate
class roles, but don't list object attributes.

Activation

Activation boxes represent the time an object needs to complete a task.

30
Messages
Messages are arrows that represent communication between objects. Use half-arrowed lines to
represent asynchronous messages. Asynchronous messages are sent from an object that will not
wait for a response from the receiver before continuing its tasks.

Various message types for Sequence and Collaboration diagrams

Lifelines
Lifelines are vertical dashed lines that indicate the object's presence over time.

31
Destroying Objects

Objects can be terminated early using an arrow labeled "<< destroy >>" that points to an X.

Loops
A repetition or loop within a sequence diagram is depicted as a rectangle. Place the condition for
exiting the loop at the bottom left corner in square brackets [

32
 : schedule : appointment
: Tenants

view schedule

Provider schedule

enter appointment

conformation of appointment

33
5.8.3 APPROVE TASK

: Provider : Tenant : indoorAdmit : outdoorAdmit

: Provider

Check available task

register ( )

details
(House details )

details

Approve Task

conform admit
Tenant id

5.9 COLLABORATION DIAGRAMS

5.9.1 What is a UML Collaboration Diagram?

A collaboration diagram describes interactions among objects in terms of sequenced messages.
Collaboration diagrams represent a combination of information taken from class, sequence, and use
case diagrams describing both the static structure and dynamic behavior of a system.

5.9.2 Basic Collaboration Diagram Symbols and Notations

Class roles

Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but
don't list object attributes.

Association roles
Association roles describe how an association will behave given a particular situation. You can draw
association roles using simple lines labeled with stereotypes.

34
Messages

Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time and
instead number messages in order of execution. Sequence numbering can become nested using the
Dewey decimal system. For example, nested messages under the first message are labeled 1.1, 1.2,
1.3, and so on. The a condition for a message is usually placed in square brackets immediately
following the sequence number. Use a * after the sequence number to indicate a loop.

CLASS DIAGRAM
What is a UML Class Diagram?

Class diagrams are the backbone of almost every object-oriented method including UML. They
describe the static structure of a system.

Basic Class Diagram Symbols and Notations

Classes represent an abstraction of entities with common characteristics. Associations represent the
relationships between classes.

Illustrate classes with rectangles divided into compartments. Place the name of the class in the first
partition (centered, bolded, and capitalized), list the attributes in the second partition, and write
operations into the third.

Active Class

35
Active classes initiate and control the flow of activity, while passive classes store data and serve
other classes. Illustrate active classes with a thicker border.

Visibility
Use visibility markers to signify who can access the information contained within a class. Private
visibility hides information from anything outside the class partition. Public visibility allows all other
classes to view the marked information. Protected visibility allows child classes to access information
they inherited from a parent class. Learn how to edit text.

Associations
Associations represent static relationships between classes. Place association names above, on, or
below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles
near the end of an association. Roles represent the way the two classes see each other.
Note: It's uncommon to name both the association and the class roles.

Multiplicity (Cardinality)

Place multiplicity notations near the ends of an association. These symbols indicate the number of
instances of one class linked to one instance of the other class. For example, one company will have
one or more employees, but each employee works for one company only.

36
Constraint

Place constraints inside curly braces {}.

Simple Constraint
Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A, the
whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow diamond to
represent a simple aggregation relationship, in which the "whole" class plays a more important role
than the "part" class, but the two classes are not dependent on each other. The diamond end in both
a composition and aggregation relationship points toward the "whole" class or the aggregate.

37
Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship
between two classes where one class is a specialized version of another. For example, VIZTS is a type
of car. So the class VIZTS would have a generalization relationship with the class car.

In real life coding examples, the difference between inheritance and aggregation can be confusing. If
you have an aggregation relationship, the aggregate (the whole) can access only the PUBLIC
functions of the part class. On the other hand, inheritance allows the inheriting class to access both
the PUBLIC and PROTECTED functions of the superclass.

38
 CHAPTER SIX
SYSTEM DASHBOARD
After successful login, the admin portal will look like the caption bellow. The administrator/manger has all
privileges in the system. The admin/manger will add Providers, houses, manage bookings and handle reports.

Figure 21: Admin portal

39
6.1.4 Managing Service.
To add Service, click service management tab on the bottom sidebar.

Figure 22: Service management tab.

The list of all the services that have been added is shown on the table window, the admin/manager can update
data for the services or delete it. The plus symbol on the top left conner is for adding service data and the close bin
symbol is for deleting data. the service will be given login in permissions by the admin/manager.
6.1.5 Managing Providers
New provider records can be added by clicking on provider tab on the right bottom sidebar. the system has
categorized providers based on skill and qualification. the provider window has Data entry section for the
manager.

Figure 23: Registering providers

40
 The patient list section has two tabs namely, All service, and provider information.
All service tab displays all the types of services being offered in the system in the form of a table. The Tenant can
search or filter data in the table.

6.1.6 Managing Houses

To Manage houses, Click houses tab. the list of all houses will be displayed. Click the plus symbol on the action
column of the table to add data .

Figure 24: Managing IPD patients

41
you can enter data for the house like, house number, address, city and country

6.1.8 Tenanst

Login as tenant and the following window will show up

42
Figure 25: This dealing with Tenants

6.2 Challenges
There are many challenges I have faced when developing this API system . some of the challenges include Internet
connectivity to download some JQuery libraries, and lack of programming experience.
CHAPTER SEVEN
7.0 Conclusion and Recommendations
7.1 Conclusion
Domestic Android Application for corporate and Home Services” is a customized Mobile Application which uses the
state-of-the-art technologies like Android SDK (Software Development Kit), Eclipse, Java and MySQL used for
Android Application Development. This application provides domestic home services where users can be served
for electrical services, plumbing services, and carpentry services. Unlike the existing “Facility Kart” application, this
application uses house numbers to fetch the users’ location and assigns nearest service provider from his existing
location dynamically. Thus, this application seems to be more dynamic, effective, and efficient than the existing
system.
Recommendations

This application can be further enhanced by allowing the users of the application to drag and drop to another
location on the maps. This facility can be used by the user in case if the user wants the service request to be
accomplished at another location than his current location. For this there is a need to integrate the maps into this
application. Another useful enhancement can be made by providing more service types to the user. Lastly, since
this application is built only for Android users, this application can also be implemented for other platform like iOS
and Windows.

REFERENCES

[1] Outsource 2 India (O2I), Software Services , “Bangalore, India,

URL: Android | MongoDB

URL: http:// Java Tutorial (w3schools.com)

[3] Simon Bennett, Steve McRobb and Ray Farmer, Object Oriented Systems Analysis and Design using UML ,
2/E, Mc Graw Hill, pp.134 144 (2001)

43