Вы находитесь на странице: 1из 23

4.

1 Brief Description
This use case describes how the Trader interacts with the catalog of
potential traders, ongoing auctions those are maintained by ViPANI.

4.2 Flow of events


The use case starts when the actor wishes to query the catalog of Traders by
their category and on going auction in the system.

4.2.1 Basic Flow


1. As soon a user logs in to the system, he/she will be provided with an option
to select the category of Trader and on going auctions in the system.
2. A user may select Trader of specific category.
3. A user may select the ongoing auctions of specific category in the system.
4. queryCatalog processes the user request and inform the user the details
of Trader or details of on going auctions.
5. A user may use information of on going auction to participate in that.
6. A user may use information of interested Traders to send RFQ(request for
quote).

4.2.2 Alternative flow


1.If the user session is invalid he will be informed appropriately.
2. If the user wish to go thorough his profile at this point, he is allowed to do
so.

4.2.2.1 Invalid query


1. If the user query is invalid, he will be displayed with appropriate
message.

4.3 Special Requirements


None

4.4 Pre-conditions
User has to authorized by the login before he can query

4.5 Post-conditions
None

4.6 Extension Points


None

5. SubmitBid
5.1 Brief Description

This use case describes how the Trader interacts with the on going auction
and negotiates the Bid price.

5.2 Flow of events


The use case starts when the Trader submits the Bid to Auction.

5.2.1 Basic Flow


1. The Trader selects from a list of auctions
2. submits his bid for the chosen auction
3. auction will records his bid.

1.2.2. Alternate flow


1.

Auction has a set of predefined Traders and the Trader does not belong
to it.
2. The system indicates the Trader regarding this.

5.3 Invalid bid


1. If the bid does not conforms to the auction rules invalid bid message is
generated.

5.4 Special Requirements


None

5.5 Pre-conditions
User has to authorized by login process submitting bid.

5.6 Post-conditions
None

5.7 Extension Points


None

6. Setup Auction
6.0 Brief Introduction
This use case describes how the trader setup an auction.
6.1 Flow of events
The use case starts when the Trader selects an auction to setup

6.2 Basic Flow


1.The user select the type of Auction to set up depending on business model.
2. He chooses the product(s) to be auctioned from the catalog of products.
3. He sets the rules for the auction
4. He sets the Starting/Closing Date/Time of the auction.

5. He chooses the algorithm for determining winners and price


6. He approves the list of Trader to invite, and the list of Trader-specific items that
each Trader will be allowed to bid on.
7. sends an RFQ to the list of Traders.

6.2.2 Alternative Flow


None

6.3

Invalid Auction
Each auction has to satisfy the business rules of specific auction type

6.4

Special Requirements
None

6.5 Pre-conditions
User has to be authorized by login process before submitting bid.

6.6 Post-conditions
None

6.7 Extension Points


None

7. Check Bid Status


7.0 Brief Introduction
This use case provides each Trader the status of ongoing bid in which he is
participating.

7.1 Flow of events.


The use case starts when the Trader wants to know about his/her bid.

7.2.1

Basic Flow
1. The seller identifies the auction to which the bid has been submitted
2. The system displays the current status of the bid i.e. the value of the bid,
whether the bid is the current best and so on.

7.2.2 Alternative Flow


None

7.3 Invalid Auction


Each auction has to satisfy the business rules of specific auction type

7.4 Special Requirements


None

7.5 Pre-conditions
User has to be authorized by login process before checking bid.

7.6 Post-conditions
None

7.7 Extension Points


None

8. Check Auction Status


8.0

Brief Introduction
This use case provides each Trader the information about the ongoing
auction setup by him/her

8.1

Flow of events
This use case starts when the Trader wants to know about the status of
auction set up by him/her.

8.2.1 Basic Flow


1. The user browses the catalog of auctions set up by him.
2. The user chooses the necessary auction whose status he wishes to
check.
3. The system displays the auction status.

8.2.2 Alternative Flow


None

8.3 Invalid Auction


Each auction has to satisfy the business rules of specific auction type

8.4 Special Requirements


None

8.5 Pre-conditions
User has to authorized by login process submitting bid.

8.6 Post-conditions
None

8.7 Extension Points


None

9 RFQ
9.0 Brief Description
This use case provides a facility for a trader to send RFQ to the potential
customer.

9.1 Flow of events


This use case is started after the Trader setup the auction and wants to send
RFQ to all the potential customer

9.2.1 Basic Flow


.1

The system checks for the set of suppliers for which the RFQ
to be sent.
.2
The system sends a RFQ in the standard format to all the
preferred vendors referring to the relevant details of auction that has
been setup.

9.2.3 Alternate Flow


None

9.3 Invalid request.


None

9.4 Special Requirements


None

9.5 Pre-conditions
User has to authorized by login process submitting bid.

9.6 Post-conditions
None

9.7 Extension Points


None

10. ePayment
10.0 Brief Description
This use case provides the facility for the Trader to make online payment
after he has own the bid.

10.1 Flow of events


This use case is started when the Winner of the bid for an auction is
determined.

10.2.1 Basic Flow


1. Once the winner is determined the buyer selects epayment.
2. Furnishes the bank account details.
3. Furnishes the detail of the Seller to make payment.
4. Submits the request to epayment to make EFT (Electronic Fund transfer)

10.2.2 Alternative flow.


If the details found to be incorrect for 3 consecutive times he is disqualified
and winner is determined again excluding this buyer.

10.3 Invalid request.


If the details furnished are not correct , he is asked to provide the correct
information.

10.4 Special Requirements


None

10.5 Pre-conditions
User has to authorized by login process before making meaningful
dialogue.

10.6 Post-conditions
Once the epayment is made the auction will be closed.

10.7 Extension Points


Security of epayment is concern, it require secure tunnel to ensure the
security.

11. Notify User


11.0 Brief Introduction.
This use case provides the Trader to communicate with other Trader ,
requesting him/her to participate in the auction.
11.1 Flow of events
This use case is started when the user wants to send the RFQ to the
potential user.

11.2.1 Basic Flow


1. The system sends the message to the users (buyer/sellers).

11.2.2 Alternative Flow.


None
11.3 Invalid
None
11.4 Special Requirements
None

11.5 Pre-conditions
User has to authorized by login process submitting bid.

11.6 Post-conditions
None
11.7 Extension Points
None

12. Auto Close Auction


12.0 Brief Introduction.
This use case is used when the winner is determined and payment is made
to the seller or when the time of auction is expired.

12.1 Flow of events.


This use case is started just after winner is determined or when the auction
timed out.

12.2.1 Basic Flow.


1. The system determines the winners by choosing the algorithm specified
by the Trader during the setup of auction.
2. The winners are informed about the auction.
3. The Trader, who has set up the auction is informed about the winners
and the other relevant details.
4. The auction status is updated.

12.2.2 Alternate Flow


1. There are no winner/bidders
2. The buyer is informed and the auction status is updated.

12.3 Invalid
None

12.4 Special Requirements


None

12.5 Pre-conditions
User has to authorized by login process submitting bid.

12.6 Post-conditions
None
12.7 Extension Points
None

13. Determine winners


13.0 Brief Introduction.
This use case helps in determining the winner of the bid for a given auction
depending on winner determination algorithm.

13.1 Flow of events.


This use case is started when the bids for an auctions are submitted,
depending on the auction rules and winner determination algorithm winner is
determined.

13.2.1 Basic Flow of events.


1. The use case collects all the bids
2. The use case uses the winner determination algorithm as set by the
Trader and computes the winning bids.
3. The system closes the auction and notifies the winners.

13.2.2 Alternate flow


1. The auction in multiple round auction
2. The system notifies the bidders on the current round details.

13.3 Invalid
None
13.4 Special Requirements
None

13.5 Pre-conditions.
User has to authorized by login process submitting bid.

13.6 Post-conditions
None
13.7 Extension Points
None
We have seen what important use cases are in the system. Now we will see the
flow of message in few use cases .i.e. sequence diagrams and collaboration
diagrams. Let us design sequence diagrams for submitbid, setupAuction and
login as well collaboration diagram for the same. This will enable to understand
ViPANI better.

Sequence diagram for submitbid

Sequence diagram for submitbid

Trader

Catelogue

RFQ

Auction

AuctionDB

create Auction
return Auction ID

setup Auction

validate Auction

enter in persistance storage

query catelogue

return Trader info

send RFQ to potential customer

check auction status

close auction

Sequence diagram for setupAuction

login.java

Trader

VIPANI

Create Trader

Submit loginID and password

login

Validate User

Sequence diagram for login

6: query catelogue
Trader

Catelogu
e
7: return Trader info

1: create Auction
3: setup Auction
9: check auction status

8: send RFQ to potential customer

10: close auction

2: return Auction ID

RFQ

4: validate Auction

5: enter in persistance storage


Auction

Auction
DB

Collaboration diagram for setupAuction

