• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

Class Diagram: Stopping point?

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 ]
 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
I can't beleive you just said that. Now I need to calm down with this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic