Jason Sheedy wrote:
If you've had experience with UML, I'm keen to discuss how much detail
you put into your class diagrams. I'm a little unsure about how much
detail you would put in the case of breaking up an object into
Bean/DAO/Gateway. Should these be listed as separate classes or should
the class diagram only provide a high level perspective?
Hi Jason,
It depends what you're trying to explain to the reader. I never use UML
like an E-R diagramming tool with full details of every class on the one
diagram - code is so much more complex than a database schema and you're
unlikely to convey much useful understanding doing it that way.
When you're documenting a software design you are telling someone a
story - you tell the story in words, and when you find it would be more
efficient to use a diagram, you whack one in, with lots of verbage
around it (or particularly as UML "notes" in the diagram itself) to fill
out the picture. UML is a notation, not a methodology - you can't use it
in a vaccuum.
Class diagrams are mainly useful for explaining how classes are related
to eachother - if you want to list the properties and methods in full
detail IMHO it would be better to have a javadoc-like description. A
useful class diagram might concentrate on the relationship between a few
classes with a caption like "x extends y and manages a collection of
zs". Because they're about relationships you want to use the connecting
lines on a class diagram properly otherwise there's not much point using
them at all:
subclass ______extends_______|> superclass
class or package --------depends on----------> another class or package
class <>_1_______has_a_collection_______0..*___ another class
+detail
class <>______has_a__________> another class which has no reference to
-prop first class (">" = one way navigability)
(A very basic list - "I use The Unified Modeling Language User Guide",
Addison Wesley, ISBN 0201571684 - particular advantage is that it tells
you how to _use_ UML rather than just draw it)
Class diagrams are only one of many UML diagram types. Interaction and
sequence diagrams are very useful for explaining how the program
actually executes code and (again IMHO) should be used more often - they
have captions like "x creates a y and then calls its z method".
Cheers,
Robin
http://www.rocketboots.com.au
PS: Have been underground for a while, the Boots are pretty busy at the
moment :-)
---
You are currently subscribed to cfaussie as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/