1: submitQuery
Trader

Catelogu
e

4: submitBid

2: CreateBid

3: Return Bid Object

Bid

7: return BidID

5: validateBid

6: put in persistance database


AuctionDB

Auction

Collaboration Diagram for setupbid

Design
SellerCatelogue
1
Catelogue

BuyerCatelogue

ViPANIMgr
1

queryCatelogue()

AuctionCatelogue

Trader
TradeType

Trade

Buy

Sell

doPayment()

1
1

0..n

setupAuction()
setBid()
getBidInfo()
modifyBid()

validateUser()

1
ViPANI

0..n

login()
logout()
checkStatus()
1..n
getAuctionIDs()
getBidIDs()
1
0..n
TradingAgent
0..n
setMinValue()
setMaxValue()
setIncrement()

0..n
1
1
0..n

RFQ

getBidType()
sendMessage()

0..n
Auction
startTime
EndTime
auctionID

1
notifyTrader()
sendRFQ()
1
determineWinner()
determinePayment()
acceptBid()
autoCloseAuction() 1

DatabaseMgr

0..n
BuyingAgent

ePayMent
modeOfPayment
amount

SellingAgent
1

0..n
PricingUnit

doPayment()
1

WinnerDP

determinPayment()

BusinessFactory

BidInfo
bidprice
noOfItems
bidID

determinWinner()

Second

SCVPA_evaluator

UDWinnerDP

SCVPA_Factory

SecondFacory

UD_Factory

SCVPA_PrUnit

SeconPrUnit

UDPrUnit

SCVPA_Bid
supplyChainCurve

Second_Bid

UD_BidInfo

1
1

1
SCVPA_Strategy

Second_Strategey

solveWDP()

SCVPA_CPLEX

solveWDP()

SCVPA_algo2

Second_CPLEX

UDWinnerDP_Strategy
solveWDP()

Second_algo2

UDWinnerDP_Algo1_CPLEX

UDWinnerDP_Algo2_CPLEX

Class diagram for ViPANI:


While Designing,
1. We are using following Design Patterns
a. Abstract Factory for creating instance of a typical business model and
related classes.
b. Factory Method for creating instances of Trader and Trade classes.
c. Strategy is used to facilitate user to solve winner determination
problem for a chosen business model with a flexibility of choosing different
algorithms at run time.
d. Sigleton: To create a single instance of ViPANI as well as DatabaseMgr,
ViPANIMgr.
e. MVC: This design pattern will be part of the application development.
f. Visitor : This design pattern provides the search of catalogue by trader.
2. We have preferred to use object composition over class inheritance.

Abstract Factory
Auction
startTime
EndTime
auctionID
notifyTrader()
sendRFQ()
determineWinner()
determinePayment()
acceptBid()
autoCloseAuction()

1
1

0..n
PricingUnit

WinnerDP

determinPayment()

BusinessFactory

BidInfo
bidprice
noOfItems
bidID

determinWinner()

SCVPA_evaluator

Second

UDWinnerDP

SCVPA_Factory

SecondFacory

UD_Factory

SCVPA_PrUnit

SeconPrUnit

UDPrUnit

SCVPA_Bid
supplyChainCurve

Second_Bid

UD_BidInfo

Intent: This design pattern allows the Different business model to be implemented
without having to change the interface. Provide an interface for creating families of
related or dependent objects without specifying their concrete classes

Participants:

WinnerDP : Declares interface for SCVPA_evaluator, Second,


UDWinnerDP.
BusinessFactory:Provides interface for SCVPA_Factory,
SecondFactory, UD_Factory
PricingUnit : Provides interface for SCVPA_PrUnit, SecondPrUnit,
UDPrUnit
BidInfo : Provides interface for SCVPA_Bid,Second_Bid,UD_BidInfo

Strategy
UDWinnerDP

SCVPA_evaluator
1

1
1
SCVPA_Strategy

UDWinnerDP_Strategy

solveWDP()

SCVPA_CPLEX

solveWDP()

SCVPA_algo2

UDWinnerDP_Algo1_CPLEX

UDWinnerDP_Algo2_CPLEX

Intent: Define a family of algorithms, encapsulate each one , and make them
interchangeable. This design pattern lets the algorithm vary independent from
clients that use it.
This design pattern provides the different implementation for winner determination
problem for the selected business model.

Factory Method
Trader
Trade
setupAuction()
setBid()
getBidInfo()
modifyBid()

TradeType
1

login()
logout()
checkStatus()
getAuctionIDs()
getBidIDs()
1
0..n
TradingAgent

