ABSTRACT

Objective.

To build an on-line auction website which provides a trading community to buy and sell products
on-line. This site also makes sure that sellers get a fair price and buyers get a genuine product.

Existing System.

• The problem with public auction is that the participation of the general public is very limited.

• This public auction is managed manually and involves lot of paper work.

• Prior to each auction, the day of auction, the venue and the items on auction are announced through news
media. Those who wish to take part in the auction have to arrive at the venue on that day on time. This
conventional method most of the times prevent aspiring bidders from participating in the bidding process.

• Another headache of the old system is to track each bidding process and to make it culminate in financial
settlement. So the system has to keep records of both buyers and sellers until the end of settlement. The
process is very cumbersome and time consuming.

Proposed System.

The proposed system is an on-line auction web site aimed at taking the auction to the finger tips of
aspiring bidders. This site also acts as an open forum where buyers and sellers can come together and exchange
their products. The salient features of this site are
Paperless Auction System.
Easy to access.
Accessible to everyone at anytime no matter where they are.
Reliable user validation and checking.
easy on-line settlement.

Modules.
An online auction system is built up with the modules mentioned below.
Web Administrator
Auction manager
Bidder
Seller
Buyer
 INTRODUCTION

Description of Project.
In the past few years, the electronic marketplace has witnessed an exponential growth in worth,
size, and usability. Projections indicate that this trend will intensify in the coming years [1]. With the help of the
fast-growing Internet environment, the products that were previously purchased in a traditional market (i.e.,
Brick-and-Mortar) can be obtained conveniently via online auction systems. Online auctions are a major
component of the electronic marketplace that makes use of electronic commerce mechanisms.
An online auction system is aimed at taking the auction to the finger tips of aspiring bidders and
sellers in a user friendly way. They can take part in the auction just sitting in the comfort of their living room, be
it during the day or night. The only pre-condition for anyone willing to participate in the auction process is that
he/she must register and authenticate himself before the auction process. In the registration process user has to
provide his details like username, password, email id, location etc. Then after registering, a verification of the
email id is done therefore activating the user's account. There are three modules in the auction website as follows
1.Web Administrator
2.Auction manager
3.Bidder
4.Seller
5.Buyer
Before accessing the site the registered user has to login to the site by providing the username and
password given to him. After logging in the user will be displayed with homepage which has a navigational
menu at the top which links to various linner pages and the center of the homepage will have list of latest
products available for bidding in their chronological order. The web administrator will add product categories
under which the sellers will add their products according to the category to which the product is related. Sellers
must provide the product information like starting bid amount, product name, and product details while adding
the product. The closing date of the bidding for each product is given by the the auction manager. Now every
user will be displayed with a list of categories of products. On clicking a category, the list of products belonging
to that category is displayed. Now the bidder can select the product of his interest and start bidding. The bid
amount given by the bidder must be greater than or equal to the starting bid amount given by the seller. After the
bidding process system will place the record in the bidding history against the bidder acount as well as the
product bids. Many bidders bid on the same product and a single bidder can bid on the same product a number of
times. After the closing date of bidding, the bidder who has given the largest bid amount is selected as buyer and
the product is sold to him by the seller after the payment of product. After getting the payment from the buyer,
the seller will give feedback to the bidder . Shipping cost as well as the bid amount is paid by the buyer thorugh
paypal or credit card. The auction manager processes the whole transaction by contacting the buyer and seller
through email instructing them to settle the transaction within a given time frame. After the whole process of
auction the buyer will give a feedback to the seller. The auction manager allots points to the seller and buyer
who recieves feedback. The higher the point total, the more experienced or trustworthy are the seller and the
buyer is.

Description of Modules.
Every user in order to access the website and participate in the auction process, has to login to the system with
his respective login id and password. The user credentials will be validated before logging him to the system.

1.Web administrator :
The system ensures high security, business integrity and confidentiality through full information log
on to the system by the administrator.The administrator has to login to the system with his user-id and password
inorder to perform his responibilities. The responsibilities of the web administrator are as follows
• Manage the users of the system like seller, bidder, buyer, auction manager.
• Manage the fraud data, if admin detects any fraud data entered by any user then he can block those users
from accessing the site.
 • Add categories for the products.
• View transaction reports.
• View auction process details.

