[CSE IIT Kanpur] INTERNET AUCTIONING SYSTEM Final Project Report Group 9 Hemraj Bairwa Y5195, Hitesh Khandelwal Y5202, Varun Mithal Y5496 Guide: Dr. T. V. Prabhakar [2008]
Internet Auctioning Aim: To meet the requirements for an online auctioning system. Motivation: As we are in final year so we realized the need to sell several items next semester like our Computers, Bicycles, cell phones and other utilities which cannot be disposed. Newsgroups and informal communication has been the norm till date however it would be of use to make a system that can be deployed and used with little supervision and maintainence. Introduction: Precise Problem Statement: An online auction server which allows a person to place an advertisement for an item for sale online and buyers will bid for them. The buyers 'view' the items on the server, and if they want to bid for it, they need to have a client to lodge a bid. The server then notifies other potential buyers of the received bid, so that they can bid against it. If no further bids are received in a given time after the last bid, the server notifies all the potential buyers that the sale is finalized. Salient features of an online auctioning system. 1) A platform where people can search for products they intend to buy. 2) The products should have a profile that shows the details. 3) Sellers should be able to add their products to existing list. 4) Potential buyers can bid for an item. 5) Security: password mechanism has been used to prevent unauthorized access. 6) Administrator can manage user and product profiles.
ARCHITECTURAL REPRESENTATION The 4 + 1 view is used for depicting the various views. The description of the architecture can be organized around these four views, and then illustrated by a few selected use cases, or scenarios which become a fifth view. Use Case Scenario: Use case describes the interaction between the end user and the system. This view describes the functionalities of the system as seen by the end user. This view in a way describes the aim of the system the rest of the views try to realize these end functionalities. The main actors in this system are the user, administrators and the product catalogue. The following diagrams describe the various use cases describing the various events observable to the actors.
Logical View: This view of software is comprised of Products, Administrator, User modules. These modules interact with one another. Process View: This view explains how main modules interact. For example, administrator uses manage functionality to delete user and product profiles. User uses search and bid functionalities to bid for a product and uses sell functionality for advertising products.
Development View: We first built modules User, Products, Admin. Given the use case scenario in the problem statement, we implemented their relationships, for example User needs to register first for using the software. User needs search functionality to find product of his/her choice and then bidding functionality to bid for it. User also needs sell functionality to advertise for his/her product. Admin needs to have manage functionality for maintaining the product and user profiles. Physical View: This view is layered architecture. Software runs on top of web server and database server which again run on same or different operating systems.
Detailed Description of modules: User User Information Modify Information Sell a product Products on sale Current Bids Past purchases/sale Notifications Administrator Delete products Delete user This involves functions like sign up, login, user profile. The user will have access to his bids and products he has put on sale. He can modify any information related to him. Product Description Seller Starting bid price/current/step size location Deadline Active/Closed This involves functions like ability to add a product, product profile display. Images can be uploaded. A description of the product to help buyers make a better decision.
Search Search from product list using keyword and can be applied to specific category. A listing of every item in a particular category can also be obtained. flexibility in search as we have implemented partial substring match based search. Bidding Registered user can bid for a particular product. It checks if the new bid is valid or not. Valid bid implies it is more than the sum of current bid and minimum bid increment. Also no bid id allowed after the deadline. Features like minimum bid, bid increment size are also available. Appropriate notification is sent to the seller and bidders about any new bid. Deployment The system is uploaded on the webspace of a group member. Next semester we intend to make it public and use it for selling of items by graduating batch. This also involves spreading of awareness about the site. Maintenance Like TorrentCore or DC++, this project needs maintainance as well as vigillance. So a team to monitor its functioning will be needed every year. REFERENCES Architectural Blueprints The 4+1 View Model of Software Architecture, Philippe Kruchten Rational Software Corp.Sommerville, Ian. Software Engineering, 8th ed. New York. Addison Wesley.