[Gzz-commits] manuscripts/UMLLink article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/15 04:57:44

Modified files:
        UMLLink        : article.rst 

Log message:
        twid

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/UMLLink/article.rst.diff?tr1=1.42&tr2=1.43&r1=text&r2=text

Patches:
Index: manuscripts/UMLLink/article.rst
diff -u manuscripts/UMLLink/article.rst:1.42 
manuscripts/UMLLink/article.rst:1.43
--- manuscripts/UMLLink/article.rst:1.42        Sat Feb 15 04:56:51 2003
+++ manuscripts/UMLLink/article.rst     Sat Feb 15 04:57:44 2003
@@ -9,7 +9,7 @@
 .. Alternative title: "Free Software toolchain for bidirectional 
    linking between UML diagrams and Javadoc"
 
-.. :Stamp: $Id: article.rst,v 1.42 2003/02/15 09:56:51 tjl Exp $
+.. :Stamp: $Id: article.rst,v 1.43 2003/02/15 09:57:44 benja Exp $
 
 .. Points for HT people
    ====================
@@ -136,6 +136,9 @@
 Abstract
 ========
 
+We describe automatic linking of design documentation to javadoc
+through UML diagrams embedded in both, acting as nexus links.
+
 XXX !!!
 
 Introduction
@@ -144,8 +147,8 @@
 Software projects manage a large base of evolving documentation, which
 is inter-related on many levels. Design documentation gives
 architectural views on a more general level, while the program code
-source files give all the minute details on how the computer should
-act and contain embedded documentation for human-readability. Although
+source files contain interfaces and embedded documentation
+giving all the minute details on how the computer should act. Although
 these two parts of documentation are semantically dependent, linking
 them is tedious -- if even possible -- when they are authored using different
 software.
@@ -155,20 +158,19 @@
 [booch-jacobson-rumbaugh98uml-user-guide]_. It was originally
 developed for descriptions on an abstract level (many constructs
 cannot be directly expressed in any programming language)
-[booch-jacobson-rumbaugh98uml-user-guide-onpage-12]_, but current
+[booch-jacobson-rumbaugh98uml-user-guide-onpage-12]_, but the current
 trend is to use it also on the concrete level, as to fully unify the
 architectural documentation and program code: the program code might
 be generated from highly detailed diagrams
-[harrison-barton-raghavachari00uml-to-java]_, or exact diagrams be
-produced from the source code
+[harrison-barton-raghavachari00uml-to-java]_, or diagrams
+may be produced from the source code
 [pierce-tilley02connecting-documentation-rose]_.
 
 Against this trend, we still use UML only to plan and document our software 
 architecture on a general level. UML functions as a common language for 
-communication within our software development team, and in this purpose we
-prefer better abstracted and more comprehensible
-human-drawn diagrams to exact illustrations matching source code to 
-every detail: 
+communication within our software development team, and for this purpose we
+prefer human-drawn diagrams that abstract from the gory details
+of code to be more comprehensible to us:
 
    "You draw diagrams to visualize a system from different
    perspectives, so a diagram is a projection into a system.