DeRent Final Thesis

DeRent
Session (2017-2021)
BSSE
Submitted By:
Akram khan 5513
Abdulwadood 5512
Supervisod By:
Mr. sibtulhassan
Department of Computer Science

Abbottabad University of Science & Technology
ACKNOWLEDGMENT
Al-Hamd-u-Lillah! We are very grateful to our Almighty Allah, the most gracious and
merciful, who blessed us with strength and mental powers without which we could not
complete this project and made us able to meet and complete this complex task. The full
credit of this software project goes to Almighty Allah because we are unable to do
anything without His help.
We are thankful to Dr. Muhammad Naeem (Chairman of department) for providing lots
of courage whose support and guidance played an important role in our achievements. His
guidance and advice, both mentally and technically have been of great importance to the
outcome of this final thesis. We sincerely appreciate his time and efforts which he has
been providing from the start of a project.
We are also thankful to all teachers and staff members here at the Computer science
department. We are extremely thankful to my beloved parents and family whose prayers
and continuous encouragement made the successful completion of this project possible.
We extend my deepest gratitude to all the responsible teachers and staff members of CS
to give us a lot of knowledge and every kind of assistance in the four years of stay in the
Institute.
i
DEDICATION
This project could not have been possible without the support of our family. Our whole
success is dedicated to our parents.
ii
PREFACE
It’s a great opportunity for us to have a Bachelor of Science in Computer Science in
Abbottabad University of Science and Technology. In the accomplishment of this degree,
we are doing a project report on “DeRent”.Whole project report has been divided into 5
chapters.
 Introduction
 Existing System
 Proposed System
 Design
 Testing
 Conclusion
