This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Answers to this question are going to have to be very high level as we are not allowed to discuss specific assignments in the forum.
You are allowed to change the business domain model. Reasons should be justified and it is recommended to change it as little as possible. The reason being if the reviewer disagrees with your change, you have a problem.
Personally, I would recommend against changing something that fundamental to the business.
I agree with you. I got the same assignment and had trouble wrapping my head around why the business domain is set up that way. But I wanted to follow the advice about not changing it too much. So eventually I documented my understanding of their business domain model and ran with that.
I am also working on the assignment. I also feel the domain model should not be modified, there should be a reason for the relationship and its cardinality.
The biggest doubt I have about this assignment is, they say visual appeal is very important criteria for the customer and none of the use cases talk about providing a visual output to the customer. In the forum, people advice just solving what is being asked in the use cases.
Main priority for the customer is Visual appeal of the house design. But the use case doesn't ask about it. Does it mean that the showing the house design visually to the customer is part of big picture which will be addressed in some other use case and we need not worry about it in our solution.
Joined: Nov 27, 2010
OK, I will reflect on that model and try to find the best suitable solution.
Dinesh, I do think that we have to model ALL requirements, use cases or not. It's only a matter of details. The use cases should be modeled more detailed than other requirements.