online Auction

Published on November 2016 | Categories: Documents | Downloads: 38 | Comments: 0 | Views: 301
of 17
Download PDF   Embed   Report

Comments

Content

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 selforganizing, 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.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close