The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Object Oriented Design - question - All classes in the diagram?

Hello,
does it make sense to have more than 1 class diagram for each project?

For example, a project that is divided into functional wizards. Each wizard does something different. But their base is the same - classes specific for wizard 2 use classes for wizard 1.

So would it make sense to split this in 2 models - to simplify each model - and have some note saying that some classes are imported?

Thanks.
MdP
Sunday, April 22, 2007
 
 
Class diagrams are a way to communicate the design.Why are they treated as such an holy artifact... If 100 class diagrams communicate the idea better to 100 people, then there should be 100 class diagrams.. Unless you want to do something funky like MDA.. Then you are completely reliant on the tool...

Sunday, April 22, 2007
 
 
You can have diagrams with more and less detail, for example:

* One high-level, introductory diagram which lists the base class and all derived classes, with the name and perhaps the description of each class, but not the details of any class e.g. none of the classes' methods

* Detailed diagrams of specific classes, showing the classes' members
Christopher Wells Send private email
Sunday, April 22, 2007
 
 
> does it make sense to have more than 1 class diagram for each project?

That's similar to asking whether it makes sense to have more than diagram of a database schema: if the schema is small (only two or three tables) then no, but if the schema is large (100s of tables) then probably yes.
Christopher Wells Send private email
Sunday, April 22, 2007
 
 
I would definitely break the diagrams along package/namespace boundaries.
Just A Guy Send private email
Monday, April 23, 2007
 
 
For any reasonable sized project the entire class diagram will be too large to understand. Once you are over about ten to twenty classes you should definitely be splitting them.
DJ Clayworth
Monday, April 23, 2007
 
 
"Each wizard does something different. But their base is the same - classes specific for wizard 2 use classes for wizard 1."

I've always felt that an object oriented design diagram should show what's possible, not what is actually done. For example, let's say some future programmer needs to create a wizard 3. He needs to be able to decide if he can inherit from wizard 1, wizard 2 or if he needs to create his own superclass from scratch.

So rather than focusing on a wizard equates to an class type of relationship, you should focus on a common functionality relationship.

For example, say you're writing an email program. You might have "add account" and "delete account" wizards. You might have a class for POP mail, a class for IMAP mail, and a class for Exchange mail. Both "add" and "delete" can manipulate the same POP class derived object if that's what the user prefers. If you decide to add a "troubleshoot account" wizard later, that likewise can hook into the POP class.

Then again, I'm defining a wizard as an elaborate macro slash interface that allow you to manipulate one or more existing objects, as opposed to literally define a class.
TheDavid
Monday, April 23, 2007
 
 
Err... to clarify, I would put all classes in the diagrams, but I'd pay attention to what I actually define as a class. If I insisted on one class per wizard, then as the others have implied, it quickly becomes unreadable.
TheDavid
Monday, April 23, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz