Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Do C++ and Java professionals use UML?? Date: Fri, 20 Jul 2012 19:33:27 +0000 (UTC) Organization: UK Free Software Network Lines: 47 Message-ID: References: <7b5978a1-16bd-4700-acd8-b6446f5c3218@j4g2000yqf.googlegroups.com> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1342812807 22022 84.45.235.129 (20 Jul 2012 19:33:27 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Fri, 20 Jul 2012 19:33:27 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: csiph.com comp.lang.java.programmer:16161 On Fri, 20 Jul 2012 13:39:20 +0200, Robert Klemme wrote: > 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. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |