[Gzz-commits] manuscripts/UMLLink umllink.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Tuomas J. Lukka <address@hidden>        03/01/21 08:06:12

Modified files:
        UMLLink        : umllink.rst 

Log message:
        reorg

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

Patches:
Index: manuscripts/UMLLink/umllink.rst
diff -u manuscripts/UMLLink/umllink.rst:1.22 
manuscripts/UMLLink/umllink.rst:1.23
--- manuscripts/UMLLink/umllink.rst:1.22        Tue Jan 21 06:50:56 2003
+++ manuscripts/UMLLink/umllink.rst     Tue Jan 21 08:06:12 2003
@@ -2,7 +2,7 @@
 A free software toolchain for bidirectional linking between UML diagrams and 
Javadoc
 
====================================================================================
 
-:Last-Modified: $Date: 2003/01/21 11:50:56 $
+:Last-Modified: $Date: 2003/01/21 13:06:12 $
 
 Introduction
 ============
@@ -22,8 +22,15 @@
 for using UML diagrams as multiple-ended hyperlinks
 between the architectural documents and javadoc.
 
-Previous work
-=============
+Background
+==========
+
+Software development processes
+------------------------------
+
+XXX!!!
+
+... something that mentions the architectural documents
 
 UML
 ---
@@ -72,6 +79,7 @@
 Java (trademark of Sun Microsystems, Javadoc is distributed only
 as part of Java, non-free), is ...
 
+
 Setting of problem
 ==================
 
@@ -104,6 +112,15 @@
 "Obvious" question: can we increase the overall value by
 interconnecting the two?
 
+- distinct architecture documentation, where diagrams are from human to human
+  + we don't wan to generate diagrams from the code or generate
+    code from the diagrams
+  + generated diagrams are too detailed to be beneficial
+  + these cover the most relevant parts from the architecture and the code
+- creating UML diagrams to natural part of our design (pegboard) and
+  documenting (architecture docs) process
+  + how our development process diffs from "the common way"?
+  + too small budget for large tookillls like Rational Rose
 
 
 Design
@@ -163,6 +180,12 @@
 Documentation's developer's point of view
 -----------------------------------------
 
+Goals:
+
+    - small, incremental changes to existing javadoc / other documentation
+
+    - Low threshold for writing new documentation, diagrams etc.
+
 reST's filosophy
 
  - indentation for blocks
@@ -172,20 +195,19 @@
 
 Why UML-language
 
- - minimum cap to make a diagram (well, at first have to learn our UML-script)
+ - minimum barrier to make a diagram (well, at first have to learn our 
UML-script)
+
+ - separate UML structure from presentation, show structure in easily
+   editable text
+
+ - direct manipulation when building diagrams clumsy
+
  - diagrams in the same reST source than the architecture document
+
  - only explicit link from diagram object to the class it represents is
    obligatory, all other are implicit
 
-Goals:
-    
-    - light-weight
-
-    - using existing free software tools
-
-    - small, incremental changes to existing javadoc / other documentation
 
-    - Low threshold for writing new documentation, diagrams etc.
 
 UML diagram component
     
@@ -200,15 +222,6 @@
       + elements are easy to create by script language
       + graphical placing could need an GUI
 
-- distinct architecture documentation, where diagrams are from human to human
-  + we don't wan to generate diagrams from the code or generate
-    code from the diagrams
-  + generated diagrams are too detailed to be beneficial
-  + these cover the most relevant parts from the architecture and the code
-- creating UML diagrams to natural part of our design (pegboard) and
-  documenting (architecture docs) process
-  + how our development process diffs from "the common way"?
-  + too small budget for large tookillls like Rational Rose
 - minimize the cap of drawing a even small diagram to make
   document more clear
 - link diagrams' objects to code documentation, which 
@@ -262,9 +275,18 @@
 
   Could Generalization/Specification be best for reST<->Javadoc.  
 
+From our point of view, the links in the last version cease to be "links"
+and the UML diagrams become objects in their own right.
 
 Implementation
 ==============
+
+Goals:
+    
+    - light-weight
+
+    - using existing free software tools
+
 
 -free software chain
 -flow diagram