wang xf

Greenhorn
+ Follow
since Nov 24, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by wang xf

Jeanne Boyarsky wrote:

wang xf wrote:[I have provided the domain model and the use case above. My question is the domain model is conflicting with the test case from my understanding.


I'm sorry. I think I am missing the obvious here. Which is the test case?



The complete use case "Use Case Specification - Issue PO to Winning Bidder" is at 4th floor.

Jeanne Boyarsky wrote:Wang,
I actually just did it as making one use case a pre-requisite for the other in my sequence diagram.



Hi Jeanne,

thanks.

But the use case "Enter Request" is independent of the use case "Check Inventory Availability". It does not really need to have the pre-requisite to start it.

Correct me if I am wrong.
There are 5 use cases in the diagram. The "Check Inventory Availability" use case include the "Enter Request" use case. like this below:

"Check Inventory Availability" --- <<include>>------> "Enter Request".

I will draw the sequence diagram for these two use case separately. Do I need to address this kind of "include" relationship in the sequence diagram. If yes, how do I do in the sequence diagram?

Jeanne Boyarsky wrote:I'm not sure how to help without talking about the assignment too much. Maybe if you elaborate about the conflict with the use case, someone can validate or point to a flaw in your logic?



I have provided the domain model and the use case above. My question is the domain model is conflicting with the test case from my understanding.

Kindly let me know if anywhere is not clear and need any more information.

Bigwood Liu wrote:from

Request [1:n] Bid [1:1] PurchaseOrder

it is very intuitive that I conclude: Request[1:n]PurchaseOrder, which is exactly:

PurchaseOrder [n:1] Request




These relationship are shown in the domain model diagram.

My question is how to understand the Request [1:n] PurchaseOrder relationship. It seems conflict with the use case above.

Bigwood Liu wrote:

wang xf wrote:Basically, my task a reverse auctioning assignment.

In the domain model diagram, the relationship of Request (I guess it's BidRequest), Bid and PurchaseOrder

Request [1:n] Bid
Bid [1:1] PurchaseOrder
PurchaseOrder [n:1] Request



From text description of the assignment, one Request have only one winning Bid. Bid is a 1:1 relationship to PurchaseOrder. So one Request can have only one PurchaseOrder.

So how could I support PurchaseOrder [n:1] Request in the domain model. I am confused.

Any advice will be highly appreciated.



-"one Request have only one winning Bid"
-" one Request might have one won Bid (I don't know if this is required), but one Request has n Bid is declared", so you can't conclude that 1 Req : 1 PO from combining "one Request have only one winning Bid" and "Bid [1:1] PurchaseOrder" . I don't know the context, but I think you have some misunderstanding here.




Thanks. Bigwood Liu.

The domain model diagram shows the relationship Request [1:n] Bid [1:1] PurchaseOrder [n:1] Request


The following use case are directly copied from the assignment (I have masked sensitive information)

Use Case Specification - Issue PO to Winning Bidder

Brief Description
The Issue PO to Winning Bidder user case allows a XXXX representative to select a winning bid for a specific bid request and issue a PO to the supplier associated with that bid.

Basic Flow
1. The representative searches for closed bid requests.
2. System responds with all bid requests relating to the search criteria
3. The representative selects closed bid request of interest.
4. The representative reviews all bids to ensure that the most valid bid has been chosen.
5. The representative accepts the most suitable bid.
6. The system issues a PO to the winning supplier.


Yeah. It's easy to understand the relationship of Request [1:n] Bid (multiple Bids from different supplieies).

There is nowhere talking about the PurchaseOrder except this use case and the model diagram. My understanding is this use case implies one Request has only one Winning Bid, the representative issues one PO for the winning Bid. So I can conclude the relationship between Request and PurchaseOrder is 1:1. The conclusion conflict with the relationship PurchaseOrder [n:1] Request in the domain model diagram.
Basically, my task a reverse auctioning assignment.

In the domain model diagram, the relationship of Request (I guess it's BidRequest), Bid and PurchaseOrder

Request [1:n] Bid
Bid [1:1] PurchaseOrder
PurchaseOrder [n:1] Request



From text description of the assignment, one Request have only one winning Bid. Bid is a 1:1 relationship to PurchaseOrder. So one Request can have only one PurchaseOrder.

So how could I support PurchaseOrder [n:1] Request in the domain model. I am confused.

Any advice will be highly appreciated.