aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Class diagram Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Class diagram" Watch "Class diagram" New topic
Author

Class diagram

Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Does the class diagram capture all the classes in the system?


Groovy
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Most probably not - depends on what you are drawing it for.
What are you drawing it for?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

If all classes are not displayed then how will the programmer be able to use the class diagram to create classes?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
If all classes are not displayed then how will the programmer be able to use the class diagram to create classes?

This is again a question of how one intends to use UML. If you're just designing with UML, the developers only need to communicate using UML diagrams and they can leave the obvious transfer objects, etc out of the diagrams to improve the efficiency of communication. The developer will know how to glue the overall design together by adding the details on the fly. If you're using UML as a programming language, you need to tell the tool everything so that it can generate working code for you.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Pradeep Bhat:
If all classes are not displayed then how will the programmer be able to use the class diagram to create classes?

In the same way they would create classes in the diagram - by thinking about which classes they will need. Actually I think this is often easier to do with code, because in fact it *is* the code which needs the classes, not the diagram. Drawing classes in diagrams *always* is somewhat speculative (unless, as Lasse pointed out, you use UML as a programming language).
In my humble opinion, the true strength of UML is being able to *abstract* from the code. When doing this, I want to filter classes from the diagram which I don't need to make my current point.
Did that help?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

In the same way they would create classes in the diagram - by thinking about which classes they will need.

Each one will have his/her own way of defining i.e. some attributes/methods may be missed. I had faced that problem some time ago.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Pradeep Bhat:

Each one will have his/her own way of defining i.e. some attributes/methods may be missed. I had faced that problem some time ago.

Interesting. Can you elaborate a little bit? What happened?
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Foe e.g. Some guys used long for some attributes when it was supposed to be int.
Every one had they own way of interpreting the domain knowledges.
It is really a long story.
Allan Halme
Ranch Hand

Joined: Aug 22, 2003
Posts: 62
Lasse's distinction between designing in UML as opposed to programming in UML is crucial.
A good example: if you're programming in UML and you want an EJB, you'll need to specify all the ancillary interfaces in addition to the component class itself, whereas if you're designing in UML (which is what I do -- I program in Java), then I find it sufficient and significantly more clear to just draw a single class, give it the name that the remote interface will eventually have, and give it an "EJB" stereotype.
Class diagrams that pedantically include all the EJB interfaces are often just cluttered and detract from the understanding of the system that a parsimonious diagram can convey.


<i>The lyf so short, the craft so long to lerne.</i> --Geoffrey Chaucer (c. 1343-1400)
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
A model is generally at some level of abstraction - leaving out details to better communicate the big picture. A model that captures 100% of the details (say reverse engineered from source) may not communicate large-grained concepts any better than the code itself. So models and diagrams rarely have EVERYTHING.
A neat concept that I learned with Rose but applies everywhere is to separate the model from the diagram. The model is all the information you know or have recorded about a system - all the classes, relationships, etc. A given diagram shows a subset of the model with a specific communication goal. So if your goal is to explain a particular class or subsystem to someone, a class diagram with only a few related classes would be perfect.
An advantage to using a tool like Rose instead of a whiteboard is that all diagrams are views of the same model and are much more likely to be consistent. If a class appears on several diagrams, you KNOW it's the same class every time. Does that matter? Is it worth thousands of dollars per seat? You get to choose!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Robert Martin
Author
Ranch Hand

Joined: Jul 02, 2003
Posts: 76
Originally posted by Pradeep Bhat:
Does the class diagram capture all the classes in the system?

A class diagram is a tool for you to use, not a declaration of souce code. In a class diagram you only draw those classes that you are interested in exploring. What's more, you constrain the topic of the diagram so that only a few classes are relevant. We want a class diagram to have less than a dozen or so classes on it. Nothing is worse than a sprawling tangle of classes and relationships on a huge wall-sized diagram.
By the same token we do not put all the methods and attributes inside the classes in a class diagram. Often we simply list the name of the class. There are times when it makes sense to list one or two methods or attributes, but that is rare.
Keep your diagrams small, clean, and expressive. Make sure that each diagram has one reason to exist, and that it communicates that one reason well. And don't feel that you must communicate every topic with a diagram. Many topics are better described with code.


---<br />Uncle Bob.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Class diagram