Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"

rafael liu

+ Follow
since Feb 08, 2009
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by rafael liu

It seems to me the Product should have the price (as it name says, it's a product..), CompletedDesign could have the total sum of its Products.

On the other side we schedule consultations searching "completed" CompletedDesign using the zip code. That way it seems the CompletedDesign should hold the zip code and the price (wouldn't make sense schedule a consultation for a CompletedDesign to discuss only one of it's Product's price). Maybe completedDesign is for cases where we want to build house complexes or condominiums, where we have lots of Houses but at the same place. Still Product is dispensable.. Inputs?
Victor, I came to agree with you. I don't think it's responsability of IS to validate combinations, but I read the assignment over and over again and it seems from that IS is really supposed to do it.

Another thing: what do you get from "filling in required features as necessary (heating, plumbing and so on) to arrive at an indicative cost."? It says the Customer should stablish a cost and the application should expend no more than this. If the Customer enters $1000, ok, we can do all the plumbing and heating, but what if he enters $50? Where should the application save money? Should we cut heating? Fill with a less expensive one? Use less plumbing? It seems this aspect was left to our imagination..
"The Complete House Design use case allows the customer to validate and complete an end-to-end house design satisfying the constraints of the design system" which constraints would these be? From "stock inventory and management system that controls all inventory and valid combinations of inventory in the Factory Homes catalog." I see some guys understood that the system would validate a combination of components for the completed house, but don't think so as it says "combinations of inventory" (which actually i didn't understand, validtion for combination of components in stock?!?). Seems like we have to have a rule component that knows which combinations are OK.

what do you think?
I thought about making them persistent. In the Complete House Design UC, there's a step "Customer changes status to completed.", so "open" design would be the same, only with different status.
I see your point. But Inventory could be used for another kind of application, like a Home Center store, this way I think it should only deal with components, not the House itself. Another thing about the House being stored in the Inventory System is that it's not actually "in stock", there is no count, there isn't even the real House built.

Yes, communication would be more chatty. But one thing: how do you understand the the Inventory System would check valid combinations? Probably the IS has to know about component characteristics in order to check compatible combinations between them, that way the component representation should be stored in the IS. (or maybe some dumb logic like A doesn't go with B? maybe I'm complicating things but what about Wall that can't be make of concrete if the Foundation aren't waterproof?)

I like the idea of IS holding business logic while the database holds data, but IS is actually a system itself, not just a layer of our application.

Maybe a middle term: the inventory has the components but once we got it we replicate it on the application's database.
Victor, I do think "Customer selects a house design" is from their own "open" designs. He selects it and click conclude. From the phrase "customers to add a selected, valid component to their current house design" I understand that he has a lot of open designs and he "selects" one to be the current one, then add/change (can it be changed? there's no UC..) components. Then, from this point of view there wouldn't be pre-built models.

The company has recently invested in a state of the art stock inventory and management
system that controls all inventory and valid combinations of inventory in the Factory Homes
catalog. This system is accessible using a well-defined set of web services.

I was designing it as a subsystem that would store and retrive components for me. The Wall, Door, etc in my application would be just for binding the Web Service response into a POJO, it wouldn't be store in my data base. The House, Product, etc would be in my data base only with references to its components.

I don't see how it would work if this system was only for validation.. You would pass a set of components combination just to check validity?
That's the way I understand the BDM, please comment:

House: the house, object.

Product: the house for sale, include price and stuff.

CompletedDesign: is the user interaction with the system. In this interaction he can build as many houses as he wants.

The 0..* ending of the 0..* - 1..* association between CompletedDesign and Product doesn't make sense for me. How can a house exist without a corresponding Product/CompletedDesign? I only see it possible if pre-built House exists, but the way I understand the Customer will build custom houses from Components in the Inventory and another Customer won't be able to select the same house (he can build a similar instance only). Even if there was the possibility of choosing pre-built Housers, there isn't a Use Case where it would be picked.

About your BDM, mine is practically the BDM in the assigment.. I read that only domain classes should be included but I'm thinking about including my Facades, DAOs, etc.. What are you guys doing?
Wow, that's weird, my reply appeared as an edit of yours..

I wrote:

CompletedDesign is for me an "interaction with the system", this way in the same interaction the Customer can build 2, 3, * houses. Anyway, I'm changing this domain model..

In your understanding the House itself would be in the Inventory System?
That's what I thought at first, but there's no way to have a Product without a CompletedDesign, there simply is no Use Case that would build a Product without creating a respective CompletedDesign. And even if it had, there is no Use Case that would pick this pre-built house.

CompletedDesign is for me an "interaction with the system", this way in the same interaction the Customer can build 2, 3, * houses. Anyway, I'm changing this domain model..

I think the relation should be 1-* to 1-*, I doesn't make sense to have a Product without a CompletedDesign. It would be ok if there were a "house propotype hall" from which the user could pick an already made house..