Академический Документы
Профессиональный Документы
Культура Документы
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.4 Pre-conditions
User has to authorized by the login before he can query
4.5 Post-conditions
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.
Auction has a set of predefined Traders and the Trader does not belong
to it.
2. The system indicates the Trader regarding this.
5.5 Pre-conditions
User has to authorized by login process submitting bid.
5.6 Post-conditions
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.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
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.5 Pre-conditions
User has to be authorized by login process before checking bid.
7.6 Post-conditions
None
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.5 Pre-conditions
User has to authorized by login process submitting bid.
8.6 Post-conditions
None
9 RFQ
9.0 Brief Description
This use case provides a facility for a trader to send RFQ to the potential
customer.
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.5 Pre-conditions
User has to authorized by login process submitting bid.
9.6 Post-conditions
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.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.
11.5 Pre-conditions
User has to authorized by login process submitting bid.
11.6 Post-conditions
None
11.7 Extension Points
None
12.3 Invalid
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.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.
Trader
Catelogue
RFQ
Auction
AuctionDB
create Auction
return Auction ID
setup Auction
validate Auction
query catelogue
close auction
login.java
Trader
VIPANI
Create Trader
login
Validate User
6: query catelogue
Trader
Catelogu
e
7: return Trader info
1: create Auction
3: setup Auction
9: check auction status
2: return Auction ID
RFQ
4: validate Auction
Auction
DB
1: submitQuery
Trader
Catelogu
e
4: submitBid
2: CreateBid
Bid
7: return BidID
5: validateBid
Auction
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
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:
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()
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
<<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
Client
Browser
Security
Layer
ViPANI Server
XML Parser
Database
Layer
Business Logic
Persistance
Database
Clients
Presentation Tier
Control Tier
Messaging
Layer
Business Logic
Database Manager
Security
Manager