E0 239 : Electronic commerce

Y. Narahari
e-Enterprises Laboratory
Department of Computer Science and Automation
Indian Institute of Science
Bangalore - 560 012

VIPANI release 1


VIPANI is a generic Electronic Business Exchange, which offers a wide variety of business models and enables buying agents and selling agents to meet, choose/set up a business model, and transact business and do commerce in a secure way.

Each batch (of two students) will be designing, architecting, and building VIPANI in three releases. Release 1 emphasizes use of OOAD to create a sound and robust design model for VIPANI. Release 2 will focus on implementing VIPANI with focus on business model and market algorithms. Each batch will implement one common model and one distinctive business model and associated algorithms. Release 3 will "secure" VIPANI and build an "epayment" infrastructure.
First, do the following if you have not already done:

  1. Read the design document of EPSILON (E-Procurement Solution) which can be downloaded from my website. This provides you with a benchmark for your own design document.
  2. Read the paper on Kasbah (1996): An Agent Based Marketplace, by Pattie Maes. Download from MIT Medialab website.

VIPANI is a generalization of Kasbah. It is intended to be a highly configurable marketplace capable of supporting a wide variety of business models including new, user-defined business models.

Traders (buyers/sellers) can register with VIPANI and participate in trading. Traders can choose one of several business models that are offered by VIPANI or can define their own business models.

  1. A potential seller registers with VIPANI and provides information on the product(s) he would like to sell and chooses a business model. This could be a forward auction, reverse auction, or an exchange, etc. As soon as the seller registers, VIPANI will do a variety of things such as matching him to potential buyers or matching (aggregating) him with other potential sellers, etc, as entailed by the business model.
  2. A potential buyer registers with VIPANI and provides information on the product(s) she would like to buy. When a buyer registers, VIPANI will enable the buyer to know the potential sellers, aggregate the buyer with other potential related buyers, etc, as entailed by the business model.
  3. A "trade" happens where 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).

Your design should support a wide variety of business models, user-defined business models and winner determination algorithms. This calls for solid use of design patterns in your design.
Your implementation should cover at least two business models:

  1. A marketplace for procuring multiple units of a single item using a supply curve auction with Vickrey pricing (this will be covered in the class) (this mechanism is common to all the batches).
  2. A distinctive model different from supply curve auction (this would be different for different batches and would suggested by me to individual batches - if a batch wishes to come up with their own mechanism, that would also be welcome).
VIPANI will have three releases:
  1. A complete design model (UML analysis diagrams, UML design diagrams, software architecture, and use of design patterns) to be submitted by March 1, 2005. Note that effective use of design patterns and best practices in OOAD will be critical to the robustness of your design model. If you wish, you may use Rational Rose, but it is not mandatory.
  2. An implementation with 2 different business models implemented by March 20, 2005.
  3. A more complete implementation with use of crypto APIs, security APIs, and payment APIs (using public domain toolkits that will be recommended later) by April 10, 2005.

Your design model should ensure that VIPANI evolves gracefully through Releases 2 and 3.

Issues that will need special attention are:


The Design Document should contain the following. The EPSILON design document is a good benchmark here.

  1. A use case model. Choose the actors and use cases. Write down a detailed use case diagram(s). Prioritize the use cases. Choose architecturally significant use cases and write down detailed descriptions for those in the standard format. Write down interaction (sequence or collaboaration) diagrams for the chosen use cases.
  2. An analysis model. Discover all important abstractions (classes, interfaces, active classes, collaborations, etc.) for the application. Write down use case realizations for chosen use cases. Present a class diagram. Write down state chart diagrams for interesting objects and activity diagrams for interesting business processes. Use an iterative approach to arrive at an optimal analysis model.
  3. An architecture specification. Describe which architectural style(s) your system will be using. Clearly identify the major components and connectors. Package diagrams and component diagrams will come in handy here. Emphasize traceability from use cases to architecture. You should do an architectural analysis to confirm good features of the architecture and also reveal where the architecture is weak.
  4. A Design Model. Use appropriate UML diagrams here. The emphasis should be on a compelling use of design patterns. Do not try too many patterns. Use several (four to five is a good number, but could be less or more depending on your problem) patterns that fit your problem in a natural and non-trivial way. The diagrams you prepare should clearly bring out the use of the patterns. Though patterns are to be emphasized, do not let patterns completely dominate pragmatic issues of your design model.
  5. Make a HTML page of your design document email me a URL for that page before March 1, 2005.

    some important links:

     Modified by: Sandhya G & Shijesta Victor on 03.11.2003