iii
Table of Contents
CHAPTER 1 ....................................................................................................................... 1
INTRODUCTION.............................................................................................................. 1
1.1 Purpose ............................................................................................................................. 2
1.2 Scope ................................................................................................................................ 2
1.3 Objective ............................................................................................................................ 2
1.4 Use Cases and Usage Scenarios: ...................................................................................... 3
1.4.1 Use Case Diagram ..................................................................................................................... 3
1.4.2 Extended Use Case Diagram ..................................................................................................... 4
1.4.3 Usage scenarios ......................................................................................................................... 5
1.5 Tools Used ...................................................................................................................... 11
1.5.1 Frontend: .................................................................................................................................. 11
1.5.2 Backend:................................................................................................................................... 11
1.5.3 Documentation: ........................................................................................................................ 11
CHAPTER 2 ..................................................................................................................... 12
THEORETICAL BACKGROUND ............................................................................... 12
2.1 Limitation of Existing System ........................................................................................ 13
2.2.1 Inconsistency ........................................................................................................................... 13
2.2.2 Limited .................................................................................................................................... 13
2.2.3 Communication ....................................................................................................................... 13
2.2.4 Limited showroom ................................................................................................................... 13
2.2.5 Time consuption ...................................................................................................................... 13
CHAPTER 3 ..................................................................................................................... 14
PROPOSED SYSTEM .................................................................................................... 14
3.1 Modules .......................................................................................................................... 15
3.1.1 Authentication ......................................................................................................................... 15
3.1.1.a Borrower: ............................................................................................................................ 15
iv
3.1.1.b Vendor:................................................................................................................................ 15
3.1.2 Borrower: ................................................................................................................................. 16
3.1.3 Vendor ..................................................................................................................................... 16
3.1.4 Product ..................................................................................................................................... 16
3.1.5 Rating ...................................................................................................................................... 17
3.2 Functional Requirements ................................................................................................ 17
3.3 Non-Functional Requirements........................................................................................ 17
3.3.1 Usability .................................................................................................................................. 17
3.3.2 Performance Requirements ...................................................................................................... 17
3.3.3 Availability .............................................................................................................................. 18
3.3.4 System Requirements: ............................................................................................................. 18
3.3.4.a Hardware Requirements: .................................................................................................... 18
3.4.4.b Software Requirements: ...................................................................................................... 18
3.4 Feasibility Study ............................................................................................................. 18
3.4.1 Economic Feasibility ............................................................................................................... 19
3.4.2 Operational Feasibility ............................................................................................................ 19
3.4.3 Technical Feasibility ............................................................................................................... 19
3.5 Chosen Methodology...................................................................................................... 20
3.5.1 Incremental Development Model .............................................................................................. 20
3.6 Reason for Chosen Methodology ................................................................................... 21
3.7 Work Plan ....................................................................................................................... 21
3.7.1 Project Plan in Visio .................................................................................................................. 21
3.8 Project Structure ............................................................................................................. 21
3.8.1 Team Structure ........................................................................................................................ 21
3.8.2 Members .................................................................................................................................. 22
CHAPTER 4 ..................................................................................................................... 23
SYSTEM DESIGN ........................................................................................................... 23
4.1 Purpose ........................................................................................................................... 24
v
4.2 Scope .............................................................................................................................. 24
4.3 Definition, Acronyms, and Abbreviations ...................................................................... 25
4.3.1 Definitions ............................................................................................................................... 25
4.3.2 Abbreviations........................................................................................................................... 25
4.4 Sequence Diagram .......................................................................................................... 25
4.4.1 Sequence Diagrams for registration ......................................................................................... 26
4.4.2 Sequence Diagrams (Vendor) .................................................................................................. 27
4.4.3 Sequence Diagram (Borrower) ................................................................................................ 28
4.5 Activity Diagram ............................................................................................................ 29
4.6 Data Flow Diagram ........................................................................................................ 30
4.6.1 Context Level 0: ...................................................................................................................... 30
4.6.2 Level 1 DFD ........................................................................................................................... 31
4.7 Deployment Diagram ..................................................................................................... 32
4.8 Graphical User Interfaces ............................................................................................... 33
4.8.1 Home page ............................................................................................................................... 33
4.8.2 Admin login ............................................................................................................................. 34
4.8.3 Sign Up as a Vendor ................................................................................................................ 35
4.8.4 Signup for Borrower ................................................................................................................ 36
4.8.5 Borrower Profile ...................................................................................................................... 37
4.8.6 Chat.......................................................................................................................................... 38
4.8.7 Product Table ........................................................................................................................... 39
CHAPTER 5 ..................................................................................................................... 40
SYSTEM TESTING ........................................................................................................ 40
5.1 Purpose of Testing .......................................................................................................... 41
5.2 Objectives of Testing ...................................................................................................... 41
5.3 Testing Techniques ......................................................................................................... 42
5.3.1 Black Box Testing ................................................................................................................... 42
5.3.1 a Interface Name: A-Login ..................................................................................................... 42
vi
5.3.1 b Interface Name: A-Login ..................................................................................................... 43
5.3.1 c Interface Name: A-Login ..................................................................................................... 43
5.3.1 d Interface Name: Borrower/ Vendor _changepassword ....................................................... 44
5.3.1 e Interface Name: Product table ............................................................................................ 44
5.3.1 f Interface Name: Add product .............................................................................................. 44
5.3.1 g Interface Name: Vendor/Borrower_ Addcontact ................................................................ 45
5.3.2 White Box Testing ................................................................................................................... 46
5.3.2 a Login Code .......................................................................................................................... 46
5.3.1 b White Box Test Cases .......................................................................................................... 47
5.3.1 c Results ................................................................................................................................. 49
5.4 Unit Test ......................................................................................................................... 49
5.5 Integration Testing.......................................................................................................... 49
5.6 System Testing ............................................................................................................... 51
CHAPTER 6 ..................................................................................................................... 52
CONCLUSION ................................................................................................................ 52
CONCLUSION .......................................................................................................................... 53
REFERENCES .......................................................................................................................... 54
vii
LIST OF FIGURES
Figure 1 Use Case Diagram ................................................................................................. 3
Figure 2 User Use Case Diagram.......................................................................................4
Figure 3 Vendor Use Case Diagram...................................................................................4
Figure 4 Adinistrator Use Case Diagram............................................................................4
Figure 5 Incremental Model............................................................................................... 20
Figure 6 Work Plan ............................................................................................................ 21
Figure 7 Sequence Diagram for Registration..................................................................... 26
Figure 8 Sequence Diagram for Vendor ............................................................................ 27
Figure 9 Sequence Diagram for Borrower ......................................................................... 28
Figure 10 Activity Diagram ............................................................................................... 29
Figure 11 DFD Level 0 ...................................................................................................... 30
Figure 12 Level 1 DFD ...................................................................................................... 31
Figure 13 Deployment Diagram ........................................................................................ 32
Figure 14 GUI for Home page ........................................................................................... 33
Figure 15 GUI for Admin login ......................................................................................... 34
Figure 16 GUI for Signup(Vendor) ................................................................................... 35
Figure 17 GUI for Signup(Borrower) ................................................................................ 36
Figure 18 GUI for Borrower Profile .................................................................................. 37
Figure 19 GUI for chat screen ........................................................................................... 38
Figure 20 GUI for Product table ........................................................................................ 39
viii
LIST OF TABLES
Table 1 Login Usage Scenario0 ........................................................................................... 5
Table 2 View Product Usage Scenarios ............................................................................... 6
Table 3 Add Product Usage Scenarios................................................................................ 7
Table 4 Change Password Usage Scenarios ........................................................................ 8
Table 5 Logout Usage Scenarios ......................................................................................... 9
Table 6 Chat Usage Scenarios ........................................................................................... 10
Table 7 Team Structure ...................................................................................................... 22
Table 8 Defination ............................................................................................................. 25
Table 9 Abbrevation .......................................................................................................... 25
Table 10 User Login .......................................................................................................... 42
Table 11 Vendor Password Length .................................................................................... 43
Table 12 Borrower Password Length ................................................................................ 43
Table 13 Change Password ................................................................................................ 44
Table 14 Product Table ...................................................................................................... 44
Table 15 Add Product ........................................................................................................ 45
Table 16 Add Contact ........................................................................................................ 46
Table 17 White Box Test Case .......................................................................................... 48
Table 18 Test Case Result.................................................................................................. 50
Table 19 Integration Testing .............................................................................................. 50
ix
CHAPTER 1
INTRODUCTION
1
The purpose of this project is to provide a platform for users and rental product(s) owners
in an effective and efficient manner. Online Renting System is a one stop rental portal. It
provides services such as electronic devices (DSLR cameras, stand mic, loud speakers,
play stations, drones cameras, computer systems, electric generator etc ) books, sports,
fasion&beauty, furniture and home décor and other Products. It provides the facility to
make online orders and get everything done before you reach the destination.
1.1 Purpose
The DeRent (Online rental system) which is web application is intended to provide
complete solutions for product owner as well as customers through a single get way using
the internet. It will enable product owner to setup online rental business, and the customer
to browse and rent them online without having to visit the showroom.
1.2 Scope
 Provides an earning platform for product owner.
 Provides privacy.
 Free from taxes.
 Time Efficient.
 The system is a web application.
 The system will work in pakistan only.
 The system will provide the chat feature.
 Mobile friendly(responsive)
 User registration (sign up) is must to avail the product.
 The user would be able to feedback(customer reviews).
