• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question on Part II

 
Bijan Mohanty
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Folks,
How detail the class diagrams needs to be ? Do we need to put the exception classes in our class diagrams or not ? Also, if the class diagram gets too big, what are the options of breaking into multiple diagrams ?
Thanks a bunch in advance.
Bijan
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Keep the implementation details to a minimum in the class diagram. Use stereotypes to reduce the clutter - for instance, for EJBs instead of showing Home, Remote and Bean classes, just show the Remote interface with business methods and use stereotypes such as <<entitybean>> or <<sessionbean>>. Although it may be okay to include multiple class diagrams, try to show everything in one diagram. It will just be easy for the evaluator to look at one page and infer your design instead of paging back and forth between multiple diagrams.
As a rule of thumb, exclude anything that is not directly business related. IMO exceptions fall in to this category. They are implementation specific way of reporting an error condition to the user. If the class diagram has anything that is not related to entities represented in the business domain object model, you will have to ask yourself whether it makes sense to show it, and if you decide not to show it, whether it affects the clarity of the diagram.
It may be a good idea to have someone look at your design artifacts once you think they are done - show it to your coworkers or your boss. Give them the overview of the business problem and the domain model, show them the diagrams and see if they can make sense of your design without asking too many questions. This will help you see you works through the eyes of the reviewer.
In general, you have to make sure there is just enough information in the diagrams to be able to map them to requirements and business model. The collaborations indicated should fulfil the stated business requirements.
Good luck!
 
Richard Carr
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For what it's worth, I submitted two class diagrams.
My facade session beans appeared in both diagrams.
The main diagram centred around the domain model classes.
On the second diagram I showed the relationships between various ancillary classes.
I wanted to keep the domain model to implementation mapping clear, but also show significant other classes I thought necessary for the implementation.
BTW, it's four weeks tomorrow, and no result yet.
Regards,
Rich.
 
Bijan Mohanty
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a bunch to both Ajith and Richard. Is it a good idea to place the WAF classes(For example the Front Controller, ScreenFlowManager etc.) in the class diagram side by side with the domain classes(Customer, Account etc) in the same diagram ? What's a better idea if the above mentioned thing is not good.
Thanks.
Bijan
 
Nalla Senthilnathan
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see two kinds of class diagrams beig used in the BluePrints doc:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1a3.html
1. framework class diagram (Figure 17)
2. domain class diagram (structure diagram) (Figure 20)
There would be one structure diagram per module.
Nalla
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic