VIPANI release 1
PROGRAMMING ASSIGNMENT: VIPANI
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:
- 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.
- 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.
- 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.
- 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.
- 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:
- 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).
- 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:
- 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.
- An implementation with 2 different business models implemented by
March 20, 2005.
- 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:
- uniform format for messages (XML-based)
- notification
- interoperability
- extensibility.
GUIDELINES FOR RELEASE 1
The Design Document should contain the following. The EPSILON design
document is a good benchmark here.
- 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.
- 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.
- 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.
- 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.
- 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