1.3 Objective
The main objective of the project is to provide platform for the product owners(vendor)
and borrowers.
To design a user friendly system that enable a person to get a product on rent.
To design a system that enables a person to rent his/her product.
2
1.4 Use Cases and Usage Scenarios:
1.4.1 Use Case Diagram
Figure 1 Use Case Diagram
3
1.4.2 Extended Use Case Diagram
Figure 2 User Use Case Diagram
Figure 3 Vendor Use Case Diagram
Figure 4 Administrator Use Case Diagram

4
1.4.3 Usage Scenarios
Table 1 Use Case description of Login Usage Scenarios
Use Case Title Login

Abbreviated Vendor & Borrower
Title
Use Case Id Use Case 01
Requirement Id Registration ID
Description: Vendor & Borrower attempts to login to the system to perform required
operations.
Pre-Conditions: Vendor & Borrower must have an account.
Task Sequence Exceptions
1. User Request for login Form. 1- An exception occurs when Form not
found.
2. System will ask the user to enter his user ID 2- The system generates an implicit
and password exception, and gives message to user to
provide his correct name and password.
3. If the User ID and password is correct the 3. If User Record not found system
system will allow the user to access the provides exception.
required Forms/modules.
Post Conditions:
1. Vendor & Borrower successfully logged in to the system.
Unresolved issues: None
5
Table 2 Use Case description of View product Usage Scenarios
Use Case Title View Products

Abbreviated Title View Products
Requirement Id Borrower
Description: Borrower View the Products.
Pre-Conditions: Borrower must be login into their account.

1. Click on Products link. 1- Invalid filter
2. Products saved are shown. 2- Record Not Found.
Post Conditions:
1. Borrower can request for Services.
6
Table 3 Use Case description of Add Product Usage Scenarios
Use Case Title Add Product
Abbreviated Add Products
Title
Requirement Id Vendor
Description: Vendor enter the product detail.
Pre-Conditions: Vendor must be logged on to system.

1. Click on Add Product 1- Exception occurs if user enter
invalid data.
2. Enter Product Detail. 2- Exception occur if user did not
provides all values.
3. Click on save button.
Post Conditions:
1. Products are visible by the customers.
7
Table 4 Use Case description of Change Password Usage Scenarios
Use Case Title Change Password
Abbreviated Title Change Password
Requirement Id Vendor and Borrower
Description: Vendor and Borrower can change their user account password.
Pre-Conditions: Vendor and Borrower must be logged in into the system.

1. Click on Change Password Link 1- Exception message will be provided if
form not loaded correctly.
2. Enter Old and New Password. 1- Exception occur if Incorrect Information
is Provided
3. Click on Update Button
Post Conditions:
Vendor and Borrower must use new password for login.
8
Table 5 Use Case description of Logout Usage Scenarios
Use Case Title Logout

Abbreviated Logout from system
Title
Requirement Id Vendor and Borrower
Description: Vendor and Borrower of system attempt to logout from system.
Pre-Conditions: Registered user must have logged in to system.

1. User select logout link
Post Conditions:
User successfully logout from application
9
Table 6 Use Case description of Chat Usage Scenarios
Use Case Id 6
Use Case Title Chat

Scope Rent product
Level Borrower Goal
Primary Actor Borrower
Stakeholder and Interest:

Borrower:
Borrower can chat with Vendor to get any product on rent.
Pre-Condition:
Application need email and password
Application needs Wi-Fi to store information.
Exceptions:
Invalid name, user name, Mobile Number, skills category, email and password.
Success Guarantee (Post Conditions):

Successfully signup to the application.
Access his/her account
Main Success (Basic Flow):

Borrower open the application
Borrower sign in application.
If Borrower enter valid email and password so he/she come to homepage.
From page Borrower can choose chat button to start a chat with Vendor.
10
1.5 Tools Used
Front End:
• HTML
• CSS
• JavaScript
• jQuery
• Bootstrap
• React JS
Back End:
• Node JS
• Express JS
• SQL
DBMS
• MySQL
Graphics
• Photoshop CS6
Project Documentation
MS Word 2015
11
CHAPTER 2
THEORETICAL BACKGROUND
12
If anybody want to rent a product from a particular city from their own home, how it is
possible? If one person is going to another city, but if he want products for rent before he
reach is destination, then how it possible? So answer to these questions is our web site.
There are many rental systems which are available online. But, they are not providing all
products at one place. Also many of them restricted to only one city. That means car
rental system in online deals only with cars. Also many of them are not providing
effective communication between customer and the vendor. Also present rental systems
restricted to only one vendor means products are supplied only from one rental show
room.
2.1 Limitation of Existing System

Following are the limitation of the existing system:
2.2.1 Inconsistency
In existing system there is an Inconsistency in record management. There is no proper
relationship in between the data and information.
2.2.2 Limited
They limited to only one product and limited cities.There are many existing systems for
renting purpose but these systems are limited to single product like a renting car system
and also some rental system are limited in specific area.
2.2.3 Communication
.No effective communication between user and the vendor.In existing systems there is no
specific feature for chat.
2.2.4 Limited show room

Products limited to only one rental show room.If a person need any product he/she
2.2.5 Time Consumption

