Java

A PROJECT REPORT
on
ONLINE AUCTION SYSTEM
Submitted in the fulfillment of the requirement

for the award of the degree of
Bachelor of Technology
in
INFORMATION TECHNOLOGY
by
Sachin Loverale(20140728)
Sainath Narwane(20140734)
Aman Gawande(20150721)
Akshay Perkar(20150747)
Rahul Tamgadge(20150758)
Under the guidance of

Prof. V.J. Kadam
DEPARTMENT OF INFORMATION TECHNOLOGY

DR. BABASAHEB AMBEDKAR TECHNOLOGICAL UNIVERSITY
Lonere-402103, Tal.-Mangaon, Dist.-Raigad (M.S.) INDIA.

2018-2019
CERTIFICATE
This report entitled Online Auction System submitted by Sachin Loverale(20140728),

Sainath Narwane(20140734), Aman Gawande(20150721), Akshay Perkar(20150747)
,Rahul Tamgadge(20150758) is approved for the partial fulfillment of the requirement for the
award of the degree of Bachelor of Technology in Information Technology.
Examiners:
1. (Name: )
2. (Name: )
Place: Dr. Babasaheb Ambedkar Technological University, Lonere.
Dr. S. M. Jadhav
Head
Department of Information Technology
i
Acknowledgement
This work is just not an individual contribution till its completion. We take this opportunity to express a
deep gratitude towards my guide Prof. V.J.Kadam, for providing excellent guidance encouragement
and inspiration throughout the Training work. Without his invaluable guidance, this work would never
have been a successful one.
We wish to express our sincere thanks to the all department faculties and staff members for their
support. We would also like to thank our all classmates for their valuable guidance and helpful discus-
sion.
Sachin Loverale(20140728)
Sainath Narwane(20140734)
Aman Gawande(20150721)
Akshay Perkar(20150747)
Rahul Tamgadge(20150758)
ii
Abstract
The online auctioning system is a flexible solution for supporting lot- based online auctions. The thesis
explains the construction of an auction website. The system has been designed to be highly-scalable and
capable of supporting large numbers of bidders in an active auction. The online auction system lets you
easily browse lots and place bids using a secure server. All cost of mailing lots will be paid by the buyer.
The objective is to develop a user-friendly auctioning site where any kind of product can be auctioned
and provide valueadded services to the bidders and the sellers. The products will be authenticated and
the site provides a safe environment for online users.
iii
Contents
1 INTRODUCTION 1
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 No of Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Description For Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Admin Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Seller Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.3 Buyer Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.4 Visitor Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.5 Security and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Goals of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 RESEARCH AND TECHNOLOGY 5

