ELECTRONIC TRADING ONLINE

Amarnath Mullick : ME(CSE) : 4710-411-021-02225

Sourabh Kumar Verma : ME(CSE) : 4710-411-021-02223

Requirement Analysis

ELECTRON is a ELECtronic TRading Online, a rendezvous for buying agents and selling agents to meet and transact business and commerce. It supports a large number of business models and trade determination algorithm.

Whenever a seller registers with ELECTRON and provides information on the product(s) he would like to sell and chooses a business model. As soon as the seller registers, ELECTRON will do certain things like matching him to potential buyers, aggregating him to other potential sellers, etc, as entailed by the business model.

Similarly, when a buyer registers with ELECTRON, she provides information on the product(s) she would like to buy, and also chooses a business model (eg Reverse Auction) and ELECTRON matches her to potential sellers, aggregates her to other potential buyers, etc, as entailed by the business model.

A trade is said to happen when buyer(s) and seller(s) participate and negotiate according to a chosen business model. The trade determines the winner(s). The winning buyer(s) make the payment electronically and securely to the seller(s).

Use Case Model

We capture the functionality of the system through the use cases.

Actors:

1)Trader (Buyer/Seller)

2)Auction Monitor

3) System

Use Cases:

1) Register

2) Buyer Register

3) Seller Register

4) Login

5) Logout

6) Describe Product

7) Setup Trade

8) Join Trade

9) Join Trade as Seller

10) Join Trade as Buyer

11) Query

12) Modify Trade

13) Close Trade

14) Cancel Trade

In the Use Case Model, we model the Buyer and the Seller, almost identically, eg., a seller can bid or a buyer can set up a trade, so that we can also support business models like reverse auction.

Figure 1 Use Case Diagram

USER LOGIN Use Case

· Main Flow

1. A trader chooses to log in

2. System provides login page

3. Trader provides login name and password (E1)

4. System validates information

· Altenate Flow

1. The information is invalid

2. The system provides the login page again

SETUP TRADE Use Case

· Main Flow

1. Trader chooses to set up trade

2. System queries product and business model

3. Trader describes product and business model

4. System provides business model set up page

5. Trader provides detailed info and trade rules

6. System validates information (E1)

7. System checks whether trade can be hosted (E2)

8. Trade is set up

· Alternate Flow

o E1

1. The input parameters are invalid

2. Set up page is given again

· E2

1. The system does not have enough resource

2. Informs the trader that trade cannot be hosted

BID Use Case

· Main Flow

1. A trader chooses to bid

2. The system queries which trade to bid for

3. Trader identifies trade

4. System provides bid page

5. Trader fills in the bid parameters

6. The system validates the bid (E1)

7. The bid is registered in the system

· Alternate Flow

1. Bid is invalid

2. System displays the message

3. System provides the bid page again

Following are the sequence diagrams for the chosen use cases.

Figure 2: Sequence diagram for Login Use Case

Figure 3: Use Case Register Sequence Diagram

Figure 4: Use Case Bid Sequence Diagram

Analysis Model

The use case realizations for chosen use cases are shown below.

Figure 5: Trader Register Realization

Figure 6: Bid Use Case Realization

We identify the key objects as Trader, Buyer, Seller, Controller, Trade, Bid, Rules, Business Model, Database and User Interface

A preliminary class diagram is shown below.

Figure 7: Preliminary Class Diagram

The following state chart diagram show the different states a trade object can be in:

Figure 8: State Chart for Trade Object

Below we show the activity diagram of a trader submitting a query. The diagram has three swimlanes, the Client, the Server and the Backend lanes.

Figure 9: Activity diagram for Query Use Case

Architecture Specification

The users of ELECTRON, namely the buyers and sellers should be able to login, register, bid, etc. from client machines. There is very little control on these client machine’s configurations. Also most of the business logic will be executed on the server end. Hence we chose a architecture where the client requires only a standard forms capable and Java enabled Web Browser. All user interactions with the system are through the browser.

Such a architecture puts minimum requirement on the client architecture and even clients with very little computing power can participate in the ETH. However this also limits the user interface ability, and puts a lot of pressure on the server.

Our architecture is a 5-tier one, with the client, web server, application server, business objects and database, respectively in the 5 tiers.

Figure 10: Architecture Specification

Drawn below is the package diagram.

Figure 11: Package Diagram

User Interface Package: Consists of the html pages and forms the client uses to input data and requests.

Middlerware Package: Consists of the master servlet which receives all the client requests and forwards them to the proper thread.

Business Object Package: Consists of the business objects which is responsible for maintaining the state of the auction house.

Database Package: Provides persistence to the business objects.

Utility Package: Utility classes like mail sending.

Detailed Design

Following are the detailed class diagrams :

Figure 12

Figure 13

Figure 14

Figure 15

Use of Design Models

1. Composite :

Products associated with a trade can be a single product or a bundle of products. (Fig 13)

2. Decorator

Products can have added attributes like warranty or bulk discount which can be added/ deleted/ modified during trade. (Fig 13)

3) Singleton

We are using the singleton design pattern to create a container of new agents that register with the market place. The singleton class container stores these agents till they are actively incepted in the market place.

4) Strategy:

In the Kasbah model, the pricing algorithm can have different kind of price raise/ decay function. Such algorithms can be encapsulated using the Strategy pattern. Also if a business model wants to have different winner determination algorithms the strategy pattern can be used.

Also in the GVA implementation different algorithm can be used for finding the optimal allocation. (Fig 14. 15)

5) Mediator

In the Kasbah market place there is a mediator, with whom all the agent registers. It does the matching of agents and also does all the notification activities like inception of a new agent, expiry of an agent and deals made. (Fig 15)