Existing system require more time because there is manual record keeping system used by
the user.
13
CHAPTER 3
PROPOSED SYSTEM
14
The proposed system is a web based system which can be accessed by customer from
anywhere around the world. The system can offer number of products from vendor in
different locations. A vendor directly registers into this system using this system user
interface without any manual approach. The proposed system can accept any type of
product for rental, this system interface support to the vendors to upload their product
image into the system. A customer directly interacts with this product image and gets
necessary information regarding the rental products. The proposed system accepts an
online request from the customers to reserve any rental system product for his own
purpose. Administration play vital role here. Administrator can able to communicate the
reservation information of any product to that particular vendor using this system.
3.1 Modules
3.1.1 Authentication
Different users registered first of all and registered through authentication and get access
to this application.
3.1.1.a Borrower:
 Borrower has to register first, in order to register.Borrower has to provide

attributesName, Username, Mobile number, Email, Password, confirm
password.
 If Borrower already has/have an account, He/she can login by his email and
password.
 After successful login, Borrower dashboard/homepage is open.
3.1.1.b Vendor
 Vendor has to register first, in order to register.Vendor has to provide

attributesName, Username, Mobile number, Email, Password, confirm
password.
 If vendor already has/have an account, He/she can login by his email and
password.
 After successful login, Vendor dashboard/homepage is open.
15
3.1.2 Borrower:
 Borrower are customers.

 Basic information about Borrower.
 There will be a separate profile for customers.
 They can update basic information.
 They can check product.
 They can check Notification.
 Read Term & Condition.
 They can Post requirement.
 Read Privacy Policy.
3.1.3 Vendor
 Profile of Vendor can be viewed by any customer.

 Vendor can view all the updates about uploaded product.
 They will have their profile on which all of there products can be viewed.
 Basic information about Vendor.
 There will be a separate profile for vendor.
 They can update basic information.
 They can check Notification.
 Read Term & Condition.
 They can Post requirement.
 Read Privacy Policy.
.
3.1.4 Product
 Product are posted by Vendors.
 Every products may have different rent price.
 These are uploaded by vendors and borrowers can hire any product.
16
3.1.5 Rating
 Rating are given by Borrowers.

 Products of vendors at DeRent be rated by borrowers.
 This will help them out to reach more customers.
 Users can ask any question related to product or in case of any confusion.
3.2 Functional Requirements

 Borrowers and Vendors sign up.
 If they have account, they can simply login with their email, password.
 Borrowers and Vendors view their profile.
 Borrowers can view different products.
 Borrowers and Vendors update there profile if needed.
3.3 Non-Functional Requirements

In systems engineering and requirements engineering, a non-functional requirement
(NFR) is a requirement that specifies criteria that can be used to judge the operation of a
system, rather than specific behaviors.
3.3.1 Usability
Usability is the degree to which the software is easy to use as indicated by the following
substitutes. Usability minimizes the efforts required to learn, operate, prepare, input and
interpret output of a program. It is the combination of fitness for the purpose, ease of use
and ease of learning that makes a product effective. It focuses on determining if the
product is easy to learn, satisfying to use and contains functionality that the users desire.
.
3.3.2 Performance Requirements

Performance is one of the main major issues for our system. The system should have a
high performance such that the Borrowers and Vendors be able to search for a specific
Deal.
17
3.3.3 Availability
System will be available as long as the phone is connected to the internet and our system
also provide 24/7 availability.
3.3.4 System Requirements:
3.3.4.a Hardware Requirements:
 System: Intel(R) Core i3 (2.40 GHz).
3.4.4.b Software Requirements:
 Operating system: 64-bit operating system, x64-based processor

 IDE: Visual studio Code
3.4 Feasibility Study

Feasibility is defined as the practical extent to which a project can be performed
successfully. To evaluate feasibility, a feasibility study is performed, which determines
whether the solution considered to accomplish the requirements is practical and workable
in the software. Information such as resource availability, cost estimation for software
development, benefits of the software to the organization after it is developed and cost to
be incurred on its maintenance are considered during the feasibility study. The objective
of the feasibility study is to establish the reasons for developing the software that is
acceptable to users, adaptable to change and conformable to established standards.
Various other objectives of feasibility study are listed below.
 To analyze whether the software will meet organizational requirements.
 To determine whether the software can be implemented using the current
technology and within the specified budget and schedule.
 To determine whether the software can be integrated with other existing software.
3.4.1 Economic Feasibility

Economic feasibility determines whether the required software is capable of generating
financial gains for an organization. It involves the cost incurred on the software
development team, estimated cost of hardware and software, cost of performing
feasibility study, and so on. For this, it is essential to consider expenses made on
purchases (such as hardware purchase) and activities required to carry out software
18
development. In addition, it is necessary to consider the benefits that can be achieved by
developing the software. Software is said to be economically feasible if it focuses on the
issues listed below.
 Cost incurred on software development to produce long-term gains for an
organization.
 Cost required to conduct full software investigation (such as requirements
elicitation and requirements analysis).
 Cost of hardware, software, development team, and training.
3.4.2 Operational Feasibility

Operational feasibility assesses the extent to which the required software performs a
series of steps to solve business problems and user requirements. This feasibility is
dependent on human resources (software development team) and involves visualizing
whether the software will operate after it is developed and be operative once it is
installed. Operational feasibility also performs the following tasks.
 Determines whether the problems anticipated in user requirements are of high
priority.
 Determines whether the solution suggested by the software development team is
acceptable.
 Analyzes whether users will adapt to a new software.
 Determines whether the organization is satisfied by the alternative solutions
proposed by the software development team.
3.4.3 Technical Feasibility

Technical feasibility assesses the current resources (such as hardware and software) and
technology, which are required to accomplish user requirements in the software within the
allocated time and budget. For this, the software development team ascertains whether the
current resources and technology can be upgraded or added in the software to accomplish
specified user requirements. Technical feasibility also performs the following tasks.
 Analyzes the technical skills and capabilities of the software development team
members.
 Determines whether the relevant technology is stable and established.
19
 Ascertains that the technology chosen for software development has a large
number of users so that they can be consulted when problems arise or
improvements are required.
3.5 Chosen Methodology
3.5.1 Incremental Model

Incremental Model is a process of software development where requirements are broken
down into multiple standalone modules of software development cycle. Incremental
development is done in steps from analysis design, implementation, testing/verification,
maintenance. Each iteration passes through the requirements, design, coding and testing
phases. And each subsequent release of the system adds function to the previous release
until all designed functionality has been implemented. The system is put into production
when the first increment is delivered. The first increment is often a core product where
the basic requirements are addressed, and supplementary features are added in the next
increments. Once the core product is analyzed by the client, there is plan development for
the next increment.
Figure 5 Incremental Model
3.6 Reason for Chosen Methodology

 System development is broken down into many mini development projects
 Partial systems are successively built to produce a final total system
 Highest priority requirement is tackled first
20
 Once the requirement is developed, requirement for that increment are
frozen.
3.7 Work Plan

Database design is the process of producing a detailed data model of database. This data
model contains all the needed logical and physical design choices and physical storage
parameters needed to generate a design in a data definition language, which can then be
used to create a database. A fully attributed data model contains detailed attributes for
each entity.
3.7.1 Project Plan in Visio

Week Week Week Week Week Week Week Week Week Week
1 2 3 4 5 6 7 8 9 10
Study of the System
Literature Review
Designing User Interface
Breakdown of Coding
Documentation
Figure 6 Work Plan
3.8 Project Structure
3.8.1 Team Structure

Working as a team reduces time and cost efforts on the project. We Akram khan and
Abdul wadood together to develop this web and complete this document. The team
structure we adopted is the Democratic team structure. It suffers from less manpower
turnover. Democratic team structure suits to less understood problems since a group of
developers can invent a better solution than a single individual. It encourages ego less
programming as we can share and review one another's work. We work by sharing ideas,
problems and their solutions we divided tasks and completed them.
21
3.8.2 Members
Table 7 Team Structure
Akram khan Development And Testing
Abdul wadood Development,Designing And Doucementation
22
CHAPTER 4
SYSTEM DESIGN
23
Software design usually involves problem solving and planning a software solution. This
includes both a low-level component and algorithm design and a high-level, architecture
design. This document includes the design of the system to be developed from different
aspects such as the flow of data in DFD’s (Data Flow Diagrams) and sequence and
actions of system activities in Sequence Diagrams. This document also includes an
Architecture Diagram of technology that will be used for development of this system.
One of the major advantages of this phase is design documentation that keeps everything
on track during the project journey. This phase is very important for the development of
this system because in this phase the technical details of the design and various
parameters such as risks, technologies to be used, the capability of the project team and
project constraints reviewed and then the best design approach are selected for the
product.
4.1 Purpose
The purpose of this Design phase is to provide a description of the design of a system
fully enough to allow for software development to proceed with an understanding of what
is to be built and how it is expected to build. This phase is necessary to provide a
description of the details for the software and system to be built.
4.2 Scope
This Design phase is for a base level system which will work as a proof of concept for the
use of building a system the provides a base level of functionality to show feasibility and
benefits of this system for people. This Software Design is focused on the base level
system and critical parts of the system. For this particular Software Design phase, the
focus is placed on to help people in emergency situations.
24
4.3 Definition, Acronyms, and Abbreviations
4.3.1 Definitions
Table 8 Defination
Word. Definition.
Application An application framework is a software library that provides a
Framework fundamental structure to support the development of applications for
a specific environment.
Object A Java object is a combination of data and procedures working on

the available data. An object has a state and behaviour. The state of
an object is stored in fields (variables), while methods (functions)
display the object's behaviour.
4.3.2 Abbreviations
Table 9 Abbrevation
Word Abbreviation
DFD Data Flow Diagram
UI User Interface
4.4 Sequence Diagram

Sequence Diagrams are interaction diagrams that detail how operations are carried out.
They capture the interaction between objects in the context of a collaboration. They're
also called event diagrams. A sequence diagram is a good way to visualize and validate
various runtime scenarios. These can help to predict how a system will behave and to
discover responsibilities a class may need to have in the process of modeling a new
system.
25
4.4.1 Sequence Diagrams For Registration
This sequence diagram show that how a vendor/user registration take place.
Figure 7 Sequence Diagram for Registration
26
4.4.2 Sequence Diagram For Login
This sequence diagram shows that how vendor/user login process take place.
Figure 8 Sequence Diagram for Login
27
4.4.3 Sequence Diagram For Vendor To Add Product
This sequence diagram shows how a vendor will add product.
Figure 9 Sequence Diagram for Add Product
28
4.5 Activity Diagram
4.5.1 Activity Diagram
Figure 10 Activety diagram
29
4.6 Data Flow Diagram
A data flow diagram (DFD) maps out the flow of information for any process or system.
It uses defined symbols like rectangles, circles and arrows, plus short text labels, to show
data inputs, outputs, storage points and the routes between each destination. The logical
data flow diagram describes flow of data through a system to perform certain
functionality of a project.
4.6.1 Context Level 0:
DeRent
DeRent
Figure 11 DFD Level 0
30
4.6.2 Level 1DFD
Figure 12 Level 1 DFD
31
4.7 Deployment Diagram
DeRent
Device
Figure 13 Deployment Diagram
32
4.9 Graphical User Interfaces
4.9.1 Home page
Figure 14 GUI for Home page
33
4.9.2 Admin Login
Figure 15 GUI for Admin Login
34
4.9.3 Sign Up as a Vendor
Figure 16 GUI for Signup(Vendor)
35
4.9.4 Signup for Borrower
Figure 17 GUI for Signup(Borrower)
36
4.9.5 Borrower profile
Figure 18 GUI for Borrower profile
37
4.9.6 Chat
Figure 19 GUI for Chat
38
4.9.7 Products table
Figure 20 GUI for Products Table
39
CHAPTER 5
SYSTEM TESTING
40
Once the system has been developed next phase is the system testing. Even if the system
is developed using correct algorithms, its reliability remains doubtful. The validation of
results is very important to make the system acceptable. Before making the system
operational it is necessary to check that the new system is comprehensive with in its limits
and produced the required outputs correctly. Implementation means to adopt the newly
designed system in practice. It may involve the complete implementation of computer
system or the introduction of one small subsystem. The conversion of manual system into
computerized data processing system is one of the, most important activity.
Implementation phase of our project cover the period from the acceptance of the test
design to its satisfactory operation supported by the appropriate user and operation
manual.
Software testing to check whether the actual results match the expected results and to
ensure that the software system is defect free and meets the requirements.
Software testing makes sure that the testing is being done properly and hence the
system is ready for use.
5.1 Purpose of Testing

