Factory Homes Assignment

[Prashant Purkar]

Its correct.

Prashant

[Eoin Li]

I did as you said that exactly -- that is my udnerstanding.

[Gautam Ssingh]

Thanks for reply. I will then consider using builder for this pre-existing houses. I am still confused on product. In my understanding, product should be a pre-existing base house and all added components however I am unable to undertsand how would system will give a price for n products in "complete design" use case. As per this use case, system should add all extra (heating plumbing) and provide a cost for house. If cardinality is * then, should it add all houses cost while providing that.
Thanks
Gautam

[Wilmar Rodriguez]

Factory Homes...Factory Homes...Factory Homes
When I saw this assignment for first time last year i thought 'It's so easy...piece of cake'. But when you develop entire assignment and re read the pdf and revise it, a lot of new ones things are necesary, for example more use cases. The domain model is so confused, i thought Complete Designs, Product, House??? What the hel....
I recommend to all new SCEA assignments workers 'DOCUMENT YOUR ASSUMPTIONS' in the index.html.
Be careful with requirements like 3DModeling tool preview. It's a show stopper requirement. If you think that the 3DModeling tool is Adobe Flash plugin that reads the generated XML from B2C Factory Homes App, It's Ok. 'DOCUMENT IN YOUR ASSUMPTIONS'. Also include in your sequence diagrams.

Don't Be lazy!!!

Thanks,

Wilmar Rodriguez C
Project Manager Professional(preparing), SCEA5(Factory Homes Assignment) , SCEA OLD (Flight By Night Assignment), SCBCD 5, SCWCD 5, SCJDWS 5 , SCJA, etc etc etc etc etc.......

[Gautam Ssingh]

Wilmar,

Yes, you are right, domain model is very confusing, specially product-completeddesign. I am unable to understand under what business circumstances multiple product will be part of a single completed design. if we select new product and complete the design, it makes more sense to create a new CompletedDesign object rather than asking user to associate with an existing one. I can imagine if same product with slight modification can be considered different completed design. I think I will just draw this cardinality without giving it too much importance.


Thanks
Gautam

[Prashant Purkar]

Hi Guarav,

" I am unable to understand under what business circumstances multiple product will be part of a single completed design. "

Imagine you are building a twin bunglows of the same house type , the architect of the bunglow will design the bunglow only once. That meaning inventory system will have only one design details of the bunglow.

But application can have a complete design with two such bunglows of same house type, so a complete design can be of twin bunglows or single bunglow. Hence design can have multiple products.

I hope that helps in understanding.

Thanks
Prashant

[Ilya Yamalan]

Hi Guys!

I'm working on my Factory Homes assignment and search for somebody who works/worked on it too. I confused by [House 1 -- * Wall] and [Wall 1 -- * Apperture] relations. My question is about GUI and system flexibility implied by this relations. I see two approaches:

1. Customer has rich, CAD-like interactive interface which allows to manipulate each wall/door/window separately. Pros: It meets Business Domain Model and flexibility requirements. Cons: It contradicts with use cases because of customer should simply "select and add" item to his design. Customer must specify exact wall position in this approach before system can validate design.

2. There are predefined sets ot walls/doors/windows and customer simply selects such set (i.e. planning). Pros: It's simple and meets use cases. Cons: This approach isn't flexible and slightly contradicts Business Domain Model because customer can't manage [House 1 -- * Wall] and [Wall 1 -- * Apperture] relations fully.

Could you please advice me which approach is most appropriate?

Thank you in advance.

[carmine joint]

Hi guys
I just begin to working on my Factory homes assignment. I read the assignment yesterday, lots of things confuse me, I will double read it today. And I still not decide to use the Spring or EJB. I think EJB will bring the unnecessary difficult on deployment, but its a SUN certification. You know my means:).
Please give me some advise on it.

Thanks,
Archer
[e-mail]

[Rodrigo Lopes Ferreira]

Hi Ranchers.

In my opinion, "Foundation", "Wall" and "Roof" are subclasses of a new class "Component". The "Component" defines the basic behavior for all components. I created a "HouseStyle" as an enum, to represents all houses styles allowed. All components has a "AllowedHouseStyleList" that defines of what house style the product is allowed. By this manner, the "StockInventorySystem" can receive a only house object, that contains all "Components" and your allowed house styles... The system must have a "User session control" (by HTTP Session, ou Stateful Session Bean) to control the actual and not finalized house design. And... I think that a pre-requisite for all use cases are the user be logged, created a new house and selected a houseStyle to the house to start the selecting components.

