aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Factory Homes class diagram Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Factory Homes class diagram" Watch "Factory Homes class diagram" New topic
Author

Factory Homes class diagram

Oleg Kuzin
Greenhorn

Joined: Feb 16, 2009
Posts: 10
Hello everybody.
I've recieved my part2 score recently where I got 0 (zero) for class diagram with the diagnosis "class diagram catastrophically incomplete".
I can't imagine what else should be there. So please help with a good advise or idea. So:

The main idea of my design was to support new components without any code updates. The core of object model is just a single class Component which represents a hierarchy of other components (so it is basicly the tree). Every component contains at least component id (details and other stuff are lazyly fetched). So the root component has the component id which is the id of current design. With this recurse definition of component we need only one class to represent a wall, a basemant, a door, a part of house or the whole house, or even a city With this organisation my system can construct everything that is in inventory management service (even a starship ). The thing to be persisted is a mapping between (design id + completness info --> customer). I have this persisted as JPA entities.

I also provided all the needed DAO objects as well as business logic tier objects + JSFs and mbeans with all the needed methods + visualisation tool interface. Having maximum points for component and sequence diagrams I'm trying to understand what I did wrong there.

So actually, I'm 100% sure my system works (with more then 8 years of building j2ee applications I can say when I'm right).

So could anyone give any clues what do Sun guys expect me to do here...

Thank you in advance
OK
Victor-OE Cardona
Greenhorn

Joined: Jun 29, 2006
Posts: 29
Hi,


I know what you mean, you decided to work with the composite pattern, i don't see any problem if you depict in your composite classes wich ones is the composite (house, Aperture component), and which ones are the leafs (Wall, Roof, etc).

did you depict this kind of structure?
Oleg Kuzin
Greenhorn

Joined: Feb 16, 2009
Posts: 10
Victor-OE Cardona wrote:Hi,


I know what you mean, you decided to work with the composite pattern, i don't see any problem if you depict in your composite classes wich ones is the composite (house, Aperture component), and which ones are the leafs (Wall, Roof, etc).

did you depict this kind of structure?


No, I did not. Component class represents all types of house parts and their combinations. So derived classes are not needed. This gives a huge advantage as you don't have to implement anything new when new component type (for example, roof chimney or pool in the garage ) appears and everything works.
I spend a day trying to get what they need more and, yes, I think that they expect me to make all this classes for the composite. BUT in fact they are not needed and will only reduce the flexibility of the SuD.
I think guys from Sun just didn't have time to get the idea. As the model is too small and simple and , I bet, differs from the typical solution they just said "too small" Not having shown what required fetures my SuD does not support.

I'm not sure what to do now... I bet they won't check the solution again more carefully, so I need to fix the solution to the way I consider to be not optimal and effective? Any ideas?
Victor-OE Cardona
Greenhorn

Joined: Jun 29, 2006
Posts: 29
Hi Oleg.


"BUT in fact they are not needed and will only reduce the flexibility of the SuD."

I think is needed to depict those classes in your diagram in order to let the designers and developers to know that the composition is about house or buildings. I think that it is not going to reduce the flexibility because using the composite patterns makes the application open for extension (add the pool later)
Oleg Kuzin
Greenhorn

Joined: Feb 16, 2009
Posts: 10
Victor-OE Cardona wrote:Hi Oleg.


"BUT in fact they are not needed and will only reduce the flexibility of the SuD."

I think is needed to depict those classes in your diagram in order to let the designers and developers to know that the composition is about house or buildings. I think that it is not going to reduce the flexibility because using the composite patterns makes the application open for extension (add the pool later)


That was the point not to add anything later as all SuD uses is data from Inventory System. If
But anyway I'll make a resubmission with this changes although I will still consider my first solution to be correct.

Thank you, Victor, for your help. I'll post my result (hopefully good) here when I get it.
Cheers
William Taylor
Greenhorn

Joined: Feb 11, 2009
Posts: 15
Shall we put JPA entities in the component diagram? I think it adds too much detail, however, the requirement asks to show major POJOs in the Component Diagram.

If it is necessary, what the dependencies? Let EJBs depend on entities, then entities depend on the external inventory system looks weird...

Any suggestion? Thanks a lot.
Oleg Kuzin
Greenhorn

Joined: Feb 16, 2009
Posts: 10
William Taylor wrote:Shall we put JPA entities in the component diagram? I think it adds too much detail, however, the requirement asks to show major POJOs in the Component Diagram.

