Realtime Commercial Bidding System Team 6 Brenda Harvey John Johnston Jason LaBumbard Peter Tirrell

Provides realtime bidding capabilities Motivation for project –Strong market demand for e-commerce systems –Few existing B-2-B commodities brokerages –Low market pricing means automation needed –System fills a market niche and does so cost effectively Realtime Commercial Bidding System

Overview of Features Standard and reverse auctions Realtime bidding and viewing Self-serve auction setup Administrator Distributed “auctioneer” attributes & operations Account management functions Combined account functionality

Overview of Features continued… Users may participate in multiple auctions Forgotten password retrieval “On the fly” account setup

Prototype Login screen –Existing and new users Auction list view/select Join, bid in, and view an auction –Bid history, withdrawing Client-side view of reverse auction

Login Screen

Auction Information Screen

Regular Auction Screen

Regular Auction Screen 2

Regular Auction Finished

Withdrawing a Bid

Auction Information Screen 2

Reverse Auction Screen

Reverse Auction Finished

Create Auction Screen

Grey Areas What is an “Auctioneer?” –Automated piece of code –One approach: handle as distinct class –Second approach: divide functionality to other classes Why an “Administrator?” – Can all site maintenance be automated? – What can be handled by auctioneer or user account functions and what cannot?

How Problems Were Solved Auctioneer –Logically divide auctioneer data and functions into auction and user account classes –Avoid redundancy and simplify design Site Administration –Create an administrator class –Administrator basically a special type of user account

Description of Class Model Aggregated under “Realtime Auction Site” Makes use of “Administrator” Abstract classes:“Auction” User account aggregated for client and bidders Client side: login, sign-up, get password Auctioneer attributes and functionality distributed among several classes

Class Model

Sequence Diagrams Generalized overall sequence diagram –Many possible object interactions –Not a single stepwise progression of events –Most possible interactions presented Use specific sequence diagrams –Depict major interaction scenarios –Single stepwise progression of events –Ack used to denote acknowledgement of messages

Sequence Diagram

Bidding in a Standard Auction

Bidding in a Reverse Auction

Setting up a Reverse Auction

Setting up a Standard Auction

Use Case Diagrams Generalized use case diagram –Many possible actor/activity interactions –Actors include bidder, client, and administrator Specific use case diagrams –Client interactions w/ in progress auctions –Setting up an auction –Bidder auction participation scenarios

Main Use Case Diagram

Seller Use Case Diagram

Bidder Use Case Diagram

State Diagrams Used to show possible states of major objects Administrator state diagram –Fail-safe site intervention capabilities Auction state diagram –Describes progression of auction behavior User state diagram –Describes user interaction in realtime User account state diagram –“On the fly” account maintenance

Administrator State Diagram

Auction State Diagram

User State Diagram

User Account State Diagram

Critical System Properties Summary of critical system properties –No distinct auctioneer class –Administrator –One user account, both client and bidder capabilities –Self-serve account maintenance –Auction abstract class and inheritance –Client-side functionality

Promela and XSpin Analysis of two client-supplied state diagrams –Performed initial visual analysis of diagrams –Coded state machines in promela –Developed basic test case scenarios Future work –LTL –Additional scenario analyses

Client State Diagram Spin Analysis –Issue of “end_auction” signal in any state other than Idle results in deadlock –Failure of auctioneer to send “bidok” results in deadlock in User_Bid state –Dropped bids on timeout Non-Spin Analysis –No “bid-not-ok” signal (timeout?) –What happens when client bid is not high bid?