And btw., roundtrip tools don't help much with updating diagrams which
are sitting in text documents. That still has to be done manually -
unless someone invents a system which manages everything (code and
documentation). But then it would still need a human being to decide
whether a new sub class should show up on a particular diagram or not.
I've only ever seen one that did. It came out of a UK University but
never seems to have come to anything. Its 'presentation face' mixed
textual documentation and code fragments in a similar fashion to K&R or
(better) Kernighan & Pike, while still keeping the ability to maintain
the text without interfering with the code and to develop and compile the
code without screwing up the overall look and feel of the 'presentation
face'. I can't remember how it dealt with diagrammatic material. I
thought it had a lot of promise though it was probably not a much higher-
level tool that Javadocs.
My main objection to all theses methodologies is that the documentation
is usually stored and maintained separately from the code, which to me
means that it isn't going to be maintained. As I've said before, the big
advantage, as I see it, of Javadocs is that at least there's a good
chance that module-level documentation will be maintained as the code
gets modified.
Its a pity there isn't anything similar for a system's higher level
documentation like, for instance a combination source repository and data
dictionary, but the nearest I've seen to a decent attempt at that was the
long-defunct ICL Advanced Data Dictionary with its four quadrant
structure, version control and linkages between the quadrants:
processes | entities
data and | attributes
control flow | relationships
---------------------------------------
programs | schemas
pipelines | storage schemas
process management | tables
This could generate project documentation and code (both DDS and program
source) and manage version control across an entire system.