Design Model by
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Electron and Database should have single point of access and single instance; hence they are made into Singleton classes.
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.
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.