Internet-Based Bidding Design

Published on May 2016 | Categories: Documents | Downloads: 44 | Comments: 0 | Views: 237
of 7
Download PDF   Embed   Report

Comments

Content

Software Project Management (CS 800) Mini Project Phase 2: Design Prepared by Arijit Mallik (leader) Murali K Anirban Chakraborty 12CS05F 12CS14F 12CS04F

Title: Internet Based Bidding System

Course: Branch: Semester:

M.Tech CSE I

Page 1 of 7

1. Introduction
The Internet Bidding System is a flexible solution for supporting product-specific online auction. The system has been designed to be well responsive, consistent across multiple transactions, maintainable and portable. The Internet Bidding System lets the users to either upload an item for auction or easily browse the items and place bids using a secure server. Our design document intends to depict the system through suitable diagrams.

2. System overview
This part gives a general description of all the possible actors involved in the system with their functions depicted in the following simple use-case diagrams.

2.1.

Admin use-case
View users

Backup database Admin Cleanup database

Approve items for bidding

2.2.

Buyer/Seller use-case
Register/Login

View profile

Customer

Search and/or bid /Upload item

Page 2 of 7

3. Architecture Diagram

4. Database Design 4.1. ER Diagram

Page 3 of 7

4.2.

Table Description

Table name: User Description: This table contains the details of all kinds of users who use this web application. Primary Key: email Index: email Attribute Data Type Description Name userid VARCHAR(9) User id shall be of length 9 and of the form USRxxxxxx starting from USR000001 to USR999999. Use auto generator for this in form of trigger. This user id is for reference in the database only and not exposed to the users. This attribute should be unique throughout the table. VARCHAR(30) This shall contain the first name, middle name and last name of the user. VARCHAR(30) Valid authenticated email id of the user VARCHAR(30) Encrypted password of the user. VARCHAR(2) usertype=AD for administrator usertype=UR for bidders/sellers BOOLEAN Isvalid = False till the email id of user is verified after registation. This is checked while user login.

name email password usertype isvalid

Table 1: User Table

Table name: Bid Description: This table contains the bid details for an item. One instance of this object is created for each new bid performed by the bidders to maintain the bid history. Primary Key: bidid, userid, auctioned Attribute Name bidid userid auctionid price timestamp Data Type VARCHAR(9) Foreign Key Foreign Key Double DATE Description User id shall be of length 9 and of the form BIDxxxxxx starting from BID000001 to BID999999. Foreign key referenced from the user table Foreign key referenced from the Auction table Bid price corresponding to the new bid Time at which this instance of bid was made. Time stamp is applied even before locking is done to ensure accuracy.

Table 2: Bid Table

Table name: Auction Description: This table contains the auction details of an item submitted for sail. One instance of this object is created for each new item which the seller posts on the website. One auction instance can have n instances of Bid bid instance. Primary Key: auctionid, userid Index: Primary index should be on category and secondary index should be on item name to ensure good response time and also to allow hierarchical search based on category. Page 4 of 7

Attribute Name auctionid userid

Data Type VARCHAR(9) VARCHAR(9)

Description User id shall be of length 9 and of the form AUCxxxxxx starting from AUC000001 to AUC999999. Foreign key from user table. User who is intending to sell this item. Name of the item Category to which the item belongs to.

item_name VARCHAR(30) item_categ VARCHAR(30) ory

description VARCHAR(100) Brief description of the item like any warranty, usage details etc... Image_pat VARCHAR(100) Image files are to be stored in the file system and not in the DB for hs simplicity and also to reduce the size of database. Path of the uploaded image will be stored in the database in form <path1>:<path2>:...:<pathN> start_time exp_time DATE DATE Time at which the bid must start. Time at which the bid must end. The time shall be in increments of 30 min. Time like 11:45 is invalid. This is done inorder to ensure the invalidation of item using a script run for every 30 min in the back end database. Status =True if the item is available for bidding and the expiration time is not yet over. Minimum bid amount to qualify a new bid. Set bu the seller/administrator. Initial bid amount set by the seller. To ensure consistency in care of concurrent bidding for the same item.

status increment

BOOLEAN DOUBLE

start_price DOUBLE islocked BOOLEAN
Table 3: Auction Table

4.3.

Data Connection Pooling

An array with pool of connection must be maintained in order to ensure good response time. For a new request instead of creating a connection to DB, a connection is picked from the pool and used. Connection is put back into pool after use. A minimum number of free connection objects must be maintained in the pool using algorithm below.

5. Feature Design
The three important aspects considered for the design are security, maintainability and concurrency. Concurrency problems are avoided by using locking mechanism for any updates. Maintainability should be ensured at the implementation level by using frameworks like myBatis/Hibernate/Spring. Using myBatis provides a good MVC architecture. However the need for a push mechanism restricts us to use the Hibernate framework. Finally security is a major problem which has be taken care to a possible extent by email verification to allow only authenticated users. Also security of the user account can be ensured from intruders by allowing at most 3 continuous login attempts. If the third attempt fails then an email should be triggered to the user and the account should be disabled. User can re-activate the account by using a link

Page 5 of 7

which should be part of the mail sent. This feature can be implemented by using the isvalid field in the user table. Following activity diagrams explain the major functionalities of the system.

5.1.

Registration

5.2.

Login

5.3.

Closing Auction

In our model, the auction is database driven. Rather than having a running program continually check the time in order to terminate the auction, our auction terminates in response to bidder activity. This means that every time a bidder requests the item details, a script is run to check whether the auction has terminated according to the database clock. Also the same script is run for every interval of 30 minutes in order to invalidate all the
Page 6 of 7

auctions which have met the expiration time. This mandates the requirement at the implementation level to allow the sellers to set expiration time only in increments of 30 minutes starting from 0 hours. The payment is made on delivery. This approach is proposed because implementing online payment requires the application to interact with the bank gateways which requires permission from the respective Banks.

5.4.

Bidding Process

6. Future Enhancement
The system can be connected to a bank payment gateway to support online payment for an item and also reduce the fraud of the seller creating multiple login accounts to increase the bid.
Page 7 of 7

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