This is a little of my understand about this problem.


[]'s

[vikram kumar]

Hi Ranchers,

I have come with a different idea about the competed design -> Product-> House, relations.

According to my understanding there is no need to change the relationship that’s given in the BDM, every Completed Design may have 1…* products involved, here the product is not the House as such and products are nothing but the different House components manufacturers (Brands) who produce different components. So one Completed Design will consists of one to many Products House components.

I am not sure of this unless you guys agree with this approach.

Regards,
kumar

[vikram kumar]

I am worried that there is no response for my thought, I will happy even if some one says NO for my idea. Guys please speak out.

Regards,
Kumar

[Prashant Purkar]

I think product is a house or a building etc.. and it has components.

So instead of Design -> Produc House Component

it is Design - > Product -> Components

Regards

Prashant

[vikram kumar]

Thanks a lot Prashant, agree with what you said.

Regards,
Ramesh

[Gautam Ssingh]

I have received an email from Sun that I passed SCEA 5 (amazingly within 5 days after part 3) . Factory Home assignment was very confusing, thanks to everyone for clarifying several doubts.

Gautam

[Prashant Purkar]

That's very quick. Congratulations!!!

[vikram kumar]

Congratulations Gautam

[solder Job]

Hi i am on the SCEA5 assignment on factory homes too.


May i ask whether i can use J2ee 1.4 to represent my architecture?

Secondly, may i know how to come out with the deployment diagram ?

tks

[chiku awasthi]

HI ,
As the inventory has the knowledge of all the valid combinations and House designs , is it the responsibility of Inventory to create the house or should the factory Homes application refer the design ( Which is obtained from Inventory ) and take individual components from the Inventory and construct a House .

Thanks,
Chiku.

[emanuel petre]

why? In the old book of Mark Cade there is a study case where is written explicitly that the given use cases are the only ones that should be considered.
In the Factory Homes instead, it is said that the given use cases are the main ones, resulting after "a first pass at the use cases", so considering this, I think that one can add use cases in the diagram.

[emanuel petre]

Victor-OE Cardona wrote:Hi,

No, you don't have to add new use cases and you can't modify the existing ones.

why? In the old book of Mark Cade there is a study case where is written explicitly that the given use cases are the only ones that should be considered.
In the Factory Homes instead, it is said that the given use cases are the main ones, resulting after "a first pass at the use cases", so considering this, I think that one can add use cases in the diagram.

[Ashu Sharma]

In my view i think we can not add use cases because use cases are handed over by business and can't be added by Design team at will.
In the second pass the Business team might come up with the additional use cases and then Designer/Architect can model them.

[emanuel petre]

Ashu Sharma wrote:In my view i think we can not add use cases because use cases are handed over by business and can't be added by Design team at will.
In the second pass the Business team might come up with the additional use cases and then Designer/Architect can model them.

In my opinion the use cases are result of analysis and are part of the design and in the real life an architect may participate actively together with stack holders and business analysts to reveal these use cases. For the simplicity of the exam, these use cases are already provided. Yet, having a batch of use cases normally doesn't mean that an architect cannot add some others (of course after discussion with the appropriate parties) during the design phase. Personally I would try to resume to the provided use cases as much as possible. But, depending on the situation and if is not explicitly required, I can thing to add some other use cases. The authors specify that the provided use cases are the main ones, so in fact there are more, starting with the login use case. For sure I will not add this one in my solution, anyway. Think in turn to add some other secondary use cases.

[William Taylor]

Finally I submitted my assignment and got SCEA 5 certified today!

[Prashant Purkar]

Congratulations William!!!

Prashant

[Riyaz Enayath]

I also received the Factory Homes assignment. Please correct me if my understanding about the business problem and use cases are wrong.

Before started selecting component,
customer has to begin with CompletedDesign instance(with composition of product,which is house) based on the existing housestyle chosen,
UC-1. Select the component (search component catalog use case),
UC-2. Add the component(once wall,roof availability and its combinations are validated) to selected house design.
UC-3. Once the base components of each product(house) association with CompletedDesign is done, customer will say “completed”. The system will calculate total cost for the whole design with basic features(plumping,heating) included. The total cost should not be exceed the indicative cost which customer specified at the beginning of the house design(?).

In UC 1, "Systems responds with the product detail and availability/applicability of the product, based on the current house design”. My understanding is Inventory System will retrieve the component details(size,price,etc) for the selected one.

Accessories/components are mentioning wall,roof,etc. A House should have at least basic components with one house style chosen.

