Confusion. What should be the stopping point? Do we need to show all the class for any patterns uses. It will clutters the diagram a lot. ex: Locator Factory Value Objects Value Obeject Assemblers etc... with all relationships.
Originally posted by H Singh: Confusion. What should be the stopping point?
You should stop when you are finished. It is impossible to give a straight answer to this question. There are too many variables...
Originally posted by H Singh: Do we need to show all the class for any patterns uses.
The point of the assignment is not to use as many patterns as possible. The point is to create a design that is appropriate for the requirements. This may or may not involve the use of all the patterns that you listed. Most people report that they included somewhere between 20 and 30 classes in their class diagram(s). Some create less, some create more.
Originally posted by H Singh: It will clutters the diagram a lot.
If your diagrams are becoming cluttered than you have two choices: 1) Simplify the design. Maybe your diagrams are cluttered because your design is unnecessarily complex, hack out some of the complexity and get things under control. 2) Separate the large class diagram into multiple smaller class diagrams based on the various layers in your design. Many have reported success using this strategy. [ April 06, 2003: Message edited by: Chris Mathews ]
Here are some guidelines and sources that I'm using to address that issue, in addition to the valuable input from folks like Chris who have already passed the certification. The following is a excerpt from the Hints and Tips section of the Class Diagrams chapter of "The UML User Guide" by the 3 amigos. "When you create class diagrams in UML, remember that every class diagram is just a graphical presentation of the static design view of a system. No single class diagram need capture everything about a system's design view. Collectively, all the class diagrams of a system represent the system's complete static design view; individually, each represents just on aspect." "A well-structured class diagram: - Is focused on communicating one aspect of a system's static view. - Contains only elements that are essential to understanding that aspect. - Provides detail consistent with its level of abstraction, with only those adornments that are essential to understanding. - Is not so minimalist that it misinforms the reader about important semantics." Another good source is "Building J2EE Applications with the Rational Unified Process" by Peter Eeles, Kelli Houston, and Wojtek Kozaczynski. Regards, Bill