posted 21 years ago
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!
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
