gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/UMLLink article.rst


From: Tuukka Hastrup
Subject: [Gzz-commits] manuscripts/UMLLink article.rst
Date: Sat, 15 Feb 2003 14:37:05 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Tuukka Hastrup <address@hidden> 03/02/15 14:37:05

Modified files:
        UMLLink        : article.rst 

Log message:
        rewording the end

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

Patches:
Index: manuscripts/UMLLink/article.rst
diff -u manuscripts/UMLLink/article.rst:1.77 
manuscripts/UMLLink/article.rst:1.78
--- manuscripts/UMLLink/article.rst:1.77        Sat Feb 15 14:29:54 2003
+++ manuscripts/UMLLink/article.rst     Sat Feb 15 14:37:05 2003
@@ -9,7 +9,7 @@
 .. Alternative title: "Free Software toolchain for bidirectional 
    linking between UML diagrams and Javadoc"
 
-.. :Stamp: $Id: article.rst,v 1.77 2003/02/15 19:29:54 humppake Exp $
+.. :Stamp: $Id: article.rst,v 1.78 2003/02/15 19:37:05 tuukkah Exp $
 
 .. Points for HT people
    ====================
@@ -842,17 +842,17 @@
 =============
 
 The UML and linking tools are currently in everyday use in the Gzz
-project [gzz]_. For now, the projects covers about 380 Java classes
-and over 80 pages of design documentation have been written
-[gzz_doc_himalia]_. There are only about 30 different human drawn UML
+project [gzz]_. For now, the documentation covers about 380 Java classes
+and over 80 pages of design documentation exist [gzz_doc_himalia]_. 
+We have only about 30 human-drawn UML
 diagrams embedded within the design documentation pages, but the
-amount of them is continuosly growing. For all those diagrams the
-linking tool generates more than 150 different differently focused
-versions and by simply calculation the linking tool has embedded a
-single diagram implicitly on an avarage into four distinct design
+amount of them is continuously growing. For all those diagrams, the
+linking tool generates more than 150 separate differently focused
+versions, and by simple calculation the linking tool has embedded 
+each diagram implicitly on average into four distinct design
 documentation or Javadoc pages. The UML tool description language
-covers currently 26 different diagram itemtypes and its being extended
-always when necessary.
+covers currently 26 different types of diagram items and is extended
+regularily as necessary.
 
 .. figure:: umldoc-screenshot.gen.eps
    :environment: figure*
@@ -867,9 +867,9 @@
 ==========
 
 In this article we have discussed the hypertextualization of 
-our software project's documentation.
+documentation in our software project.
 Using 
-existing free software tools
+existing Free Software tools
 and a little new glue code we have made UML diagrams into
 contextual menus for switching between the architectural design
 documentation and the detailed Javadoc documentation.
@@ -880,8 +880,8 @@
 The software automatically creates multidirectional links
 based on simple directives in the UML diagram source code in our 
documentation. 
 Only web pages generated during the documentation build 
-process are affected, which makes the task of our software easier than that of 
other web 
-augmentation tools [weinreich00-linkvis]_. 
+process are affected, which makes the task of our software easier than that of 
+some other web augmentation tools [weinreich00-linkvis]_. 
 
 Earlier concept-based navigation and map-based navigation have added 
 horizontal links on top of hierarchical hypertext [brusilovsky02-mapnav]_. 
@@ -899,37 +899,32 @@
 documents. 
 Methods (and fields) should also be linked, especially in interaction 
diagrams, as well
 as associations, whenever there is a suitable object in the code documentation.
+The plugin interface for using other documentation tools also needs
+to be firmed up.
 
 The layout of the diagram is also currently
 more difficult than it should be.
 While the creation of the diagram structure is easier using
 written text than direct manipulation,
 the layout of the resulting structure would benefit from a click-and-drag 
interface.
-However, this approach will also lose some expressive power:
-in metapost the user is now allowed to draw anything on the diagram.
-It is possible that this can be solved by another stage after metapost,
+However, this approach would also lose some expressive power:
+in MetaPost layout the user is now allowed to draw anything on the diagram.
+This can possibly be solved by another stage after metapost,
 where the locations of the nodes could be interactively defined into
-metapost variables.
-On the other hand, there are also arguments against metapost:
-the error messages receive on erroneous input to the UML tool
+MetaPost variables.
+On the other hand, there are also arguments against MetaPost:
+the error messages received on erroneous input to the UML tool
 are difficult to decipher due to the translation layer between.
-This might also speed up the compiling process.
-
-The plugin interface for using other documentation tools also needs
-to be firmed up.
+Abandoning MetaPost might also speed up the compiling process.
 
 Once some of these issues are resolved, we are planning
-to release the glue code as a standalone free software package;
-until then, the code is still publicly accessible at our CVS version
-control server as part of the larger project [gzz]_ (note to referees:
-the project will likely be renamed by the final version).
-
-Finally, we'd like to point out that this tool
-is only intended as a temporary system: using web pages for the 
-presentation/UI layer of a hypertext system is useful and standard 
-but also very limiting from a UI perspective. 
-The system we are using this UML tool to develop is 
-intended for better user interfaces to similar structures.
+to release the glue code as a standalone Free Software package.
+
+Finally, we'd like to point out that this tool could benefit from a less 
+limited presentation layer than currently supported by web browsers. Ideally, 
+hypertext browsers would directly support navigation maps in their 
+user interface, stabilizing the map positions during browsing.
+
 
 Acknowledgments
 ===============




reply via email to

[Prev in Thread] Current Thread [Next in Thread]