David Jencks wrote:
As I discuss below, I find UML (or whatever modeling language you want to use) useful primarily in providing macro, analysis views of system architecture and high-level design, and in providing templates for low-level design (A.K.A. coding). For this to be useful, it must be based on a common vocabulary that is derived from the user's vocabulary. For this to be persistent, you need additional prose documentation and/or village elders who can be relied on to educate the nubies.Personally I have found uml diagrams sometimes useful in organizing my own thinking but have never been able to communicate any useful ideas using them.
<soapbox perspective="pragmatic" style="danch-rant">
It's absolutely ridiculous to do sequence diagrams that get anywhere near the fine grained detail of code. development models where some 'design' team grinds through and produces mountains of that nonsense that then must be ignored by herds of coders who are the lucky many who actually find out what works don't scale well, to say the least.
<deap-breath />
</soapbox>
8^})
Well, according to the dogma, you change the UML first. My personal best practice is to keep the UML at a high enough level that most code changes don't invalidate UML, and those changes that do invalidate the model tend to require using the model as a thinking tool first.Indeed! In fact, we can consider UML diagrams as a complement to javadoc. When a development is done, javadoc should be synchronized with it, UML diagrams should be synchronized the same way.
Frankly, my attitude to javadoc is much the same: it should be a brief description of what is being accomplished, not a detailed description of how. And you should write it _while_ you code, not after, because 'after its done' is a time no software gets to until it's irrelavant. If you write the code for a human to read (which is the point of high-level languages), you'll need minimal commenting.
UML is most useful when it is used to describe coarse-grained structures - analysis models, typical mappings from analysis to design model (both with class diagrams), and typical flows (via sequence diagrams). This makes synchronization less of an issue - if you make a change that effects things at that level, you probably _need_ to model it. Changes in implementation details fall into the 'noise' category.
I think that the main thing that causes open source software to tend not to have much in the way of design documentation is that the best open source systems are built by people who have a pretty good talent for keeping a model in their heads, and for building that wetware model by reading source. When you can see it working in your head, wacking out a model isn't real stimulating compared to getting it to work in the product.
<soapbox>
Never forget that the code _is_ a design artifact, and that coding _is_ a design activity. Don't let the fact that the fabrication process is truncated in software fool you into thinking that (good) coding is an assembly line activity.
Of course, that assumes that you have software engineers, not merely well trained howler monkeys. Don't do J2EE with howler monkeys.
</soapbox>
Yes, xmi is a standard for UML diagrams.I suggest xmi using argo/poseidon.
But they only are useful to those who can use them with the right tool. I think an image format could be used too for those who don't have such tool.again, argo is completely free and poseidon has a free version. They are both pretty lightweight.
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