2.1 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Existing System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Proposed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Technology Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.5 Apache Web Server(XAMPP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.6 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 ANALYSIS AND DESIGN 10

3.1 Requirement analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Use case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Structural model view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
iv
3.2.2 Behavioral model view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3 Implementation Model View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4 Environmental Model View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 DATA FLOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 DATA FLOW DIAGRAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.7 SEQUENCE DIAGRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Database Implementation and Interface 23

4.1 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Database Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5 TESTING 26
5.1 SOFTWARE TESTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 FUTURE ENHANCEMENTS AND CONCLUSION 30

6.1 Limitations of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2 Future Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3 Work Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
v
List of Figures
3.1 System Usecase Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Database Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 DFD Level 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 DFD Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.7 DFD Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.8 System Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.9 Interaction Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.10 Admin Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.11 Administrator activity diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.12 Seller activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.13 Buyer activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 user information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 product information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Biddings information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1 Performance Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1
Dept. of Information Technology Online Auction System
Chapter 1
INTRODUCTION
An Auction is Latin work which means augment. Auction is a bid, a process of selling; buying and
services offered take place. There are several different types of auctions and certain rules exist for each
auction. There are variations for an auction which may include minimum price limit, maximum price
limit and time limitations etc. Depending upon the auction method bidder can participate remotely or
in person. Remote auction include participating through telephone, mail, and internet. Shopping online
has widely grown; online auction system is increasing rapidly. Online auction is becoming more and
more popular in electronic commerce and hence it should system must increase its quality and security.
The online auction system is a model where we participate in a bid for products and service. This
auction is made easier by using online software which can regulate processes involved. There are several
different auction methods or types and one of the most popular methods is English auction system. This
system has been designed to be highly-scalable and capable of supporting large numbers of bidders in
an active auction.
Online Auctioning System has several other names such as e-Auctions, electronic auction etc. The
requirement for online auction or online bidding can be more accurately specified by the client. It should
be healthy and will be a good practice when it is made more transparent as a matter of fact.
Online Bidding has become more wide spread in all sorts of industrial usage. It not only includes
the product or goods to be sold, it also has services which can be provided. Due to their low cost this
expansion made the system to grow.
Online bidding has become a standard method for procurement process. Bidders can be maintained in
a single database according to the preference, and they can be monitored. User’s data can be maintained
in a confidential way for validity and integrity of contractual documentation. Neat reporting reduces
Dr.Babasaheb Ambedkar Technological University 1

paperwork, postage, photocopying and time beneficial. Multiple bidders can be communicated with a
great ease. This system allows multiple bids by single users.
Online bidding is based upon lowest or the highest price which is initiated but not the best value for
the product. Although there is a chance to fix the criteria against the fact expected to have desired
value by the seller.
1.1 Overview
• Secure registration of all users including a personal profile Administrators would authorize the
product to auction, set auction dates and Minimum auction amount for that product.
• Prior to each bid, the user’s bank or credit account must be authenticated for available balance
required for the bid.
• Complete Search/Site Map of the entire site for easy access.
• Discussion forums for users to interact with other users to know about the product’s value and
originality.
• Online Legal Documentation to avoid disputes. Guidance to the users about the same must be
available.
• Rare articles may be withheld by owner on the advice of the administrator to be thrown open in
special auctions held by the site so as to increase the bid-values.
1.1.1 No of Modules
The system after careful analysis has been identified to be presented with the following modules:
• Admin Module.
• Seller Module.
• Buyer Module.
• Visitor Module.
• Security and authentication.

1.2 Description For Modules

1.2.1 Admin Module
This module provides the complete information related to products for sale and the buyers can bid
for the products and can own them. All this has to be provided and maintained by the admin because
the complete auction process is to be kept under control till the product sale gets confirmed.
1.2.2 Seller Module

Sellers want a place where seller can sale their products at a higher price and get maximum benefit
out of that. This is the place where seller can display all his products and sell them.
1.2.3 Buyer Module

The people always want different things to purchase but in the local market they can have local
products only. But in this application buyer can buy any product from any part of the world at a very
best competitive price and own the product.
1.2.4 Visitor Module

Visitor is nothing but all the people who visits this application online. They can know the information
of all the products, which are for sale under this application.
1.2.5 Security and Authentication

The security and authentication is as follows:
• Login as buyer or seller or administrator.
• Change password.
• Forgot Password.
• Registration for buyer / seller.
1.3 Goals of the Project

The main goals of this system are to sell and bid different types of products to the customers living
anywhere around India. The website will show all products in categorized manner. Customers can
browse any product and their details and can bid on the products. User has to get the order through
the delivery policy. Admin can keep track of bids through admin panel.

1.4 Project Scope

Online Auction System- BidWarBd will be a web based application which main language of program-
ming will be PHP. Its main aim is to simplify and improve the efficiency of the bidding process for users,
minimize data entry and ensure data accuracy and security bid placement process. Users will also be
able to view all product menus in categorized way with their full details. Users will also be able to have
a visual confirmation that the order was place correctly.

Chapter 2
RESEARCH AND TECHNOLOGY
The online auctioning system is a flexible solution for supporting lot- based online auctions. The
system has been designed to be highly-scalable and capable of supporting large numbers of bidders in
an active auction. To help business with finance’s and purchases in online auctioning system.
2.1 Research
Research includes what existing system is and the purpose of the system.
2.1.1 Existing System

From a recent study make by scientists at Carnegie Mellon University, found many fraud schemes
from the historical auction data using data mining techniques and other accomplices One of the most
currently fraud schemes is that the bidders are masking false identity or accounts in order to increase
the sale price.
Currently there are two approaches mostly being implemented such as policy-based and reputation-
based trust management which also lag certain security issues.
There was a recently proposed system by Ganeriwal and Srivastava, which was a reputation based
model for sensor networks. This system works well in maintain the reputation for the nodes and also in
evaluating trustworthiness. But the main drawback is that there is no effective and particular method to
prevent the users from giving false identity and hence the system fails in providing a secured environment.

2.1.2 Proposed System

The development of this new system contains the following activities, which try to develop the web-
application entire process keeping in the view of database integration approach:
• This system will generate team progress and also provides secure registration and profile manage-
ment of the users.
• Administrators would authorize the product to auction, set auction dates and minimum auction
amount for that product.
• Prior to each bid, the user’s bank or credit account must be authenticated for available balance
required for the bid.
• Users can select their interested fields for bidding and periodic Mail alerts must be sent in case an
article in that field goes on auction.
• Complete Search/Site Map of the entire site for easy access.
2.2 Technology Description

The proposal has to be described in a detailed form to get an overview and an understanding of the
functionalities of the technical approach. This provides the technical description of the characteristics
of a proposal.
To build up this website I have used the main language of programming PHP. For database system,
I have used MYSQL. For designing the view in both front-end and back-end, I have used HTML, CSS,
Bootstrap Programming languages: PHP Database system: MYSQL Markup languages: HTML, CSS
2.2.1 HTML
HTML, an initialize of Hypertext Markup Language, is the predominant markup language for web
pages. It provides a means to describe the structure of text-based information in a document — by
denoting certain text as headings, paragraphs, lists, and so on — and to supplement that text with
interactive forms, embedded images, and other objects.
HYPER TEXT MARKUP LANGUAGE

Hypertext Markup Language (HTML), the languages of the World Wide Web (WWW), allows users
to produces Web pages that include text, graphics and pointer to other Web pages (Hyperlinks).

HTML can be used to display any type of document on the host computer, which can be geographically
at a different location. It is a versatile language and can be used on any platform or desktop.
HTML provides tags (special codes) to make the document look attractive. HTML tags are not case-
sensitive. Using graphics, fonts, different sizes, color, etc., can enhance the presentation of the document.
Anything that is not a tag is part of the document itself.
ATTRIBUTES
The attributes of an element are name-value pairs, separated by ”=”, and written within the start
label of an element, after the element’s name. The value should be enclosed in single or double quotes,
although values consisting of certain characters can be left unquoted in HTML (but not XHTML).Leaving
attribute values unquoted is considered unsafe. Most elements take any of several common attributes:
id, class, style and title. Most also take language-related attributes: language and dir.
ADVANTAGES
The advantages include:
• A HTML document is small and hence easy to send over the net. It is small because it does not
include formatted information.
• HTML is platform independent.
• HTML tags are not case-sensitive.
2.2.2 CSS
A cascading style sheet (CSS) is a Web page derived from multiple sources with a defined order
of precedence where the definitions of any style element conflict. The Cascading Style Sheet, level 1
recommendation from the World Wide Web Consortium, which is implemented in the latest versions
of the Netscape and Microsoft Web browsers, specifies the possible style sheets or statements that may
determine how a given element is presented in a Web page. CSS gives more control over the appearance
of a Web page to the page creator than to the browser designer or the viewer. With CSS, the sources of
style definition for a given document element are in this order of precedence.
2.2.3 Bootstrap
What is Bootstrap?
• Bootstrap is a free front-end framework for faster and easier web development

• Bootstrap includes HTML and CSS based design templates for typography, forms, buttons, tables,
navigation, modals, image carousels and many other, as well as optional JavaScript plugins
• Bootstrap also gives you the ability to easily create responsive designs
Why Use Bootstrap?
Advantages of Bootstrap:
• Easy to use: Anybody with just basic knowledge of HTML and CSS can start using Bootstrap
• Responsive features: Bootstrap’s responsive CSS adjusts to phones, tablets, and desktops
• Mobile-first approach: In Bootstrap 3, mobile-first styles are part of the core framework
• Browser compatibility: Bootstrap is compatible with all modern browsers (Chrome, Firefox, In-
ternet Explorer, Edge, Safari, and Opera)
2.2.4 JavaScript
JavaScript is a script-based programming language that was developed by Netscape Communication
Corporation. JavaScript was originally called Live Script and renamed as JavaScript to indicate its
relationship with Java. JavaScript supports the development of both client and server components of
Web-based applications. On the client side, it can be used to write programs that are executed by a
Web browser within the context of a Web page. On the server side, it can be used to write Web server
programs that can process information submitted by a Web browser and then update the browser’s
display accordingly.
ADVANTAGES
The advantages include:
• JavaScript can be used for Sever-side and Client-side scripting.
• It is more flexible than VBScript.
• JavaScript is the default scripting languages at Client-side since all the browsers supports it.
2.2.5 Apache Web Server(XAMPP)

Apache is a freely available Web server that is distributed under an open source license. Version
2.0 runs on most UNIX-based operating systems (such as LINUX, Digital UNIX, and AIX), on other

UNIX/POSIX-derived systems (such as Rhapsody, BeOS, and BS2000/OSD), on amigos and on Win-
dows 2000. According to a Net craft Web server survey 60 percent of all Web sites on the Internet are
using Apache (62 percent including Apache derivatives), making Apache more widely used than all other
Web servers combined. Apache is open-source software. The name Apache was chosen from respect for
the Native American Indian tribe of Apache, well-known for their superior skills in warfare strategy and
their inexhaustible endurance. It also makes a cute pun on a patchy web server a server made from a
series of patches but this was not its origin. The group of developers who released this new software
soon started to call themselves the Apache Group.
2.2.6 PHP
PHP is an alternative to Microsoft’s Active Server Page (ASP) technology. As with ASP, the PHP
script is embedded within a Web page along with its HTML. Before the page is sent to a user that has
requested it, the Web server calls PHP to interpret and perform the operations called for in the PHP
script. An HTML page that includes a PHP script is typically given a file name suffix of php .php3,” or
”.phtml”. Like ASP, PHP can be thought of as dynamic HTML pages, since content will vary based on
the results of interpreting the script.

Chapter 3
ANALYSIS AND DESIGN
Development of web based systems requires analysis of the process to be digitized in order to enable
a correct system, a system that functions as required and to assist the potential users of the system
understand the general functionality of the system. The analysis specifies the system’s objectives and
constraints to which designers have to comply. The purpose of doing analysis is to transform the system’s
major inputs into structured specification. This has mainly two requirement section- Admin section and
User section.
3.1 Requirement analysis

• Each user type admin or user needs to register him or her as a user or an admin for accessing the
user’s necessary information. They also have email, username and password. They can login into
the system from the web using their email and password.
• Admin needs to login to the system to operate the system. Admin has an individual or unique
login email, password and a user level. Through this email and password admin can login into the
system.
• Admin can update all product pages. An admin can insert a new product with details and can
update the product information through edit option.
• Admin can delete user from user panel. It can have the full access of user’s bid list.
• Admin can have access in the bid page.
• Users can look for a product from a selected category.
• User can add a product to the site with full details of that product.

• They can see their products and bided list through their account page.
• Users can edit their profiles.
3.2 Use case Diagram

The unified modeling language allows the software engineer to express an analysis model using the
modeling notation that is governed by a set of syntactic semantic and pragmatic rules. A UML system
is represented using five different views that describe the system from distinctly different perspective.
Each view is defined by a set of diagram, which is as follows. User Model View i. This view represents
the system from the users perspective. ii. The analysis representation describes a usage scenario from
the end-users perspective.
3.2.1 Structural model view

In this model the data and functionality are arrived from inside the system. This model view models
the static structures.
3.2.2 Behavioral model view

It represents the dynamic of behavioral as parts of the system, depicting the interactions of collection
between various structural elements described in the user model and structural model view.
3.2.3 Implementation Model View

In this the structural and behavioral as parts of the system are represented as they are to be built.
3.2.4 Environmental Model View

In this the structural and behavioral aspects of the environment in which the system is to be imple-
mented are represented.
Use case Diagrams represent the functionality of the system from a users point of view. Use cases
are used during requirements elicitation and analysis to represent the functionality of the system. Use
cases focus on the behavior of the system from external point of view. Actors are external entities that
interact with the system. Examples of actors include users like administrator, bank customer etc., or
another system like central database.

Figure 3.1: System Usecase Diagram
3.3 ER Diagram
An entity relationship model (ER model for short) describes interrelated things of interest in a specific
domain of knowledge. A basic ER model is composed of entity types (which classify the things of interest)
and specifies relationships that can exist between instances of those entity types.
In software engineering, an ER model is commonly formed to represent things that a business needs to
remember in order to perform business processes. Consequently, the ER model becomes an abstract data
model, that defines a data or information structure which can be implemented in a database, typically
a relational database.
This ER (Entity Relationship) Diagram represents the model of online auction system Entity. The
entity-relationship diagram of online auction system shows all the visual instrument of database tables
and the relations between products,seller,bidder, winner etc.It used structure data and to define the
relationships between structured data groups of Online Auction System functionalities. The main entities
of the Online Auction System are Seller,Bidder,Products,Winner.

Figure 3.2: ER Diagram

3.4 Class Diagram

a class diagram in the UML is a type of static structure diagram that describes the structure
of a system by showing the system’s classes, their attributes, operations (or methods), and the re-
lationships among objects. Classes included in following diagram: Online Auction,Featured Prod-
uct,Winner,User,Seller,Admin.
Figure 3.3: Class Diagram
3.5 DATA FLOW

A graphical tool used to describe and analyze the moment of data through a system manual or
automated including the process, stores of data, and delays in the system. Data Flow Diagrams are
the central tool and the basis from which other components are developed. The transformation of data

from input to output, through processes, may be described logically and independently of the physical
components associated with the system. The DFD is also know as a data flow graph or a bubble chart.
DFDs are the model of the proposed system. They clearly should show the requirements on which
the new system should be built. Later during design activity this is taken as the basis for drawing the
system’s structure charts.
Figure 3.4: Database Diagram
3.6 DATA FLOW DIAGRAMS

The data flow diagram shows the entire flow in the process.
In the Login Screen the entered username and password will be supplied to the authentication server
and if the login credentials are valid the user will be directed to the home screen and if they are invalid
the user will be taken back to the login screen
After logging in Admin will be redirected to the User Interface which displays all the available admin
tasks that are to be performed. These tasks include Creating/Modifying Categories, Creating/Modifying
Items and Bidding Information.

From the UI Interface Admin adds a new Category which will be stored in the database upon successful
creation
Figure 3.5: DFD Level 0
View Categories will fetch the categories information from the database and displays on the user
interface.
In the Categories form category name can be entered and it will be stored in the database.
For Seller the first step is registration and upon successful login the seller will be taken to the UI
displaying the set of operations. The operations include View Items, View Categories, View Bidding
Information and sale at higher price.
From the User Interface clicking the items will fetch the items from the database and will be
displayed to the seller
For buyer the first step is registration and upon successful login the UI is displayed with a set of
operations. Operations include View Items, View Categories, View Biding Information and buying all
possible items. Items will be fetched from the database and displayed on the User Interface

3.7 SEQUENCE DIAGRAM

Sequence Diagram is also known as Interaction Diagrams.From the term Interaction, it is clear that
the diagram is used to describe some type of interactions among the different elements in the model. This
interaction is a part of dynamic behavior of the system.This interactive behavior is represented in UML
by two diagrams known as Sequence diagram and Collaboration diagram. The basic purpose of both
the diagrams are similar.Sequence diagram emphasizes on time sequence of messages and collaboration
diagram emphasizes on the structural organization of the objects that send and receive messages.
The purpose of interaction diagrams is to visualize the interactive behavior of the system. Visualizing
the interaction is a difficult task. Hence, the solution is to use different types of models to capture the

different aspects of the interaction.Sequence and collaboration diagrams are used to capture the dynamic
nature but from a different angle.
The purpose of interaction diagram is :
• To capture the dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.
Figure 3.8: System Sequence Diagram

Figure 3.9: Interaction Sequence Diagram
3.8 Activity Diagram

After successful validation of login credentials Admin will be redirected to the home page and from
the home page he can add items for auction, view items that are up for auction, add categories, view
categories, add bidding info and view bidding info as per shown in Admin activity diagram
After successful validation of login credentials seller/owner will be redirected to the home page and
from the home page he can view items, update or delete items, view categories, view bidding info, update
bidding info and delete bidding info as shown in Seller activity diagram.
After successful validation of login credentials registered bidder will be redirected to the home page
and from the home page he can view items, view categories and view bidding info as shown in Buyer
activity diagram.

Figure 3.10: Admin Sequence Diagram

Figure 3.11: Administrator activity diagram.
Figure 3.12: Seller activity diagram

Figure 3.13: Buyer activity diagram

Chapter 4
Database Implementation and

Interface
4.1 Database Design

Database design is the process of producing a detailed data model of a database. This logical 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.
The term database design can be used to describe many different parts of the design of an overall
database system. Principally, and most correctly, it can be thought of as the logical design of the base
data structures used to store the data. In the relational model these are the tables and views. In an
object database the entities and relationships map directly to object classes and named relationships.
However, the term database design could also be used to apply to the overall process of designing,
not just the base data structures, but also the forms and queries used as part of the overall database
application within the database management system. The process of doing database design generally
consists of a number of steps which will be carried out by the database designer. Usually, the designer
must:
• Determine the relationships between the different data elements.
• Superimpose a logical structure upon the data on the basis of these relationships.
In the following section a detailed database structure of the ‘Online Auction System’ is elaborated
with all the details.

4.2 Database Interface

Table Number 1: users
Purpose: Users Information
Description: This table will contain the user information. Users are who is using this system. This
table will be using for authentication of users
Figure 4.1: user information table
Table Number 2: product
Purpose: Products Information.
Description: This table will contain the products details information. This information will help
to add new products and delete old products.
Table Number 3: bid
Purpose: Biddings Information.
Description: This table will contain the bidding details information. This information will help to
show biddings against categorized products and delete old biddings information.

Figure 4.2: product information table
Figure 4.3: Biddings information table

Chapter 5
Design Interface
5.1 User interface:

Home Page:
Description: In home or index page, anyone can login or sign up on the given Log In link. They can
see today’s bidding products page even if they are not logged in or signed up.
Sign In Page:
Description: Signed up users have to login first to get the privilege to bid the products. If a person
fills the form and submits, then he or she becomes a user or admin of the site.
Sign Up Page:
Description: If a person fills the form and submits, then he or she becomes a user or admin of the
site. After successful sign up, the user must go to Log In link to login with the username and password
he/she submitted into the database when they signed up.
Sell A Product:

Description: Users can upload their product through this page to bid.
My Account:
Description: From this page user can check their personal info, their bided products and uploaded
products.
Edit Account:
Description: From this page user can edit their profile.
Category Page:
Description: Users will be shown this category page where he/she can see all categories in stock in
categorized manner.
Best Bid Page:
Description: Users will be shown this category page where he/she can see Best Bid category in stock
in categorized manner for bidding.

Chapter 6
TESTING
6.1 SOFTWARE TESTING

Software Testing is the process used to help identify the correctness, completeness, security, and
quality of developed computer software. Testing is a process of technical investigation, performed on
behalf of stake holders, that is intended to reveal quality-related information about the product with
respect to the context in which it is intended to operate. This includes, but is not limited to, the process
of executing a program or application with the intent of finding errors. Quality is not an absolute; it
is value to some person. With that in mind, testing can never completely establish the correctness of
arbitrary computer software; testing furnishes a criticism or comparison that compares the state and
behavior of the product against a specification. An important point is that software testing should be
distinguished from the separate discipline of Software Quality Assurance (SQA), which encompasses all
business process areas, not just testing.
There are many approaches to software testing, but effective testing of complex products is essentially a
process of investigation, not merely a matter of creating and following routine procedure. One definition
of testing is ”the process of questioning a product in order to evaluate it”, where the ”questions” are
operations the tester attempts to execute with the product, and the product answers with its behavior
in reaction to the probing of the tester. Although most of the intellectual processes of testing are nearly
identical to that of review or inspection, the word testing is connoted to mean the dynamic analysis of
the product—putting the product through its paces. Some of the common quality attributes include
capability, reliability, efficiency, portability, maintainability, compatibility and usability. A good test is
sometimes described as one which reveals an error; however, more recent thinking suggests that a good
test is one which reveals information of interest to someone who matters within the project community.

In general, software engineers distinguish software faults from software failures. In case of a failure,
the software does not do what the user expects. A fault is a programming error that may or may not
actually manifest as a failure. A fault can also be described as an error in the correctness of the semantic
of a computer program. A fault will become a failure if the exact computation conditions are met, one
of them being that the faulty portion of computer software executes on the CPU. A fault can also turn
into a failure when the software is ported to a different hardware platform or a different compiler, or
when the software gets extended. Software testing is the technical investigation of the product under
test to provide stake holders with quality related information.
Software testing may be viewed as a sub-field of Software Quality Assurance but typically exists
independently (and there may be no SQA areas in some companies). In SQA, software process specialists
and auditors take a broader view on software and its development. They examine and change the software
engineering process itself to reduce the amount of faults that end up in the code or deliver faster.
Regardless of the methods used or level of formality involved the desired result of testing is a level of
confidence in the software so that the organization is confident that the software has an acceptable defect
rate. What constitutes an acceptable defect rate depends on the nature of the software. An arcade video
game designed to simulate flying an airplane would presumably have a much higher tolerance for defects
than software used to control an actual airliner.
A problem with software testing is that the number of defects in a software product can be very large,
and the number of configurations of the product larger still. Bugs that occur infrequently are difficult
to find in testing. A rule of thumb is that a system that is expected to function without faults for a
certain length of time must have already been tested for at least that length of time. This has severe
consequences for projects to write long-lived reliable software.
A common practice of software testing is that it is performed by an independent group of testers after
the functionality is developed but before it is shipped to the customer. This practice often results in the
testing phase being used as project buffer to compensate for project delays. Another practice is to start
software testing at the same moment the project starts and it is a continuous process until the project
finishes.
Another common practice is for test suites to be developed during technical support escalation pro-
cedures. Such tests are then maintained in regression testing suites to ensure that future updates to the
software don’t repeat any of the known mistakes . It is commonly believed that the earlier a defect is
found the cheaper it is to fix it.

Figure 6.1: Performance Table
In counterpoint, some emerging software disciplines such as extreme programming and the agile soft-
ware development movement, adhere to a ”test-driven software development” model. In this process unit
tests are written first, by the programmers (often with pair programming in the extreme programming
methodology). Of course these tests fail initially; as they are expected to. Then as code is written it
passes incrementally larger portions of the test suites. The test suites are continuously updated as new
failure conditions and corner cases are discovered, and they are integrated with any regression tests that
are developed.
Unit tests are maintained along with the rest of the software source code and generally integrated into
the build process (with inherently interactive tests being relegated to a partially manual build acceptance
process).
The software, tools, samples of data input and output, and configurations are all referred to collectively
as a test harness.
The separation of debugging from testing was initially introduced by Glen ford J. Myers in his 1978
book the ”Art of Software Testing”. Although his attention was on breakage testing it illustrated the
desire of the software engineering community to separate fundamental development activities, such as
debugging, from that of verification. Drs. Dave Gelperin and William C. Hetzel classified in 1988 the
phases and goals in software testing as 55 follows: until 1956 it was the debugging oriented period,
where testing was often associated to debugging: there was no clear difference between testing and
debugging. From 1957-1978 there was the demonstration oriented period where debugging and testing
was distinguished now - in this period it was shown, that software satisfies the requirements. The time
between 1979-1982 is announced as the destruction oriented period, where the goal was to find errors.
1983-1987 is classified as the evaluation oriented period: intention here is that during the software life
cycle a product evaluation is provided and measuring quality. From 1988 on it was seen as prevention
oriented period where tests were to demonstrate that software satisfies its specification, to detect faults

and to prevent faults. Dr. Gelperin chaired the IEEE 829-1988 (Test Documentation Standard) with
Dr. Hetzel writing the book ”The Complete Guide of Software Testing”. Both works were pivotal in to
today’s testing culture and remain a consistent source of reference. Dr. Gelperin and Jerry E. Durant
also went on to develop High Impact Inspection Technology that builds upon traditional Inspections but
utilizes a test driven additive.
Online auction enables users to participate in user friendly auction of all the utilities they wish to buy.
Users can bid for their favorite items with ease. This application is developed so as to help the users
to bid for their favorite items by going through all the items available for auction.
There are 2 main modules available in the application:

• Admin Module.
• User Module.
Admin Module:
Admin module does all the tasks that enable the user to bid for an item effortlessly. The following are
the tasks that the admin will take care of:
• Admin will create and update the categories. Under Categories we can find different items that
are up for the auction.
• Admin will take care of all the information regarding the items under each Category.
• Admin will be responsible for all the actions done by the users. Admin can block the users and
can change the privileges of the selected user.
• Admin can delete the categories and can delete the items that are up for the auction.
User Module:
User module is the place where users can register themselves so that they can bid for the items available
and can add items for auction. The following are the features available for the user:
• User can add items to the categories available so that the items can be available for auction.
• User can view all the items that are up for the auction and can bid for any item available.
• User can remove the items owned by him from the auction and can fix an end date for the auction.
Online auction is an effort towards making the auction process transparent and easy to users. Users
can bid for the items available and can add the items for the auction.

Chapter 7
FUTURE ENHANCEMENTS AND

CONCLUSION
7.1 Limitations of the system

The limitations of the system are:
• Only the permanent employees can access the system.
• System works in all platforms and its compatible environments.
• Advanced techniques are not used to check the authorization.
7.2 Future Enhancements

It is not possible to develop a system that makes all the requirements of the user. User requirements
keep changing as the system is being used. Some of the future enhancements that can be done to this
system are:
• As the technology emerges, it is possible to upgrade the system and can be adaptable to desired
environment.
• Because it is based on object-oriented design, any further changes can be easily adaptable.
• Based on the future security issues, security can be improved using emerging technologies.
• sub admin module can be added.
• An in-built web browser can be added.

7.3 Work Done

The “Online Auctioning System” was successfully designed and is tested for accuracy and quality.
During this project we have accomplished all the objectives and this project meets the needs of the
organization. The developed will be used in searching, retrieving and generating information for the
concerned requests.
Goals:
• Reduced entry work.
• Easy retrieval of information.
• Reduced errors due to human intervention.
• User friendly screens to enter the data.
• Portable and flexible for further enhancement.
• Web enabled.
• Fast finding of information requested.

References
1. http://php.net
2. http://tutorialspoint.com
3. www.stackoverflow.com
4. http://w3schools.com

Java

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Java

Загружено:

Авторское право:

Доступные форматы

A PROJECT REPORT

ONLINE AUCTION SYSTEM

Submitted in the fulfillment of the requirement

Under the guidance of

DEPARTMENT OF INFORMATION TECHNOLOGY

Lonere-402103, Tal.-Mangaon, Dist.-Raigad (M.S.) INDIA.

This report entitled Online Auction System submitted by Sachin Loverale(20140728),

Place: Dr. Babasaheb Ambedkar Technological University, Lonere.

2 RESEARCH AND TECHNOLOGY 5

3 ANALYSIS AND DESIGN 10

4 Database Implementation and Interface 23

6 FUTURE ENHANCEMENTS AND CONCLUSION 30

3.1 System Usecase Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 user information table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1 Performance Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Dr.Babasaheb Ambedkar Technological University 1

• Complete Search/Site Map of the entire site for easy access.

• Security and authentication.

Dr.Babasaheb Ambedkar Technological University 2

1.2 Description For Modules

1.2.2 Seller Module

1.2.3 Buyer Module

1.2.4 Visitor Module

1.2.5 Security and Authentication

• Login as buyer or seller or administrator.

• Registration for buyer / seller.

1.3 Goals of the Project

Dr.Babasaheb Ambedkar Technological University 3

1.4 Project Scope

Dr.Babasaheb Ambedkar Technological University 4

RESEARCH AND TECHNOLOGY

2.1.1 Existing System

Dr.Babasaheb Ambedkar Technological University 5

2.1.2 Proposed System

• Complete Search/Site Map of the entire site for easy access.

2.2 Technology Description

HYPER TEXT MARKUP LANGUAGE

Dr.Babasaheb Ambedkar Technological University 6

• HTML is platform independent.

• HTML tags are not case-sensitive.

Dr.Babasaheb Ambedkar Technological University 7

Why Use Bootstrap?

• JavaScript can be used for Sever-side and Client-side scripting.

• It is more flexible than VBScript.

2.2.5 Apache Web Server(XAMPP)

Dr.Babasaheb Ambedkar Technological University 8

Dr.Babasaheb Ambedkar Technological University 9

ANALYSIS AND DESIGN

3.1 Requirement analysis

• Admin can have access in the bid page.

• Users can look for a product from a selected category.

Dr.Babasaheb Ambedkar Technological University 10

• Users can edit their profiles.

3.2 Use case Diagram

3.2.1 Structural model view

3.2.2 Behavioral model view

3.2.3 Implementation Model View

3.2.4 Environmental Model View

Dr.Babasaheb Ambedkar Technological University 11

Figure 3.1: System Usecase Diagram

Dr.Babasaheb Ambedkar Technological University 12

Figure 3.2: ER Diagram

Dr.Babasaheb Ambedkar Technological University 13

3.4 Class Diagram