Buy

Sell

setMinValue()
setMaxValue()
setIncrement()

doPayment()

BuyingAgent

SellingAgent

Intent: Define an interface for creating an object, but let subclasses decide which class
to instantiate.
This design pattern provides a mechanism to associate different types of trading agent
according to the role of trader. The type of agent to be instantiated is decided at run time
depending on the role the trader which can be seller or buyer.

Singleton
ViPANIMgr
validateUser()
1

1
1

Trader
TradeT ype
login()
logout()
checkStatus()
getAuctionIDs()
getBidIDs()

0..n

ViPANI

1
0..n
Auction
startTime
EndTime
auctionID
notifyTrader()
sendRFQ()
determineWinner()
determinePayment()
acceptBid()
autoCloseAuction()

1
1

DatabaseMgr

Intent: The design pattern ensures that a class only has one instance, and
provides a global point of access to it.

Here this design pattern is used to create single instance of ViPANI, ViPANIMgr,
DatabaseMgr.
Visitor:
SellerCatelogue

BuyerCatelogue

Catelogue
queryCatelogue()

AuctionCatelogue

1
0..n
Trader
TradeType
login()
logout()
checkStatus()
getAuctionIDs()
getBidIDs()

Intent: Represent an operation to be performed on the elements of an object


structure. Visitor lets you define a new operation without changing the classes of
the elements on which it operates.
This design pattern allows the Trader perform various types of query on the
database.

MVC design pattern:


Intent: This design pattern provides mechanism to separate the Design model from the
(user )interface of the application. The communication between the Design model and
user interface is done with the control object.
In this application the design model is completely separated from the application
interface with the control objects. The control objects can be created using the standard
web development tools like struts.

DEPLOYMENT MODEL FOR ViPANI


The Figure below gives details of component diagram for ViPANI assuming that
the software technology is to be Java Server Pages/ Servlets. Table below tells
us to which component the classes depicted in the Design Class Diagram are
mapped.
Name of the
Component

Classes in Design Class Diagram

Auction

BusinessFactory
Catelogue
TraderCatelogue
ProductCatelogue
DatabaseMgr
SellerClient
BuyerClient

Auction:
winnerDP: for SCVPA_evaluator, Second,
UDWinnerDP.
ePayment:
PricingUnit: SCVPA_PrUnit, SecondPrUnit, UDPrUnit
Bidinfo: SCVPA_Bid,Second_Bid,UD_BidInfo
BusinessFactory:: SCVPA_Factory, SecondFactory,
UD_Factory
Catalogue
TraderCatelogue
ProductCatelogue
DatabaseMgr
Seller class implementing Trader
Buyer class implementing Trader class

Table: Mapping between Class Diagram and Component Diagram

<<client page>>
login.java

<<client page>>
Trader home

<<client page>>
submit bid

<<client page>>
Check Auction
Status

<<client page>>
Setup Auction

<<client page>>
Check Bid
Status

<<client page>>
change profile
<<server page>>
Seller Servlet

<<server page>>
Authentication
unit

<<server page>>
Buyer servlet

MessagingClient

AuthenticationDB

catelo
gue

Business
Factory

Auction

BidDB

<<client page>>
ePpayment

buyer

seller

AuctionDB

TraderCatelogue

Buyer Catelogue
Seller Catelogue
Product Catelogue

product
catelogue

DatabaseMgr

Component diagram for ViPANI.

Client
Browser

Security
Layer

ViPANI Server

XML Parser

Database
Layer

Business Logic

Package diagram for ViPANI

Persistance
Database

AN ARCHITECTURE FOR ViPANI


The architecture of ViPANI is multi-tired. Which will ensure that the functionality of the
application is distributed among different layers to ensure smooth flow of messages in
the system. The different layers identified in the system are

The Web Presentation Tier


This is realized in many ways , different approaches suggested are Java server
pages, Active sever pages, etc.
The Control Tier.
This is a very important tier which separates the business logic from the
application interface This can be realized by the standard web development tools
like struts.
The Business Logic Tier
This is where the actual Design model is implemented , this tier intern interacts
with control tier to communicate to the end user.
The Data Handling Tier
This is very important layer used to persist business logic objects , this layer
separate s the business layer from the underlying database. This layer can be
realized using standard OR tools like hibernate and iBatis.

Clients

Presentation Tier

Control Tier

Messaging
Layer

Business Logic

Database Manager

Architecture diagram for ViPANI

Security
Manager

Вам также может понравиться