After competition of coding reviewing software and check all queries, then procedures,
output, input values and triggers. We check buttons to see that they work properly check
alert on execution on time and check report information for errors. Testing begins at the
component level and works towards the integration of entire computer-based system.
 To check the reliability of the app.
 It ensures that the app is free from any bug that can cause any kind of failure.
 It ensures that the app is in line with the requirements.
 To make sure that the app is user-friendly To find out alert sending response
timings.
 To test UI and UX experiences.
5.2 Objectives of Testing

Software Testing has different goals and objectives. The major objectives of
Software testing are as follows: Finding defects which may get created by the
programmer while developing the software. Gaining confidence in and providing
information about the level of quality. To prevent defects.
41
5.3 Testing Techniques
5.3.1 Black Box Testing

Black box testing also known as Behavioral Testing, is a software testing method in
which the internal structure/design/implementation of the item being tested is not known
to the tester. These tests can be functional or non-functional, though usually functional.
Following are some techniques that can be used for designing black box tests:[6]
 Equivalence Partitioning: It is a software test design technique that involves

dividing input values into valid and invalid partitions and selecting representative
values from each partition as test data.
 Boundary Value Analysis: It is a software test design technique that involves the
determination of boundaries for input values and selecting values that are at the
boundaries and just inside/ outside of the boundaries as test data.
 Cause-Effect Graphing: It is a software test design technique that involves
identifying the cases (input conditions) and effects (output conditions), producing
a Cause-Effect Graph, and generating test cases accordingly.
5.3.1 a Interface Name: A-Login