2.Auction manager.
An auction manager has access to the whole process of auction. The auction manager has the
following responsibilities.
• Edit the product details like closing date of bidding for the product.
• Get the detailed product information from the seller.
• Manage the bidding history of a product
• Select the bidder to whom the product must be sold.
• Process the transaction by contacting the buyer and seller through e-mail
• Settle the transaction within a time frame
• Give points to the buyer and the seller after receiving feedback.
3.Bidder.
The bidder is the person who participates in the bidding of a product. The bidder have access to
only few functionalities listed below and is restricted from other functionalities depending on the system.
• View his profile
• Edit his account details
• View his bidding history
• View the products in the website
• Select the product for bidding.
• View the points of seller.
• Can bid any number of times on a single product.
• The bid amount given by the bidder must be greater than or equal to the starting bid amount given by the
seller.
• View FAQ
• Ask questions to the seller of product.
• View his answers given by the seller.

4.Seller :
The seller can sell his products through the auction website in a easier way. He can perform the
following actions.
• View and edit his accuount details.
• Register products for auction.
• Registrations need payment from the seller. He can pay through credit card or paypal account to the
website.
• Select category under which he needs to add products.
• Add product information like product name, product details, starting bid amount , shipping cost involved
and also upload image for the product.
• View bidding history of the product.
• View bidding history of bidder
• Answer to the questions of bidder.
• Contact the buyer though email for further transactions.
• Contact the auction manager through email regarding the problems in the auction.
• Deliver the product to the buyer after getting the payment for the product.
• Give feedback to the buyer after getting the payment.
5.Buyer :
Buyer is the bidder who gave the largest bidding amount for a prodcut. He can perform all the
actions of a bidder as well as the following ones
• Pay for the product through paypal or credit card including the shipping cost of the product.
• Give details of himself to the seller so that the seller can deliver the product.
• Give feedback to the seller after receiving the product.

LITERATURE SURVEY
Software Engineering Concepts :

Agile software development model :

Agile software development is a group of software development methodologies based on iterative
and incremental development, where requirements and solutions evolve through collaboration between self-
organizing, cross-functional-teams.

Agile software development is a conceptual framework for software engineering that promotes iterations
throughout the life-cycle of the project. There are many agile agile development methods; most minimizing risk
by developing software in short amounts of time. Sofware developed during one unti of time is considered as an
iteration, which may last from one week to four weeks. Each iteration is an entire software project: including
planning,requirements analysis,desing,coding,testing and documentation. Some of the principles behind agile
manifesto are
• Customer satisfaction by rapid, continuous delivery of useful software
• Working software is delivered frequently(weeks rather than months)
 • Even late changes in requirements are welcomed
• close,daily cooperation between business people and developers
• face-to-face conversation is the best form of communication
• projects are built around motivated individuals, who should be trusted
• continuous attention to technical excellence and good design
• simplicity
• self-organizing teams
• regular adaptation to changing circumstances

Agile methods have much in common with the “Rapid Application Development” techniques.
Some of the well known agile sofware development methods :
• Agile Modelling
• Agile Unified Process
• Agile Data Method
• Short release cycles
• Responsive Development
• Test-driven Development
• Feature Driven development
• Essential Unified process

We will be using the Test-driven Development method for our case study.

Test Driven Development :

Test driven development (TDD) is a software development technique consisting of short iterations
where new test cases covering the desired improvement or new functionality are written first then the production
code necessary to pass the tests is implemented, and finally the software is refactored to accommodate changes.
The availability of tests before actual development ensures rapid feedback after any change. Practitioners
emphasize that test-driven development is a method of designing software, not merely a method of testing.

Test Driven Development Cycle :

Test-driven development (TDD) is a software development process that relies on the repetition of a
very short development cycle: first the developer writes a failing automated test case that defines a desired
improvement or new function, then produces code to pass that test and finally refactors the new code to
acceptable standards. Test-driven development is related to the test-first programming concepts of extreme
programming.

Requirements :
Test-driven development requires developers to create automated unit tests that define code
requirements (immediately) before writing the code itself. The tests contain assertions that are either true or
false. Passing the tests confirms correct behavior as developers evolve and refactor the code. Developers often
use testing frameworks, such as xUnit, to create and automatically run sets of test cases.

Test-Driven Development Cycle :

The following is the sequences of life cycle process of test-driven development.
• Add a test
• Run all the tests and see the new one fail
• Write some code
• Run the automated tests and see them succeed
• Refactor the code.
1.Add a test.
In test-driven development, each new feature begins with writing a test. This test must inevitably
fail because it is written before the feature has been implemented. (If it does not fail, then either the proposed
“new” feature already exists or the test is defective.) To write a test, the developer must clearly understand the
feature's specification and requirements. The developer can accomplish this through use cases and user stories
that cover the requirements and exception conditions. This could also imply a variant, or modification of an
existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is
written: it makes the developer focus on the requirements before writing the code, a subtle but important
difference.

2.Run all the tests and see the new one fail.
This validates that the test harness is working correctly and that the new test does not mistakenly
pass without requiring any new code. This step also tests the test itself, in the negative: it rules out the possibility
that the new test will always pass, and therefore be worthless. The new test should also fail for the expected
reason. This increases confidence (although it does not entirely guarantee) that it is testing the right thing, and
will pass only in intended cases.
3.Write some code.
The next step is to write some code that will cause the test to pass. The new code written at this
stage will not be perfect and may, for example, pass the test in an inelegant way. That is acceptable because later
steps will improve and hone it. It is important that the code written is only designed to pass the test; no further
(and therefore untested) functionality should be predicted and 'allowed for' at any stage.

4.Run the automated tests and see them succeed.

If all test cases now pass, the programmer can be confident that the code meets all the tested
requirements. This is a good point from which to begin the final step of the cycle.

5.Refactor.
Now the code can be cleaned up as necessary. By re-running the test cases, the developer can be
confident that refactoring is not damaging any existing functionality. The concept of removing duplication is an
important aspect of any software design. In this case, however, it also applies to removing any duplication
between the test code and the production code.

Repeat
Starting with another new test, the cycle is then repeated to push forward the functionality. The size
of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not
rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to
excessive debuggin..Continuous Integration helps by providing revertible checkpoints. When using external
libraries it is important not to make increments that are so small as to be effectively merely testing the library
itself, unless there is some reason to believe that the library is buggy or is not sufficiently feature-complete to
serve all the needs of the main program being written.

UML DESCRIPTION :
As UML describes the real time systems it is very important to make a conceptual model and then
proceed gradually. Conceptual model of UML can be mastered by learning the following three major elements:
• UML Building blocks
• Rules to connect the building blocks
• Common mechanisms of UML.

The building blocks of uml can be defined as

• Things
• Relationships
• Diagrams
1.Things.
Things are the most important building blocks of UML. Things can be:
• Structural
• Behavioural
• Grouping
• Annotational

Structural Things.
The Structural things define the static part of the model. They represent physical and conceptual
elements. Following are the brief descriptions of the structural things.
Class.
Class represents set of objects having similar responsibilities.

Interface.
Interface defines a set of operations which specify the responsibility of a class.

Collaboration.
Collaboration defines interaction between elements.

Use case.
Use case represents a set of actions performed by a system for a specific goal.

Component.
Component describes physical part of a system.

Node.
A node can be defined as a physical element that exists at run time.
Behavioral Things.
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things:

Interaction.
Interaction is defined as a behavior that consists of a group of messages exchanged among elements to
accomplish a specific task.

State machine.
State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states
an object goes through in response to events. Events are external factors responsible for state change.

Grouping Things.
Grouping things can be defined as a mechanism to group elements of a UML model together.
There is only one grouping thing available:

Package.
Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational Things.
Annotational things can be defined as a mechanism to capture remarks, descriptions, and
comments of UML model elements. Note is the only one Annotational thing available.

Note.
A note is used to render comments, constraints etc of an UML element.
2.Relationship.
Relationship is another most important building block of UML. It shows how elements are
associated with each other and this association describes the functionality of an application. There are four kinds
of relationships available.

Dependency.
Dependency is a relationship between two things in which change in one element also affects the other one.

Association.
Association is basically a set of links that connects elements of an UML model. It also describes how many
objects are taking part in that relationship.

Generalization.
Generalization can be defined as a relationship which connects a specialized element with a generalized element.
It basically describes inheritance relationship in the world of objects.

Realization.
Realization can be defined as a relationship in which two elements are connected. One element describes some
responsibility which is not implemented and the other one implements them. This relationship exists in case of
interfaces.

3.UML Diagrams.
UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are
used to make a complete UML diagram and the diagram represents a system. The visual effect of the UML
diagram is the most important part of the entire process. All the other elements are used to make it a complete
one. UML includes the following nine diagrams and the details are described in the following.
1.Class Diagram
2.Object diagram
3.Use case diagram
4.Sequence diagram
5.Collaboration diagram
6.Activity Diagram
7.State chart diagram
8.deployment diagram
9.Component diagram.
1.Class Diagram.
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of
static structure diagram that describes the structure of a system by showing the system's classes, their attributes,
and the relationships between the classes.
The upper part holds the name of the class
The middle part contains the attributes of the class

The bottom part gives the methods or operations the class can take or undertake.

2.Object Diagram.
Object diagrams describe the static structure of a system at a particular time. They can be used to
test class diagrams for accuracy.

3.Use case Diagram.

A use case diagram in the unified modelling language is a type of behavioral diagram defined by
and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided
by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use
cases. The main purpose of a use case diagram is to show what system functions are performed for which actor.
Roles of the actors in the system can be depicted.
4.Sequence Diagram.
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram that
shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart.
Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams.
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that
live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they
occur. This allows the specification of simple runtime scenarios in a graphical manner.

5.Collaboration Diagram.
A collaboration diagram is an interaction diagram that emphasizes the structural organization of the
objects that send and receive messages.
They show the relationship between objects and the order of messages passed between them. The
objects are listed as icons and arrows indicate the messages being passed between them. The numbers next to the
messages are called sequence numbers as the name suggests, they show the sequence of the messages as they are
passed between the objects.

6.Activity diagram.
Activity diagrams are graphical representations of workflows of stepwise activities and actions with
support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used
to describe the business and operational step-by-step workflows of components in a system. An activity diagram
shows the overall flow of control.
7.State chart diagram.
A state chart diagram is a type of diagram used in computer science and related fields to describe
the behavior of systems. State diagrams require that the system described is composed of a finite number
of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. There are many
forms of state diagrams, which differ slightly and have different semantics.

8.Deployment Diagram.
A deployment diagram displays the configuration of run time processing elements and the software
components. Processes and objects that live on them. Software component instances represent run time
manifestations of code units.

9.Component Diagram.
A component diagram shows the organization and dependencies among a set of components.
Component diagram displays the high level packaged structure of the code itself. Dependencies among
components are shown including source code components, binary code components, and executable
components. Some components exist at compile time, at link time, at run time well as at more than one time.
 TECHNOLOGY OVERVIEW
RUBY AND RUBY ON RAILS.

Ruby.
Ruby and ruby on rails are often mentioned in the same breath, and it is easy to think that they are
one and the same. Ruby is simply a programming language much like perl, PHP or java. Ruby is completely
object-oriented, meaning that everything in ruby is an object—there are no primitives. Also, ruby is a dynamic
language, which basically means that programs written in ruby can change their structure as they are run. Ruby
is dynamically typed: varialbles are not restricted to a particular type; they can change types during the execution
of the application. Ruby was concieved and developed by Yukihiro “Matz” Matsumoto and first released to the
public in 1995. Ruby is not only used for developing web applications but also for system administration tasks
and tool development. The standard libraries and increasingly extensive third party libraries allow you to quickly
develop scripts, tools, and applications. There are ruby frameworks for developing desktop applications too.

Rails.
Rails is a framework in which applications are written in ruby. Rails is all aboout individuals and
interactions. There are no heavy tool sets, no complex configurations, and no elaborate processes. Rails assumes
a certain rubtime directory layout. The following are the top level directories of rails application.

app/ and test/ : Most of our work takes place in the app and test directories. The main code for the application
lives below the app directory. Unit, functional and integration tests , fixtures all are placed below test directory.

doc/ : The doc directory is used for application documentation. It is produced using RDoc. If u run rake doc:app,
you will end up with html documentation in the directory doc/app.

lib/ : The lib directry holds application code that doesn't fit neatly into a model, view or controller. The lib
directory is also good place to put code that is shared among models, views or controllers. Once you have files in
the lib directory, you use them in the rest of your application.

Rake tasks : we'll also find an empty tasks directory under lib. This is where we can write our own rake tasks,
allowing we to add automation to our project.

db/ : This directory contains all the schema and migration information.

log/ : As rails runs, it produces a bunch of useful information. This is stored in the log directory by default. Here
we can find three main log files development.log, test.log, and production.log. The logs contain more than just
simple trace lines;they also contain timing statistics, cache information, and expansions of the database
statements exceuted.

Public/ : The public directory is the external face of our application. The web server takes this directry as the
base of the application. Much of the deployment configuration takes place here.

Script/ : The script directory holds programs that are useful for the developers. Run most of these scripts with
no arguments to get usage information.
-about : displays the version numbers of ruby and the rails components being used by our application, along with
other configuration information.
-console : allows you to use irb to interact with our rails application methods.
-break pointer : a client lets you interact with running rails application.
-destroy : removes autogenerated files created by generate.
-plugin : the plugin script helps you to install and administer plugins.
-server : the server script runs our application in a self contained web server, using mongrel, lightTPD, or
WEBrick.
tmp/ : this has the rails's temporary files. We can find subdirectories of caches, sessions, and sockets here.
vendor/ : the vendor directory is where third-party code lives. Rails installs plugins into the vendor/plugins
directory.