Valid components for house styles and accessories/components(wall,roof,etc) and will be checked against ISM webservice. ISM just holds business logic and components and house styles would be persisted in DB.

In UC3, “required features as necessary (heating,plumping and so on) to arrive at an indicative cost”. Indicative cost is specified by customer at the beginning of the house design.

There is no use case mentioned where the customer is initiate (new registration "CompletedDesign" request) the house design. Please clarify.

In NFR, There is no constraint specified on development time and cost allocation for the design. Can I make assumption like this design should be high scalable, unlimited users in future(at presently 200 concurrent users maximum)?. Desired technology to meet NFR is JSF,JPA,EJB3 combinations.

Please share your inputs and experience.

Regards,
riyaz

[Volker Abel]

Hi there,

I am a bit confused... I am wondering why the usual "first rule of SCEA is: don't talk about the assignment. second rule of SCEA is: don't talk about the assignment" isn't taking place.

Is the "Factory Homes Assignment" not a real assignment? (Which I cannot know, because nobody talks about assignments... )

Cheers
Volker

[Yanzhong Liang]

I got this assignment too. I am very confused on how to validate a design or component. any idea?

Thanks,

Joe Ng

[praveen Ji]

First, thank you all for such informative discussion. I had the similar doubts about CompletedDesign, Product and House.

Having read the thoughts above and analyzing the given requirement specs, my understanding is:

Product is a generic term used to represent anything that is available for sale. I see this from an e-commerce web-site perspective.
In case of FactoryHomes, their product is a House.

On the other hand, CompletedDesign is a sort of online purchase order, and hence has details like:

What is being bought (Comes from House design, that user has assembled)

What is the price (Comes after customer changes the house design status to "Completed" )

Who is buying (Comes from Customer association)

Please share your views.

[praveen Ji]

Duplicate reponse.

[praveen Ji]

Sorry guys. Its duplicate post again. I am not sure wats going on.

[mario buonopane]

Gautam Ssingh wrote:Assignment mentions that "company plans to launch this program with a limited number of valid combinations for house styles and accessroies"

Doesn't this imply that inventory system is aware about all fixed house styles and component which can be added to this particular house style.

My understanding is customer has to choose an existing house style and system should be able to construct a dwelling and add wall, aperture etc as per selected house style.

Once this house object is available, customer can start use case for select, adding components.

Please let me know if my understand is wrong.

Thanks
Gautam

What i don't understand is what component i can add if selecting an house style the system build an house object completed of all components(walla, roof, foundation and aperturas).

[Krzysztof Koziol]

Rodrigo Lopes Ferreira wrote:Hi Ranchers.

The "Component" defines the basic behavior for all components. I created a "HouseStyle" as an enum, to represents all houses styles allowed. All components has a "AllowedHouseStyleList" that defines of what house style the product is allowed. By this manner, the "StockInventorySystem" can receive a only house object, that contains all "Components" and your allowed house styles...

[]'s

Does it mean that you have to synchronize your components and their allowed styles between Factory Homes DB and "StockInventorySystem" (let's say once per day) and then web-service call is used to check the component availability?

What about component category list? Can we assume that list doesn't contain to many records and will be fetched each time form IMS?

Regards,
Krzysztof

[Dannyf Soon]

Prashant Purkar wrote:I think product is a house or a building etc.. and it has components.

So instead of Design -> Produc House Component

it is Design - > Product -> Components

Regards

Prashant

Hi Phashant, Ranchers,

According to the workflow "(After user selected a specific component...)System responds with the product detail and availability / applicability of the product, based on the current house design.", system responds with product information for the selected component. Dose it imply that component is product too? In this manner, house is also a product, composed of component products.

Agree or disagree with me?

Looking forward to your response.

Thanks a lot!

[Dannyf Soon]

Prashant Purkar wrote:I think product is a house or a building etc.. and it has components.

So instead of Design -> Produc House Component

it is Design - > Product -> Components

Regards

Prashant

Another question of mine is regarding where to put the House object. Since a house is a product (vice versa), they're equivalent of each other. Then, where to put House in the class diagram? Does it also need to take part in the sequence diagram?

Thanks in advance!

[Andrew Monkhouse]

Dannyf Soon wrote:Another question of mine is regarding where to put the House object. Since a house is a product (vice versa), they're equivalent of each other. Then, where to put House in the class diagram? Does it also need to take part in the sequence diagram?

That would be a good question to ask your architect.

I'm closing this topic now since it seems to drift regularly from discussions about the domain, into discussions about solutions.