Design Model by
ME. CSE,
Problem Description
ELECTRON stands for ELECtronic TRading
ONline. This course project aims at building an electronic
commerce system which can support different types of business models. Users can
visit the ELECTRON website, register and after logging into the system they can
setup different kinds of auctions as well as bid for the products kept for
sell. A user can also register a request for a product which may become
available in future. The whole process is made automatic by the use of “agents”
for each of the seller and buyer of
auction. “Agents” are software processes which do the task of carrying out
business process for each user. Below we
present the complete design model for ELECTRON.
SOLUTION
OVERVIEW
The design presented here has been created using the OOAD
technique. Enough care has been taken to ensure that the model is easily
extendible and can support various different kinds of business models easily.
Design patterns have been used to sufficient extent to ensure flexible, robust,
extendible and reusable system architecture.
The design process was carried out using the “Rational Products
Enterprise edition” suite of software to make effective use of UML modeling
technique. The design model suggested here has been implemented by us for the
KASBAH and IGVA-iBundle
business models.
1.
USE CASE
DIAGRAM
The requirements
analysis task of the system is captured by the use case diagram. There are 3 major actors on the scene.
·
Sellers
Registered users of ELECTRON, after logging in into the
system can setup auction. The auction can use any of the business models
supported by the system. For each seller the system creates an configurable
agent which takes care of the business for the seller thereafter.
·
Buyers
Registered users interested in buying products kept for sell
at ELECTRON can log into the system can choose from a range of products
available for sell. There bidding process is made automatic by specifying the
system to create a configurable agent for them.
·
Moderator
Moderator represents the controller of the
system. It is not a physical entity but represents the ELECTRON monitor. It is
responsible for legal working of the business processes.
1.
SEQUENCE
DIAGRAMS
We present below the sequence diagrams for 3 of the major
use cases that we have identified. They depict the actual sequence of events
expected to happen during the execution of each of the use cases.
·
Bid
After the buyer specifies her interest in buying objects the
system displays it the list of all available products for sell. The buyer
selects the product he is interested in. Since the business model for that
particular auction has already been set now the system asks the bidder to
specify the details of the automation of the bidding process. Depending on the
specifications an agent is created by the system for the buyer who carried out
the further bidding process.
·
Login
The login process involves verification of the password
specified by the user by ELECTRON using the database. After the login is
verified the user is allowed to access the system.
A person interested in setting up an auction requests
ELECTRON . After filling up the details in the form the details of the auction
the system sets up a new a new auction for her and an agent is created to
automate the further process. An entry is made in the database for this
particular auction.
2.
PRELIMINARY
CLASS DIAGRAM
The preliminary class diagram for the system is presented here.
3.
USE CASE
REALIZATIONS
Diagrams below show the objects which are are used in the
realization of the use cases for bid and login process.
·
Bid
·
Login
4.
ARCHITECTURE
DIAGRAM
We present hybrid architecture for the system. The architecture diagram depicts the
4-tier architecture of the system.
The system uses 5 different packages for user interface (UI
package), application logic (business logic package), the database access
interface (database package), and a package for web services (internet services
package).
The various components of the system which make up each of
the packages are depicted in this diagram.
5.
STATE CHART
DIAGRAMS
The various states and interaction among them for each agent
created, and auction are shown here.
·
Agent
Unlike in original KASBAH model where the system does the
job of determination of the winner and the task of matching the requests with
demands, here each agent is autonomous in itself and with the help of the
auction object does the desired task.
The state chart diagram depicted is a specific one for the Kasbah
business model for the selling agent only. For each of the new bid
arriving for a product the selling agent
for that particular product does the task of matching all the bids and current
requirements from the seller and decides whether the match is found or not.
After a successful match the agent notifies the auction creator and waits for
his final approval. In case no match is
found the agent waits again for the next bid.
·
Auction
Even though the agent is autonomous his contact with the
creator is through the auction object. Since the agents are autonomous the
auction object itself passes through small no. of states as its task is reduced
now. It creates the agent for the user
and waits till the agent finishes his task. After the creator of the auction
gives his approval for finalizing the deal the auction object is destroyed.
6.
DETAILED DESIGN DIAGRAM
The detailed design model along with all the classes, their
attributes and methods is specified in this detailed design diagram. Design patterns have been used here to make
the design more extendible and reusable.
Following design patterns have been used while designing the model:
·
Abstract
Factory
The type of the bids and the business logic depend upon the
type of the business model chosen by the user. After the creator chooses a
particular business model for a particular product all the objects needed to be
created for it have to be created of that kind only. Thus here we are required
to create families of objects of a particular kind. Hence abstract factory
pattern can be used here. The AuctionFactory abstract factory class is
inherited by the classes representing concrete creators for each of the
business models. The concrete classes for each of the business models and bids
are created by these concrete AuctionFactory classes.
·
Composite
In a combinatorial auction a trader can put his bid either
on a part or whole of the product for sale. In some other kinds of auctions
also this can happen. To model this part-sole item relationship we use
composite design pattern for the Product class.
·
Singleton
Electron and Database should have single point of access and
single instance; hence they are made into Singleton classes.
·
Mediator
All the agents created for a particular auction need to
communicate with each other. Each buying
agent needs to be informed about all the new bids that are being put up and the
current price offered by the seller for the product. One mediator object is
created for each auction which carries out this responsibility of inter-agent
communication.
·
Iterator
The access to the database is provided though a class which
implements the Iterator interface. This helps particularly for the queries
about all auctions of a particular product all bidders for a particular
product, etc. However we find that such an interface is provided already by the
java class ResultSet.
