Dreamcar DestinationMarket and marketplace

[Ronald Wouters]

Hi,

I just re-read the "Workshop Output" section again for the millionth time and something new occurred to me, go figure :-)
In the business domain model a CarModel is linked to a DestinationMarket.
However the "marketplace" the workshop output is referring to seems to actually be the eCommerce website on which the requests are "posted" and not geographical locations (countries, regions). What if the DestinationMarket in the BDM is in fact a "marketplace" as defined in the workshop ? You could argue that Dreamcar uses different marketplaces, some for blind auctions, others for open international auctions and yet others for local auctions without international bidding. If you interpret things this way, it actually makes sense having the DestinationMarket in the BDM although it is not mentioned explicitely in the usecases. It is just the "instanceof" the particular eCommerce website that will handle that particular Request's bidding. This would also mean it would make no sense having a DestinationMarket as a kind of search criteria I think.


Your thoughts ?

Regards.
[ December 07, 2008: Message edited by: Ronald Wouters ]

[Arvind Tiwari]

Hi Ronald,

Are you still working on this project?

If yes lets start working on it.

Thanks,
Arvind

[Ronald Wouters]

I am indeed still working on this project. I have just one use case / sequence diagram to complete. Then I can make the final updates on my component diagram. I haven't started yet on the deployment diagram because I feel you need to have the component diagram finished before it makes sense doing the deployment diagram, although I already have a picture in my mind of how it is going to look like, I think
I hope to complete the assignment and submit it in a couple of weeks time, fingers crossed
By the way, the "brainstorm" I had in the original posting about the destinationmarket and marketplaces, I abandonned that idea completely.
Let's make sure we stick to the rules though about disclosure of assignment information.

[Arvind Tiwari]

Thanks Ronald for the prompt response, I will assure that we will discuss the project within the rule. Feel free to point me if I violate the rules.

I also have done something (class diagram, component diagram and sequence diagram) but got some confusion as following, please share your views.

1. How to show (class diagram/component diagram) that my design is extensible?

The BDOM is showing three classes (Brake Pad, Brake Discs, suspension) but we need to make the design extensible." with additional part types coming in later phases."

In my opinion, if there is one more part them there will be one more class added in the class diagram and there will one more master table (i.e. headlight master) in the database.
(Sorry I am thinking the implementation)

As per following comment to address extensibility but that violates the OO design, you should have specialized classes for specialized part.

"Pratik Das: I have replaced the three parts with a single class part type but I have not used the enumeration. Using enumeration will entail changing the class model each time we add a new part type."

2. Why we need to initialize all the part type object, all we need is the part specification in the request object and quantity?

3. For the 1st use case, are we going to have multiple part types in single request o?
Then only we can justify 1-* relation between request and PO but if the request will have single item then it is in correct.

[Arvind Tiwari]

Hi Gurus,

Are you guys are planning to apply any core design pattern?
Please share your ideas.

Thanks,
Arvind

[Unnikrishnan Nair]

I hope core design patterns can be included as required in the design. But dont try to include them for the sake of including them, if you see it has visual advantages, you should... My perspective