• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

Part 2: should class diagram reflect non-business domain areas

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Should the class diagram for part 2 also reflect the classes that do not map
to the business domain. e.g Session Beans, Service Locator, MVC classes etc.
Further, does the class diagram for business domain need to indicate actual
implementation classes(like extends javax.ejb.EntityBean) .
[ April 01, 2004: Message edited by: sriram ]
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for joining JavaRanch.
Unfortunately your name violates our naming policy. Please take a quick look at the rules and edit your profile accordingly.
Thank you!
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Should the class diagram for part 2 also reflect the classes that do not map
to the business domain. e.g Session Beans, Service Locator, MVC classes etc.


You may omit framework components such as Service Locator, MVC implementation etc in the class diagram and show them in sequence/component diagram. However, I do not think Session Beans can be treated the same way. Session Beans normally model business processes and therefore correlates with domain concepts. So don't omit Session Beans.


Further, does the class diagram for business domain need to indicate actual
implementation classes(like extends javax.ejb.EntityBean) .


Yes, class diagrams should not only reflect your analysis of the domain model, but also refer to certain implementation choices - session bean, entity bean, POJO, helpers etc. There are two ways you can represent the implementation specific details. You can include J2EE specific classes in your class diagram, or you can use UML stereotypes. The former option tends to clutter the diagram.
Hope that helps,
 
sriram ramanathan
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ajith Kallambella:

Yes, class diagrams should not only reflect your analysis of the domain model, but also refer to certain implementation choices - session bean, entity bean, POJO, helpers etc. There are two ways you can represent the implementation specific details. You can include J2EE specific classes in your class diagram, or you can use UML stereotypes. The former option tends to clutter the diagram.
Hope that helps,


Thanks!! That is useful information.
[ April 02, 2004: Message edited by: sriram ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic