Hi Robin,
long time no see. Thanks for the detailed explanation. I've been
progressing along the line of breaking the class diagram up into small
chunks and including comments on the role of each class. However, I
have been including as much detail as possible in each class,
including all the methods and attributes in order to try and draw a
full picture of what's required. It's taking a bit of time, but I
think it will be worth it when it comes time to code.
--
Jason Sheedy
www.jmpj.net
On 20/06/05, Robin Hilliard <[EMAIL PROTECTED]> wrote:
> 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/
>
---
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/
