• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Showing Entity in class diagram

 
Ashu Sharma
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers,
I have one confusion regarding how to show the Hierarchy of the Entities in Class diagram.

For Example Class Wall(which is marked by stereotype<<entity>> extends the more Generic class Component.Should i mark Component also an entity or only the concrete class has to be shown with stereotype.

Thanks
Ashu
 
Ashu Sharma
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear Ranchers,
Maybe i was not clear in my previous post so i made a quick diagram.
Please guide me if figure A or Figure B is the right representation

Thanks
Ashu
class_22.GIF
[Thumbnail for class_22.GIF]
 
Vivekanand Apuri
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Fig A makes sense as you are using <<entity>> steriotype
 
Ashu Sharma
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vivek,
Thanks for your comment.

Vehicle is an abstract class( in Italics). Should it be marked as entity?.
What if we are following the Table per Concrete class approach in JPA.

Thanks
Ashu
 
Prabu S Arumugam
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What if we are following the Table per Concrete class approach in JPA.


The class diagram, ideally.. should look technology independant.
The component diagram can be loaded with all the J2EE components and concepts.
Class diagram is your (Object oriented) break down of the 'requirements'.
Component diagram is your medium to say how you are going to 'implement' it.

Table per concrete class or Single table is an implementation detail.
 
Vivekanand Apuri
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Prabu,

Point on component and class diagram are definetely makes sense if OO technology is determined and homogenious, but incase of same component implemented differently then showing all posibilities is difficult. Ex. A web component is set of J2SE+StrutsOrSpingMVC, Hence i would suggest where possible we can make use of UML notation (sterio types). Having said that we shouldn;t overdo UML diagrams, best is leave it with documentation/notes. Some times its possible that these technologies are choosen based on experience with team and compliance decisions, hence mayn;t be feasible to dictate technolgies in all cases, as an Architect it makessense to set direction and give attention to critical components HL design

"What if we are following the Table per Concrete class approach in JPA."
You can say parent class as <<abstract>> and notate child classes as <<entities>>

Regards,
Vivek.
 
Prabu S Arumugam
Ranch Hand
Posts: 49
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vivek,

"What if we are following the Table per Concrete class approach in JPA."

To me, this is a candidate for the class diagram to show your Inheritence strategy for Entities.
A note in the class diagram can say if its going to be single table or table per concrete class.
But the component diagram may not be the right placeholder as we try to document J2EE components (JSF, EJB, etc,.) in the component diagram.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic