[Gzz-commits] manuscripts/UMLLink short-paper.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Tuomas J. Lukka <address@hidden>        03/05/21 15:01:45

Modified files:
        UMLLink        : short-paper.rst 

Log message:
        resolveconflict

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/UMLLink/short-paper.rst.diff?tr1=1.27&tr2=1.28&r1=text&r2=text

Patches:
Index: manuscripts/UMLLink/short-paper.rst
diff -u manuscripts/UMLLink/short-paper.rst:1.27 
manuscripts/UMLLink/short-paper.rst:1.28
--- manuscripts/UMLLink/short-paper.rst:1.27    Wed May 21 15:00:21 2003
+++ manuscripts/UMLLink/short-paper.rst Wed May 21 15:01:45 2003
@@ -2,7 +2,7 @@
 Bridging Javadoc and design documentation via UML diagram image maps
 ====================================================================
 
-.. $Id: short-paper.rst,v 1.27 2003/05/21 19:00:21 humppake Exp $
+.. $Id: short-paper.rst,v 1.28 2003/05/21 19:01:45 tjl Exp $
 
 .. short paper == 2 pages, deadline the end of May
 
@@ -82,14 +82,13 @@
 between requirements and design decisions is relatively
 well developed [gotel94reqtracing-andalso-jarke98reqtracing]_.
 
+.. REF for j2sdk - probably no room.... XXX
+
 What is often missing is the connections between
 the design documentation and the embedded documentation.
 This can be daunting to a newcomer; consider the javadoc
-for the interface ``java.security.PublicKey`` in Sun's
-Java2 SDK 1.4.1.
-
-.. REF?. XXX
-
+in Sun's Java2 SDK 1.4.1
+for the interface ``java.security.PublicKey``.
 While the class is easy to find through the package and class lists
 when looking for a class to represent cryptographical public keys,
 the javadoc is not terribly useful: there is no information
@@ -235,6 +234,22 @@
 The implementation in Navidoc
 =============================
 
+..  Navidoc is a modular tool, lightweight tool
+    for implementing the above
+    UML-based linking between design documents and low-level
+    documentation.
+    Navidoc itself does relatively little --- it is built on top 
+    of other tools with minimal effort as an experiment.
+
+    The most complex component is our own language
+    for describing simple UML diagrams --- none of the free software
+    tools were suitable for our purposes.
+    It is a language and not a graphical editor because for programmers,
+    the main audience of the tool, point-and-click is often slower
+    than simple description of the diagram.
+    The structure and layout of the diagram are separated
+
+
 .. think, this should be much clearer :) But how to say everything shortly...
 
 Navidoc, our implementation, is as a light-weight tool built on top of
@@ -246,6 +261,9 @@
 in the images. These diagrams embedded into target documents, allow easy 
traverse
 through all the participant nodes and backlink to the startup page holding
 the original diagram.
+The automatically inserted images
+are scaled to half size, whereas in their "real" location
+in the design documentation the images are shown at their full size.
 
 .. After compiling, it creates imagemaps for every UML diagram to link
    diagrams' elements to corresponding source code documentation
@@ -254,6 +272,17 @@
 .. The main existing components are Docutils [goodger02docutils]_,
 
 ..  we can only have very few references [fsf02categories]_ 
+
+..  - main parts: Docutils [goodger02docutils]_, lexical UML language
+
+..  Navidoc uses several free utilies to convert each
+    textual 
+
+..  The UML diagram descriptions are then converted
+    into a set of imagemaps --- one
+    for each target document since the current document is highlighted
+    in the images with color and a dark, irregular line to draw
+    the viewer's eye towards it. 
 
 .. - main parts: Docutils [goodger02docutils]_, lexical UML language