Ruby on Rails.
Ruby on rails is simply a set of libraries and tools written in ruby to allow rapid development of
web applications. This package of tools is known as a framework. This is an open source framework.David
Heinemeier Hansson is the brain behind Ruby on Rails. Ruby on Rails is simply called a Rails. Rails follows the
design philosophy of ruby, in that it focuses on making our life as a web developer easy and happy. Rails has a
couple of main design principles that help achieve these goals: don't repeat yoursel (DRY) and convention over
configuration. DRY is self-explanatory. If you have defined something once, you need not define it anywhere
else. For instance, once you have defined the column names in a database schema, you need not have to repeat
them else where in your code. This reduces the amount of work and prevents inconsistencies in the code. Rails
implements MVC architecture.

Browser controller

view model db

Models, Views, And Controllers.

Back in 1979, Trygve Reenskaug came up with a new architecture for developing interactive
applications. In his design, applications were broken into three types of components: models, views, and
controllers.
The model is responsible for maintaining the state of the application. Some times this state is
transient, lasting for just a couple of interactions with the user. Sometimes the state is permanent and will be
stored outside the application, often in a database. A model is more than just data; it enforces all the business
rules that apply to that data. For example, if a discount shouldn’t be applied to orders of less than $20, the model
will enforce the constraint. This makes sense; by putting the implementation of these business rules in the model,
we make sure that nothing else in the application can make our data invalid. The model acts as both a gatekeeper
and a data store.
The view is responsible for generating a user interface, normally based on data in the model. For
example, an online store will have a list of products to be displayed on a catalog screen. This list will be
accessible via the model, but it will be a view that accesses the list from the model and formats it for the end
user. Although the view may present the user with various ways of inputting data, the view itself never handles
incoming data. The view’s work is done once the data is displayed. There may well be many views that access
the same model data, often for different purposes.
Controllers orchestrate the application. Controllers receive events from the outside world (normally
user input), interact with the model, and display an appropriate view to the user.

This triumvirate—the model, view, and controller—together form an architecture known as MVC.
The above figure shows MVC in abstract terms. MVC was originally intended for conventional GUI
applications, where developers found the separation of concerns led to far less coupling, which in turn made the
code easier to write and maintain. Each concept or action was expressed in just one well-known place. Using
MVC was like constructing a skyscraper with the girders already in place—it was a lot easier to hang the rest of
the pieces with a structure already there. In the software world, we often ignore good ideas from the past as we
rush headlong to meet the future. When developers first started producing web applications, they went back to
writing monolithic programs that intermixed presentation, database access, business logic, and event handling in
one big ball of code. But ideas from the past slowly crept back in, and folks started experimenting with
architectures for web applications that mirrored the 20- year-old ideas in MVC. The results were frameworks
such as WebObjects, Struts, and JavaServer Faces. All are based (with varying degrees of fidelity) on the ideas
of MVC.
Ruby on Rails is an MVC framework, too. Rails enforces a structure for your application—you
develop models, views, and controllers as separate chunks of functionality and it knits them all together as your
program executes. One of the joys of Rails is that this knitting process is based on the use of intelligent defaults
so that you typically don’t need to write any external configuration metadata to make it all work. This is an
example of the Rails philosophy of favoring convention over configuration. In a Rails application, incoming
requests are first sent to a router, which works out where in the application the request should be sent and how
the request itself should be parsed. Ultimately, this phase identifies a particular method (called an action in Rails
parlance) somewhere in the controller code. The action might look at data in the request itself, it might interact
with the model, and it might cause other actions to be invoked. Eventually the action prepares information for
the view, which renders something to the user.

Active Record : Rails Model Support.

In general, we’ll want our web applications to keep their information in a relational database.
Order-entry systems will store orders, line items, and customer details in database tables. Even applications that
normally use unstructured text, such as weblogs and news sites, often use databases as their backend data store.
Although it might not be immediately apparent from the SQL2 you use to access them, relational databases are
actually designed around mathematical set theory. Although this is good from a conceptual point of view, it
makes it difficult to combine relational databases with object-oriented programming languages. Objects are all
about data and operations, and databases are all about sets of values. Operations that are easy to express in
relational terms are sometimes difficult to code in an OO system. The reverse is also true.