VIPANI: A Generic
Electronic Business Exchange
-Sarojini (04842)
-Sudha
Kolavali(04988)
1. INTRODUCTION
This report documents the
software modeling, analysis, architecture and design of VIPANI, 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. UML (Unified
Modeling Language) has been used to visualize, specify, construct, and document
the artifacts of VIPANI. The key features of VIPANI architecture and design are
extensibility, robustness, re-usability, flexibility, scalability and security.
This can be achieved with the practice of design patterns, which help in designing
Object-oriented software. Design Patterns make it easier to use successful
designs and architectures.
The organization of the report is as follows. Section
2 deals with Requirement definitions for VIPANI. Section 3 presents the
object-oriented analysis of VIPANI. In this section, the software requirements
specification is presented first, followed by a detailed use-case model,
accompanied by a description of the use cases. This is followed by a domain
analysis where an analysis level class diagram is presented. Sequence and
collaboration diagrams are presented next. In Section 4, the discussion is centered on VIPANI architecture.
Section5 presents the design model in the form of a design level class diagram.
This section is on the application of the following design patterns: Abstract
Factory, Strategy, Observer, Singleton, Mediator, Composite, Decorator . In
Section 6, component and deployment models are presented.
2.REQUIREMENTS DEFINITION
This section deals with
requirements specification for VIPANI.
GOAL: VIPANI is a software system, which enables buyers
and sellers to meet and transact business in a secure way.
TOP LEVEL REQUIREMENTS
DEFINITION:
RD 1: Traders (buyers/sellers) can register with VIPANI and
participate in Trading. They can choose one of the several business models that
are offers by VIPANI or can define their own business models.
RD 2: A potential registered seller provides information
on the product(s) he would like to sell and chooses a business model. This
could be forward auction (FA), reverse auction (RA), or an Exchange auction
(EA). VIPANI matches the registered
seller to potential buyer(s) or matches (aggregates) him with other potential seller(s),
etc, as entailed by the business model.
RD 3: A potential registered buyer provides information
on the products he would like to buy. VIPANI enables the registered buyer to
know the potential sellers, aggregate the buyer with other potential related
buyers, etc, as entailed by the business model.
RD 4: Trade happens where buyers and sellers participate
and negotiate according to a chosen business model. The trade determines the
winners. The winning buyers make the payment electronically and securely to the
sellers.
These are the top-level
requirements specified for VIPANI.
3.ANALYSIS OF VIPANI
3.1 SOFTWARE REQUIREMENTS SPECIFICATION
VIPANI has the following
agents:
- Buyer
- Buying Agent
- Seller
- Selling Agent
- Administrator
- Database Manager
The agents requirements are
as follows:
3.1.1
Buyer:
3.1.1.1:
Buyer should be able to login, change passwords and browse ‘relevant’ parts of
the system.
3.1.1.2:
Buyer should also be able to register with VIPANI.
3.1.1.3:
Buyer should be able to check the status of bids placed by them.
3.1.1.4:
Buyer should be able to add items to the product list.
3.1.1.5:
Buyer should be able to create new auctions, modify rules of predefined
auctions before it gets started or choose an existing business model offered by
VIPANI.
3.1.1.6:
Buyer should be able to close the auction.
3.1.1.7: Buyer should be able to know
potential sellers or aggregate with other potential related buyers, those
participate in an auction as entailed by business model.
3.1.1.8:
Winning Buyer has to pay the amount to the seller, securely.
3.1.2 Buying Agent:
3.1.2.1: A buying agent is a
software agent capable of carrying out some of the actions on behalf of the
buyer. Specifically, query the bids
submitted to the auction.
3.1.2.2:The services should
be offered via secure, authenticated means.
3.1.3 Seller:
3.1.3.1: Sellers must be
able to login, change details, and browse ‘relevant’ parts of the system.
3.1.3.2: Sellers must be able to
register with VIPANI.
3.1.3.3: Sellers should be
able to check the status of offers placed by them.
3.1.3.4: Seller should be able to add items to the
product catalogue.
3.1.3.5: Sellers should be
able to create new auctions or choose an existing business model offered by
VIPANI.
3.1.3.6: Sellers should be
able to close the auction.
3.1.3.7: Sellers should be
able to know potential buyers or aggregate with other potential related
sellers, those participate in an
auction as entailed by business model.
3.1.4 Seller Agent:
3.1.4.1: A selling agent is
a software agent capable of carrying out some of the actions on behalf of the
seller. Specifically, query the
auctions scheduled for a specific period; and query the interim allocations and
final allocations of the auction.
3.1.4.2: The services should
be offered via secure, authenticated means.
3.1.5 Administrator:
3.1.5.1: He should be able to validate the user.
3.1.5.2: He should be able to add/Remove new products to the
existing Catalogue.
3.1.5.3: He should be able
to validate the auction/bid.
3.1.5.4: He should be able
to monitor the auction and notify to the users.
3.1.6 Database Manager:
3.1.6.1: He should be able
to validate the DB connection.
3.1.6.2: He should be able
to store the product/trader catalogue in database and should help to execute
any query on the underlying data.
3.2 USE-CASE MODEL:
Use-case diagrams are used for modeling the dynamic
aspects of the system. These are important for visualizing, specifying, and
documenting the behavior of an element. A use-case model describes what the system does for each type of user
and provides the essential input for analysis, design, and testing. Use-case
diagrams consist of Use cases, Actors, and the relationships between them.
These are used to model the context and requirements of a system.
3.2.1: Actors:
The actors that are identified in VIPANI are:
1.
Seller
2.
Buyer
3.
Administrator
4.
Database
3.2.2: Use Cases:
The
Use-cases that are identified are shown in a tabulated form:
|
Sl.No |
Use Case |
Software Requirements traced to Use Case |
|
1.0 |
Login |
SR 3.1.1.1, SR 3.1.1.1 |
|
2.0 |
Logout |
SR 3.1.1.1, SR 3.1.1.1 |
|
3.0 |
Register with VIPANI |
SR 3.1.1.2, SR 3.1.3.2 |
|
4.0 |
Place Bids |
SR 3.1.1.5,SR 3.1.3.5 |
|
5.0 |
Setup an Auction |
SR 3.1.1.5, SR 3.1.3.5 |
|
6.0 |
Modify an Auction |
SR 3.1.1.5, SR 3.1.3.5 |
|
7.0 |
Choose a Model |
SR 3.1.1.5, SR 3.1.3.5 |
|
8.0 |
Check Status |
SR 3.1.1.3,SR 3.1.3.3 |
|
9.0 |
Browse Trader Catalogue |
SR 3.1.1.7,SR 3.1.3.7 |
|
10.0 |
Modify Product Catalogue |
SR 3.1.1.4, SR 3.1.3.4 |
|
11.0 |
Close Auction |
SR 3.1.1.6, SR 3.1.1.3.6 |
|
12.0 |
Determine Winners |
SR 3.1.1.3, SR 3.1.2.1 |
|
13.0 |
Notify Users |
SR 3.1.5.4 |
|
14.0 |
Payment |
SR 3.1.1.8 |
|
15.0 |
Validate Auction |
SR 3.1.5.3 |
|
16.0 |
Validate DB Connection |
SR 3.1.6.1 |
|
17.0 |
Manage User |
SR 3.1.5.1 |
|
Add User |
||
|
Remove User |
Table 3.1: Use cases Identified
The Use case diagram is as
shown in Figure 3.2. Use Case diagrams
for Add/Remove User, Set Up Auction, Set up Bids, Check Status and Close
auction are also shown.
Fig
3.2: Use Case diagram for VIPANI.
Fig
3.3 use case diagram for “Add/Remove User”
Fig 3.4 use case diagram for “Set
up Auction”
Fig 3.5
: Use case diagram for “Bid”
Fig 3.6: Use case
diagram for “Check Status”
Fig 3.7: Use case
diagram for “Close Auction”.
3.2.3: USECASE
DESCRIPTION:
1.Login/Logout Use Case:
a. Assumptions:
User is already registered as seller/buyer.
b. Main Flow:
i.
User enters his/her
name, password
ii.
System determines
whether he is a registered user.
iii.
System displays
corresponding interface and profile.
iv.
Users can logout. User
data will be stored in database.
c. Alternate Flow:
i.
Incorrect
Username/Password system prompts for re-login.
ii.
Otherwise shall ask the
user to register.
2.Register Use Case:
a. Main Flow:
i.
User enters name,
email, password and registers with VIPANI.
ii.
User should also
provide his category i.e., seller /buyer.
b. Alternate Flow:
i.
If login already
exists, user should register again.
3.Place Bids Use Case:
a. Main Flow:
i.
Trader provides
information on the trading products and bids.
c. Alternate Flow:
ii.
In case of incorrect
information, system takes him back to bidding page.
4.Set
Up an Auction:
a. Main Flow:
i.
Trader chooses the
products for which auction needs to be setup.
ii.
Trader should create a
new auction ID.
5.Choose a Model:
a. Main Flow:
i.
Trader should choose a
Model for Auction.
ii. Trader should choose the Winner
Determination and Price Determination Algorithms.
ii.
Trader should set the
closing auction date/time of the auction.
6.Check
Status:
a.
Main Flow:
i.
Trader should be able
to check the status of auction/bids placed by them.
7.Browse
Product/ Trader Catalogue:
a. Main Flow:
i. Trader should add/remove products in
the auction.
ii.
Trader should also know
the other traders participating in the auction.
8.Close
Auction:
a. Main Flow:
i.
Trader decides to close
the auction.
ii.
Winner is determined
and is notified to the users in the Trade.
iii.
System closes the
auction and updates the database.
9.Notify Users:
a. Main Flow:
i. System sends a message to all the users.
3.3 DOMAIN ANALYSIS:
The information gathered
during the construction of the use-cases was used to perform the object
decomposition and build the object structure of the system.
Object Identification: The key
objects are: Buyer, Seller, Bid, Auction, Administrator, Auction Rules, Item,
Products, and Administrator.
Relationships
Identification: The key relations
between different classes are:
Ø
Seller/ Buyer is
specialization of trader.
Ø
Forward Auction,
Reverse Auction and Exchange auction are types of auction.
Ø
Composite bid is
composition of Single bids.
3.3.1 Sequence Diagrams:
In this section Sequence diagrams for Setup Auction and Submit
Bid are shown.
Fig 3.8: Sequence
diagram for “Setup Auction”
Fig 3.9: Sequence
diagram for “Submit Bids”
4.ARCHITUCTURE MODEL
Successful systems
invariably need robust, scalable and flexible architectures. In this phase the
model that we have developed in the class diagrams is organized into various
packages, tiers and components.
VIPANI is designed as 4-tier
model. The different tiers are:
1. Presentation Layer.
2. Control Layer.
3. Business Logic Layer.
4. Database Layer.
Fig 4.1:
Architecture diagram for VIPANI.
Presentation Layer: This layer is designed to allow the user to access
the services offered by the system. The user is allowed to perform a set of
well-defined operations, which achieves the ultimate business goal, such as
registration, login, logout, participating in auctions, etc. SinceVIPANI allows
for software agents to interact with the system, it is possible for users to bypass
this layer while accessing the services offered by the system. However, since
the operations allowed for the agents are restricted, this layer can be
considered to be the starting point of most interactions with the system.
Control Layer: This layer essentially
provides various activities of the system. It is responsible for access
control, directing the requests to specific business logic components and data
handling components.
The Business Logic Layer: This is the main layer of
the system. The services that are promised by the system are actually performed
here. The determinations of winners and the price to be paid by the buyer to
the winners, management of auctions, etc are some of the prominent
functionalities of this Layer.
The Database Layer: This layer is responsible
for handling all operations related to the database(s) that store the
information of the system. This layer is responsible for initializing
databases, maintaining the database connections, manipulating databases.
5. DESIGN OF VIPANI
The following diagram shows the design level class
diagram evolved from the analysis. Concentrating more on the Business Logic rather than the Persistence
Mapping, or User Interface develops this diagram.
Fig 5.1:
Class Diagram for VIPANI.
5.1 DESIGN PATTERNS:
Design patterns applicable
for VIPANI are:
Ø ABSTRACT
Ø COMPOSITE
Ø DECORATOR
Ø MEDIATOR
Ø OBSERVOR
Ø STRATEGY
Ø
SINGLETON
5.1.1 ABSTRACT FACTORY:
Intent:
Provide an interface for creating families of related or
dependent objects without specifying their concrete classes.
Participants:
Auction
object uses the interfaces declared by Auction, Bid, Offer, Rules and
notifier classes.
- Auction declares an interface for operations
that create Bid, Offer and Rules classes
- Forward Auction, Reverse Auction and Exchange
implements the operations such as Create Bid (), Create Offer (),
CreateNotifier () and Create Rules () to create corresponding Bid, Offer,
Notifier and Rules.
- Bid, Offer, Notifier and Rules declare an
interface for FABid, RABid, EXBid and FAOffer, RAOffer, EXOffer and
FANotifier, RANotifier, EXNotifier and FARules, RARules, EXRules
respectively.
Applicability:
It is used when a system should be configured with
one of multiple families of products. A system should be independent of how its
products are created, composed and represented.
Structure:
Fig 5.1: Abstract factory Pattern
5.1.2 COMPOSITE:
Intent:
Compose objects into tree structures to represent part-whole
hierarchies. Composite lets
clients treat individual objects and compositions of objects uniformly.
Participants:
Bid: Declares the interface for objects in the composition.
Single Bid: Defines primitive objects in the composition.
Composite Bid: Implements child-related operations in the Bid interface.
Applicability:
Composite pattern is an abstract class that represents both primitives and
their containers. Since Bid can be a single item bid or combinatorial bid,
composite pattern can be used here.
Structure:
Fig
5.2: Composite Pattern
5.1.3 DECORATOR:
Intent:
Attach additional responsibilities to an object dynamically.
Decorators provide flexible alternative to subclass-in for extending
functionality.
Participants:
Bid: Defines an interface for objects that can have responsibilities added to
them dynamically.
Bid Embellishment: defines an interface for defining additional attributes like
Business rules, Time stamping, XMLify, Encrypting
etc.
Applicability:
We can add responsibilities to Bid object dynamically and transparently
that is without affecting others objects.
Structure:
Fig 5.3:
Decorator Pattern
5.1.4 MEDIATOR:
Intent:
Define an object
that encapsulates how a set of objects interacts. Mediator promotes loose
coupling by keeping objects from referring to each other explicitly, and it lets
you vary their interaction independently.
Participants:
Trader: Defines an interface for communicating with sellers and buyers.
Mediator: Implements cooperative behavior by coordinating colleague objects.
Seller and Buyer: Each Seller and buyer communicate with its mediator whenever
it would have otherwise communicated with another seller/buyer.
Applicability:
In Exchange auction
multiple buyers and multiple
sellers need to interact with each other by bidding and offering. Since this
communication is
complex, we use Monitor as Mediator.
Structure:
Fig
5.4: Mediator Pattern
5.1.5
OBSERVER:
Intent:
Define relationship amongst a collection of objects such
that whenever one object is updated all others are notified automatically.
Participants:
Notifier: Provides an interface for attaching and detaching Observer
Objects.
Observer: Defines an updating interface for objects that should be
notified of changes in a notifier.
FA/RA/Ex Notifier: Sends a notification to its observers when its state changes.
Seller/Buyer: Implements the Observer updating interface to keep its state
consistent with the Notifier.
Applicability:
When changes to one object require changing others.
Structure:
Fig 5.5
Observer Pattern
5.1.6
STRATEGY:
Intent:
Define a family of encapsulated algorithms and make them
interchangeable so each algorithm can vary independently from the clients that
use it.
Participants:
Auction: Maintains a reference to
WDA/PDA.
WDA/PDA: Declared an interface common to all supported algorithms.
Notifier uses this interface to call the algorithm defined by a WDA/PDA.
Applicability:
When many
related classes differ only in their behavior and when different variants of an
algorithm are present.
Structure:
Fig
5.6: Strategy Pattern.
5.1.7 SINGLETON:
Intent:
Ensure a class only has one
instance and provide a global point of access to it.
Participants:
Database Manager and Trade manager are responsible for multiple clients
to access their unique instance.
Applicability:
This is used when there must be exactly one instance of class and it
must be accessible to clients from a well-known access point.
Structure:
Fig
5.7: Singleton Pattern.
6.
DEPLOYMENT MODEL FOR VIPANI
Table 6.0 tells us to which
component the classes depicted in the Design Class Diagram are mapped.
|
Name of the Component |
Classes in Design Class Diagram |
|
VIPANI Manager |
Vipani Manager |
|
Trader |
Trader, seller, buyer |
|
Auction |
Auction, Bid, Items, Rules, WDA, PDA. |
|
Database Manager |
DatabaseManager |
Table 6.1 Mapping between Class
Diagram and Components
6.1 A HIGH
LEVEL COMPONENT DIAGRAM
Figure 6.2 depicts a high-level
component view of VIPANI using UML package diagram.
Client Package: Consists of HTML pages, which
enable the user to interact with the system.
WebServer Package: Consists of JSP/Servlets, which
handle the requests from the clients and are responsible for invoking
appropriated objects in the Business Logic Package.
Messaging Package: Consists of mechanisms used for
client and server communication, such as XML.
Business Logic Package: Consists of worker classes, which
implement the auction logic part. This package uses the services of Database
Package. The classes in this package perform activities like winner
determination, pricing etc.
Database Package: Consists of classes whose
implementation depends on the persistent storage media chosen. The DataManager
class in this package is responsible for maintaining connectivity with the
Database and acts as an interface for other classes performing certain
operations like insert, update, delete, and select on the Data Base.
Persistent Storage Package: Database system used.
Figure
6.2. A High level component view for VIPANI