Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Factory Homes class diagram

 
Oleg Kuzin
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Oleg

Congratulations!




 
William Taylor
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic