ELECTRON is  ELECtronic TRading ONline, a rendezvous for buying agents and selling agents to meet and transact business and commerce. Each batch (of two students) will be building ELECTRON in three releases. Release 1 emphasizes use of OOAD to create a sound design model for ELECTRON. Release 2 will focus on implementing ELECTRON with focus on business model and market algorithms. Each batch will implement a distinctive business model and associated algorithms. Release 3 will "secure" ELECTRON and build an "epayment" infrastructure. This programming assignment is intended to go hand in hand with the lecture sessions.

First, do the following:

(1) Read Chapter 12 from the book by Ericsson and Penker (The UMLToolkit). The chapter describes a case study of a library support system (analysis and design using UML). This is part of the reading material already provided to you.
(2) Read Chapter 8 from Rumbaugh's book, which discusses a systematic process for object oriented modeling for an ATM case study.
(3) Read the following paper: Object oriented analysis and design of a web-enabled auction house (by Y. Narahari, K.N. Rajanikanth, and Sourav Sen). This is also part of the reading material.
(4) Read the paper on Kasbah (1996): An Agent Based Marketplace, by Pattie Maes. Download from MIT Medialab website.

ELECTRON is a generalization of Kasbah. Traders (buyers/sellers) can register with ELECTRON and participate in trading. Traders can choose one of several business models that are offered by ELECTRON.

(1) A potential seller registers with ELECTRON and provides information on the product(s) he would like to sell and chooses a business model. This could be an auction (direct or reverse), combinatorial auction (direct or reverse), continuous double auction, call market, etc. As soon as the seller registers, ELECTRON 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 ELECTRON and provides information on the product(s) she would like to buy. When a buyer registers, ETH 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 and trade determination algorithms.
Your implementation should cover 2 business models: (1) Kasbah model and (2) your own "distinctive" model.

ELECTRON 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 February 15, 2003. Note that effective use of design patterns and best practices in OOAD will be critical to the robustness of your design model. 
(2) An implementation with  2 diverse business models implemented by March 10, 2003.
(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, 2003.
Your design model should ensure that your ELECTRON evolves gracefully through Releases 2 and 3. Issues that will need special attention are:  (a) uniform format for messages (XML-based) (b) notification (c) interoperability (d) extensibility.


GUIDELINES FOR RELEASE 1

The Design Document should contain the following.
(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 February 15, 2003.