ELECTRON

Design Document

Requirements Specification

ELECTRON is ELECtronic TRading ONline, a rendezvous for buying agents and selling agents to meet and transact business and commerce. Traders meet in the market place and participate in the trading. The various activities involved are

Traders interested in buying or selling should register with ELECTRON.

Registered trader can log into the system to buy or sell goods.

A trader can be a buyer or seller.

Trader provides the complete description of the product he wishes to buy or sell.

He also chooses the business model depending on which he may have to provide business specific information.

The central system accepts request from the user and performs the necessary action.

Once the trader specifies the product, central system tries to find a match between buyers and sellers based on the business model.

In case of a match, the trader is notified and payment is done.

Use Case Model

Actors

Trader

Buyer

Seller

Central System

Use cases

The trader registers with the system.

Registered trader is authenticated using his username and password and allowed to access the services.

Logout

User logs out of the system.

Add product description

The trader specifies the product he is interested in and whether to buy or sell. He also chooses the business model, depending on which he will be prompted for more information. For example in ‘Kasbah’ model he will be prompted for decay function, lowest/highest price etc.

Remove product description

Trader can remove the product description he has already submitted. This will enable him to remove his agent.

Update product description

Trader can change product description parameters such as price etc.

Choose business model

As part of product description, the user can choose the business model. Transactions are based on the model selected.

Query

The user can query about his status such as negotiation history, price etc. He can also query about other buyers, sellers and products.

Make payment

The trader makes payment electronically and securely once a match is found.

Notify

Events such as addition and deletion of product description are notified.

Match

Depending on the business model, central system matches the agents and determines the winner.

Setup Transaction

The transaction is set up by creating the agents and products and negotiation is done using a matching strategy determined by the business model. It uses the create agent use case.

Create Agent

Depending on the business model an agent is created. Agent is uniquely identified by the trader and product.

Remove Agent

This removes agent when a match is found or when user requests.

Use case Diagram

Key Use cases

Request for registration

Present registration page

Submit information to server

Validate information

Update database

Show confirmation page

Provide user name and password

Submit information to the server

Authenticate

Show confirmation page

Query

Request for query page

Process the query

Show result page

Add product description

Provide product information including business model

Submit information to the server

Server prompts user for business specific information

Provide business specific information

Validate information

Update database

Show confirmation page.

Setup Transaction

Central system sends set up transaction request to the business model.

Depending on the business model, an agent is created. The trader and product specify agent.

A product object is also created which contains all particulars about the product.

The agent is invoked to start negotiation.

The appropriate matching algorithm is used to determine the winner.

If winner selected, it notifies the trader and the business model.

Also database is updated to revise the prices.

Analysis Model

Class Diagram

Front End

The trader uses the user interface for interacting with the system. Depending on the request, Electron invokes the appropriate service handler such as register, login etc. These classes interact with the database to get the required information and present the response to the user. In case of requests for addition or modification of products, the database is also updated. BusinessModel class is invoked by Electron to handle business-specific information.

BackEnd

Backend process will create a thread for each business model. The thread will create the agents for doing negotiations. A trader and product identify an agent. Depending on whether trader wants to sell or buy, buying agent or selling agent is created. The agent will select the matching algorithm and negotiates. In case a match is found, the user is notified and payment is made, otherwise database is updated as specified by the business model.

Use case Realization

Add product description

Query

Setup Transaction

State Chart Diagram

Electron

Electron is the central system that processes all requests from the clients.

Activity Diagram

Backend Process

Architecture

Our design uses four-tier thick client architecture. Scripts are used for performing validations and transformations. The use of four-tier architecture enables clear separation of functionalities and thereby allows better understanding of the system. Applets and scripts are used for encrypting and sending data to the server.

Front-end of the system uses a layered architecture wherein the user interface communicates with the web server and the web server communicates with the database. Layering supports increasing levels of abstractions. It allows implementing a complex problem into a sequence of incremental steps. It also supports reuse and extensibility. But layering might compromise on performance.

Package Diagram

Component Diagram for Front-end

Design Model

Detailed Class Diagram

Front-end

The user interacts with the user interface to submit the details. Depending on the request invokes the appropriate service handler to handle the request. The database is accessed and updated whenever necessary. Results are also returned to the client by the servlet. The HTML pages are generated using the HTMGen class.

Back-end

The business engine creates thread for each business model. The thread invokes business model to create agent and products specific to that model. The agents start negotiation by calling appropriate matching strategy. If the match is found, end transaction is invoked to notify the winner and handle all other necessary actions. If no match is found, database is updated to revise the attributes of the business object in accordance with the business strategy.

Design Patterns Used

Builder

Builder pattern is used for creating the HTML pages to present the responses to the user. The HTMGen class acts as the Director and PageBuilder class represents the builder.

State

Depending on the link clicked by the user, the service handler invokes the appropriate class to handle the request. The ServiceHandler acts as the State here.

Prototype

A prototype is defined for creating an agent. So a Kasbah agent or Procurement agent can be created and if in the future, new agents can be created by registering a new concrete prototype.

Strategy

A strategy pattern is used for selecting the matching algorithm to be used for the negotiations and for determining the winner.

Decorator

Different business models require different product specifications, which can be effectively captured using a decorator design pattern. The BasicProduct class contains all basic attributes and it can be decorated using more business specific information.

Deployment Diagram