If it is necessary, what the dependencies? Let EJBs depend on entities, then entities depend on the external inventory system looks weird...

Any suggestion? Thanks a lot.


Make it simple: just use <<Entity>> stereotype. And leave implementation details to other team members. <<Entity>> shows that class is a part of system tesaurus so persistence is another question
Prashant Purkar
Ranch Hand

Joined: May 08, 2008
Posts: 84
Hi Oleg,

Wouldn't it put too much information in component class if it represents everything.

Like only design can have state of completion while no other component has that.


William , in component diagram you can show a component named JPA entities and that should be OK.

Also you can mark each entity with <<@Entity>> to show entity annotation, a hint for developers that JPA is used.


Thanks
P
Oleg Kuzin
Greenhorn

Joined: Feb 16, 2009
Posts: 10
Prashant Purkar wrote:Hi Oleg,
Wouldn't it put too much information in component class if it represents everything.
Like only design can have state of completion while no other component has that.


The only thing needed is the component id. All other details will be fetched from in a string form in ComponentDetails value object as a response from inventory system
Cheers
Oleg
Victor-OE Cardona
Greenhorn

Joined: Jun 29, 2006
Posts: 29
Hi Oleg.

What you mean is that the component description is store in the Inventory System ?

why we can't load the component's details from the data base ?

Oleg Kuzin
Greenhorn

Joined: Feb 16, 2009
Posts: 10
Victor-OE Cardona wrote:Hi Oleg.

What you mean is that the component description is store in the Inventory System ?

why we can't load the component's details from the data base ?



Hi Victor.

Yes, in my solution component description is stored in the Inventory System. We can store details in database, but this means synchronization need between our database and Inventory System which makes these two systems more coupled.

This is my view of the problem, if anyone has other ideas it would be very interesting to discuss them.

Cheers
Oleg
Prashant Purkar
Ranch Hand

Joined: May 08, 2008
Posts: 84

Synchronization wouldn't be required if a component in the inventory system changes, its ID is changed as well.

One question regarding the component diagram, is it ok to show abstract classes as interfaces in component diagram?
With interfaces one get those ball and socket notation in a diagram.
I actually wanted to use interfaces in the first place but jpa doesn't support interface inheritance so I have to use abstract classes.


Prashant
Oleg Kuzin
Greenhorn

Joined: Feb 16, 2009
Posts: 10
Prashant Purkar wrote:
Synchronization wouldn't be required if a component in the inventory system changes, its ID is changed as well.

One question regarding the component diagram, is it ok to show abstract classes as interfaces in component diagram?
With interfaces one get those ball and socket notation in a diagram.
I actually wanted to use interfaces in the first place but jpa doesn't support interface inheritance so I have to use abstract classes.


Prashant


JPA class is an interface to a component? O_o
Oleg
Oleg Kuzin
Greenhorn

Joined: Feb 16, 2009
Posts: 10
Hi all.
I've just got a P status after resumission which means I'm SCEA now. Although I consider my first solution to be better than the resubmitted one.
Thanks to everyone who shared their ideas and thoughts.
Cheers and good luck!
Oleg
Victor-OE Cardona
Greenhorn

Joined: Jun 29, 2006
Posts: 29
Hi, Oleg

Congratulations!




William Taylor
Greenhorn

Joined: Feb 11, 2009
Posts: 15
Oleg Kuzin wrote:Hi all.
I've just got a P status after resumission which means I'm SCEA now. Although I consider my first solution to be better than the resubmitted one.
Thanks to everyone who shared their ideas and thoughts.
Cheers and good luck!
Oleg


Hi Oleg,

So house itself is a composite component in your design? Do you think components like Foundation and walls are products themselves? Thanks a lot.
Prashant Purkar
Ranch Hand

Joined: May 08, 2008
Posts: 84
Hi ,

I have also received the similar feedback for my class diagrams, having been given maximum marks for component/sequence diagrams.

I have separated class diagrams in different web,business,model diagrams with separate links to each of them on the index page.

While investigating what could have gone wrong i have found very few obvious mistakes in class diagrams like get method returning void but how does everyone put class diagrams ? Just one Link/html page for all class diagrams?

In that case how does one show package info, is it mandatory to show class distribution in packages?

Thanks in advance.
Prashant

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Factory Homes class diagram