UCNo: 01 User Name
Valid: {A-Z, a-z, 0-9, @, #, $, %, &}
Invalid: Empty
Table 10 User Login
Test Case Input Use case Format Expected Actual Output
ID Output
01 Akram {A-Z, a-z, 0-9, @, #, $, Valid Name Name Displayed
%, &}
02 Empty Invalid Name Name Rejected
42
5.3.1 b Interface Name: A-Login
UCNo 02: Password
Valid: {1-20} length
Invalid: {Less than 1}
Invalid: {Greater than 20}
Table 11 Vendor Password Length

Test Input Use case Expected Actual
Case Format Output Output
ID
01 Akram {1-20} Valid Password
length Password Displayed
02 {Less Invalid Password
than 1} Password Rejected
03 Akramkhankjjkkisagreatguyhelovehisgirl {Greater Invalid Password
than 20} Password Rejected
5.3.1 c Interface Name: A-Login

Interface Name: A-Login
UCNo 2.1: Password
Valid: {A-Z, a-z, 0-9, @, #, $, %, &}
Invalid: Empty
Table 12 Borrower Password Length

ID Output
01 @Borrower {A-Z, a-z, 0-9, @, #, $, Valid Password
%, &} Password Displayed
02 Empty Invalid Password
Password Rejected
43
5.3.1 d Interface Name: Borrower/Vendor_changepassword
UCNo 3: Confirm Password
Valid: Equal
Invalid: Not equal
Table 13 Change Password
Test Case Input Use case Expected Actual Output
ID Format Output
01 Confirm password = = Equal Valid Roll no Password

New password Accepted
02 Confirm password != Not equal Invalid Password
New Password Password Rejected
5.3.1 e Interface Name: Products_Table

UCNo 4: Session
Valid: Select from available products
Invalid: Empty
Table 14 Products tabe
ID Output
01 Product Select from available Valid product Product
name products Displayed
02 Empty Invalid Product Product
Rejected
44
5.3.1 f Interface Name: Product
Interface Name: Product
UCNo 6: All details
Valid: submitted
Invalid: Not fully submitted
Table 15 Add Product
Test Case Input Use case Expected Actual Output
ID Format Output
01 Submit all details submitted Valid detail. Record saved
02 Submit all details Not fully Invalid details Record not save.
submitted
5.3.1 g Interface Name:Vendor/ Borrower _Addcontact

UCNo -8: Contact #
Valid: {length = = 11}
Invalid: {length < 11}
Invalid: {length > 11}
Table 16 Add Contact Vendor/Borrower
Test Case Input Ecp Expected Actual Output

ID Output
01 03225768788 {length = = Valid no Number
11} Displayed
02 034466 {length < 11} Invalid no Number Rejected
03 03339876543456788 {length > 11} Invalid no Number Rejected
45
5.3.2 White Box Testing
White-box testing (also known as Clear Box Testing, Open Box Testing, Glass Box
Testing, Transparent Box Testing, Code-Based Testing, or Structural Testing) is a
software testing method in which the internal structure/design/implementation of the item
being tested is known to the tester.
5.3.2 a Login Code

class Vendor{
constructor(id, fullname, phone, email, password,
workingcategory, subcategories, profilepicture, rating, dateofjoining,city, status ) {
this.id = id;
this.fullname = fullname;
this.phone = phone;
this.email = email;
this.password = password;
this.workingcategory = workingcategory;
this.subcategories = subcategories;
this.profilepicture = profilepicture;
this.rating = rating;
this.dateofjoining = dateofjoining;
this.city=city;
this.status = status;
}
class Borrower {
constructor(id, fullname, phone, email, password,
profilepicture, rating, dateofjoining, status ) {
this.id = id;
this.fullname = fullname;
this.phone = phone;
this.email = email;
this.password = password;
this.workingcategory = workingcategory;
this.subcategories = subcategories;
46
this.profilepicture = profilepicture;
this.rating = rating;
this.dateofjoining = dateofjoining;
this.city=city;
this.status = status;
}
}
The tester chooses inputs to exercise paths through the code and determines the
appropriate outputs.
 Path Coverage
 Statement Coverage
 Control flow testing
5.3.1 b White Box Test Cases

Table 17 White Box Test Case
Condition Username Password Email C-No. User Type Test Case
If -1,2,3,4, Waqas Pak5454 ar@g 031705 Borrower (1) Waqas Pak5454
5,6,7 mail.c 96277 ar@gmail.com
om 03170596277
13101-3338897-0
Customer
om 03170596277
13101-3338897-0
Customer
If -1,2,3,4, Waqas12 Pak5454 ar@g 031705 Borrower (3) Arooba12
5,6,7 mail.c 96277 Pak5454
om ar@gmail.com
03170596277
13101-3338897-0
Customer
47
If -1,2,3,4, Waqas Pak5454 abc@g 031705 Borrower (4) Waqas Pak5454
5,6,7 mail.c 96277 abc@gmail.com
om 03170596277
13101-3338897-0
Customer
om 0333777667
13401-3338897-5
Customer
om 03170596277
13101-3338897-0
Vendor
If -1,2,3,4, Waqas12 Pak5454 ar@g 031705 Borrower (7) Waqas12
5,6,7 mail.c 96277 Pak5454
om ar@gmail.com
03170596277
13101-3338897-0
Tailor
om 03170596277
13101-3338897-0
If -1,2,3,4, Waqas Pak5454 031705 Borrower (9) Waqas Pak5454
5,6,7 96277 03170596277
13101-3338897-0
Customer
If -1,2,3,4, Waqas ar@g Borrower (10) Waqas Pak5454
5,6,7 mail.c ar@gmail.com
om 13101-3338897-0
Customer
48
5.3.1 c Results
Table 18 Test Case Result
Test case Id. Path Covered
1 ABCDEFGHI
2 ABCDK
3 ABCJ
4 ABCDEL
5 ABCDEFM
6 ABCDEFGN
7 ABCJ
8 ABCDEFGN
9 ABCDK
10 ABCJ
5.4 Unit Test

Unit testingis a level of software testing where individual units/ components of the
software are tested. The purpose is to validate that each unit of the software performs as
designed.
5.5 Integration Testing

Integration Testfocuses mainly on the interfaces & flow of data/information between the
modules. Here priority is to be given for the integrating links rather than the unit
functions which are already tested. We tested app modules interaction after combining
them.
Sample Integration Test Cases for the following scenario:
 Signup Activity and Login

 Borrower place order
 Vendor accept and Order done.
 And each of them is integrated logically.
49
Table 19 Integration Testing
Test Test Case ID Test case Expected

Test Method
case Id with Title Description Result
Administrator,
Vendor & White Box and
Test Case 01 Successful
1 Borrower Requests Black Box testing is
(Login) Login
the System for performed
Login
Test Case 02 Borrower view and Successful in White Box and
2 (View search the desired finding and Black Box testing is
Services) product viewing product performed
Test Case 03 By using this form White Box and
Successful in
3 (User new user can Black Box testing is
user registration
Registration) register himself performed
Successful in White Box and
Test Case 04 Vendor add new
4 Adding New Black Box testing is
(Add Product) product
Product performed
Test Case 05 Users attempt to White Box and
Successful in
5 (Update update specific Black Box testing is
Updating record
Record) record performed
Borrower place White Box and
Test Case 06 Successful in
6 order on the Black Box testing is
(Add Order) Adding order
Product performed
Vendor view the White Box and
7 order placed on Black Box testing is
(View Order) viewing order
specific product performed
Test Case 08 User can change Successful in White Box and
8 (Change their user account Changing Black Box testing is
Password) password Password performed
User of system White Box and
9 attempt to logout Black Box testing is
(Logout) logout
from system. performed
50
5.6 System Testing
System testing is testing conducted on a complete integrated system to evaluate the
system's compliance with its specified requirements.
System testing takes, as its input, all of the integrated components that have passed
integration testing. The purpose of integration testing is to detect any inconsistencies
between the units that are integrated together (called assemblages). System testing seeks
to detect defects both within the "inter-assemblages" and also within the system as a
whole. The actual result is the behavior produced or observed when a component or
system is tested.
51
CHAPTER 6
CONCLUSION
52
CONCLUSION
The main purpose of DeRent ( Online Renting System) is Vendors/users to advertise their
available products in our web site and also to provide available products booking for the
users. Here in the system we are providing a great flexibility for the vendor/user to add,
delete or update his products in our web site. They are able to update or delete their
personal account. We are maintaining good communication between vendors and the
customers. There are many rental systems are available in online. But, they are not
providing all products at one place. Also many of them restricted to only one city. That
means car rental system in online deals only with cars. Also many of them are not
providing effective communication between customer and the vendor. Also present rental
systems restricted to only one vendor means products are supplied only from one rental
show room. It provides services such as Electronic devices, Sports Goods, Books,
Furniture & Home decor, and Other Products. It provides the facility to make online
orders and get everything done before you reach the destination. This web application
provides a platform for users and rental product(s) owners/venders, in an effective and
efficient manner.
53
REFERENCES
 Jaffery A Hoffer, Mary B Prescott & Fred R McFadden - Modern Database

Management (Eighth Edition).
 Kenneth E Kendall & Julie - System Analysis and Design.
 Rojer Pressman - Software Engineering
 Software Engineering- A practitioner's Approach by Roger S. Pressman: 6th
edition McGraw Hill, 2005
 An Integrated Approach to Software Engineering by Pankaj Jalote:3rd edition
Springer, 2005
 Rojer Pressman - Software Engineering Fifth Edition
 Software engineering A Beginner’s Guide, 2nd Edition by Wendy Willard.
 Wrox - Beginning Java Database Programming.
 Android, A Programmers Guide by J.F. DiMarzio
 http://www.wikipedia.org
54

DeRent Final Thesis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DeRent Final Thesis

Uploaded by

Copyright:

Available Formats

DeRent

Department of Computer Science

1.1 Purpose ............................................................................................................................. 2

1.2 Scope ................................................................................................................................ 2

1.3 Objective ............................................................................................................................ 2

1.4 Use Cases and Usage Scenarios: ...................................................................................... 3

1.4.1 Use Case Diagram ..................................................................................................................... 3

1.4.2 Extended Use Case Diagram ..................................................................................................... 4

1.4.3 Usage scenarios ......................................................................................................................... 5

1.5 Tools Used ...................................................................................................................... 11

1.5.1 Frontend: .................................................................................................................................. 11

1.5.3 Documentation: ........................................................................................................................ 11

THEORETICAL BACKGROUND ............................................................................... 12

2.1 Limitation of Existing System ........................................................................................ 13

2.2.1 Inconsistency ........................................................................................................................... 13

2.2.2 Limited .................................................................................................................................... 13

2.2.3 Communication ....................................................................................................................... 13

2.2.4 Limited showroom ................................................................................................................... 13

2.2.5 Time consuption ...................................................................................................................... 13

PROPOSED SYSTEM .................................................................................................... 14

3.1 Modules .......................................................................................................................... 15

3.1.1 Authentication ......................................................................................................................... 15

3.1.1.a Borrower: ............................................................................................................................ 15

3.1.2 Borrower: ................................................................................................................................. 16

3.1.3 Vendor ..................................................................................................................................... 16

3.1.4 Product ..................................................................................................................................... 16

3.1.5 Rating ...................................................................................................................................... 17

3.2 Functional Requirements ................................................................................................ 17

3.3 Non-Functional Requirements........................................................................................ 17

3.3.1 Usability .................................................................................................................................. 17

3.3.2 Performance Requirements ...................................................................................................... 17

3.3.3 Availability .............................................................................................................................. 18

3.3.4 System Requirements: ............................................................................................................. 18

3.3.4.a Hardware Requirements: .................................................................................................... 18

3.4.4.b Software Requirements: ...................................................................................................... 18

3.4 Feasibility Study ............................................................................................................. 18

3.4.1 Economic Feasibility ............................................................................................................... 19

3.4.2 Operational Feasibility ............................................................................................................ 19

3.4.3 Technical Feasibility ............................................................................................................... 19

3.5 Chosen Methodology...................................................................................................... 20

3.5.1 Incremental Development Model .............................................................................................. 20

3.6 Reason for Chosen Methodology ................................................................................... 21

3.7 Work Plan ....................................................................................................................... 21

3.7.1 Project Plan in Visio .................................................................................................................. 21

3.8 Project Structure ............................................................................................................. 21

3.8.1 Team Structure ........................................................................................................................ 21

3.8.2 Members .................................................................................................................................. 22

SYSTEM DESIGN ........................................................................................................... 23

4.1 Purpose ........................................................................................................................... 24

4.3 Definition, Acronyms, and Abbreviations ...................................................................... 25

4.3.1 Definitions ............................................................................................................................... 25

4.4 Sequence Diagram .......................................................................................................... 25

4.4.1 Sequence Diagrams for registration ......................................................................................... 26

4.4.2 Sequence Diagrams (Vendor) .................................................................................................. 27

4.4.3 Sequence Diagram (Borrower) ................................................................................................ 28

4.5 Activity Diagram ............................................................................................................ 29

4.6 Data Flow Diagram ........................................................................................................ 30

4.6.1 Context Level 0: ...................................................................................................................... 30

4.6.2 Level 1 DFD ........................................................................................................................... 31

4.7 Deployment Diagram ..................................................................................................... 32

4.8 Graphical User Interfaces ............................................................................................... 33

4.8.1 Home page ............................................................................................................................... 33

4.8.2 Admin login ............................................................................................................................. 34