SCEA part 2 : a question of domain model

[wang xf]

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.

[Bigwood Liu]

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.

[Bigwood Liu]

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

[wang xf]

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.

[wang xf]

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.

[wang xf]

can anybody help?

[wang xf]

can anybody help?

[Jeanne Boyarsky]

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?

[wang xf]

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.

[Jeanne Boyarsky]

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?

[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.

[Rajiv Shr]

Wang,

Since this is an exam question, not sure if someone can answer this completely without doing part of the assignment for you. So let me give you this hint - Yes, your question is correct. I had the same doubt as I got the same assignment. You are the architect. There is a design assumptions section allowed in the assignment, where you can state why are you are doing things a certain way. Use it

- Rajiv

[Jeanne Boyarsky]

wang xf wrote:My question is the domain model is conflicting with the test case from my understanding.

I see. You meant "use case" rather than "test case." If you see a conflict, assume one is correct, document in your assumptions and design according to that assumption. It is ok to say you assumed the client made a mistake in the use case.

We aren't going to be able to go into any more detail here though. Sorry.

[vivek srivastava]

I am not sure if this help you but one way to understand could be like this:-

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

One request contains multiple binds, and each bid is associated with a purchase order(please mark that these are not the winner purchase order, you can assume that each bid consist of a bid details and a purchase order detail). When a bid wins corresponding purchase order is selected as winner purchase order.
The point is that don't think purchase order as the winner purchase order. its like each bid document consist of two part, bid details and purchase order details.

[Bigwood Liu]

I Got it.

There is a logical flaw here:

bid != winning bid, while the assignment seems assume that bid = winning bid.



I would contact the oracle test center first;

if (I got answer) {
if (what is in assignment is wrong) {
act according to answer;
return;
}
}

assume flaw in assignment;

[Purna Manepalli]

Hi Ranchers,

I would like to restart this thread after a long time, because now i am in same situation.

I echo with vivek srivastava's comments. As per this assumption, there will not be any changes required in either DM or Use Case.

Please share your comments.

Thanks in advance.