[Gzz-commits] manuscripts/UMLLink article.rst

[Tuukka Hastrup]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Tuukka Hastrup <address@hidden> 03/02/15 17:06:32

Modified files:
        UMLLink        : article.rst 

Log message:
        UML twids

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

Patches:
Index: manuscripts/UMLLink/article.rst
diff -u manuscripts/UMLLink/article.rst:1.94 
manuscripts/UMLLink/article.rst:1.95
--- manuscripts/UMLLink/article.rst:1.94        Sat Feb 15 16:57:57 2003
+++ manuscripts/UMLLink/article.rst     Sat Feb 15 17:06:32 2003
@@ -9,7 +9,7 @@
 .. Alternative title: "Free Software toolchain for bidirectional 
    linking between UML diagrams and Javadoc"
 
-.. :Stamp: $Id: article.rst,v 1.94 2003/02/15 21:57:57 tjl Exp $
+.. :Stamp: $Id: article.rst,v 1.95 2003/02/15 22:06:32 tuukkah Exp $
 
 .. Points for HT people
    ====================
@@ -131,9 +131,9 @@
     they don't give the documentation any structure.
 
 In the following sections, we first discuss the role of documentation
-in software engineering in general, then bring the problem of the distinct 
-documentation bodies into focus and present our solution and
-its implementation. Finally, we discuss our practical use of the tool
+in software engineering in general, then bring the problem of the separate
+documentation bodies into focus and present our solution to linking and
+its implementation. Finally, we discuss our experience from using the tool
 and conclude.
 
 Background
@@ -162,7 +162,7 @@
 ideal software design process, and that there are several different
 types of documentation at different levels of abstraction. 
 The steps listed above should produce
-documentation which records requirements or design decisions and
+documentation which records requirements and design decisions, and
 could be referenced throughout the building of the
 software [brooks75mythical-man-month]_. 
 
@@ -207,7 +207,8 @@
 require a more formal process for changes, as in Boehm's Spiral Model
 of software development and enhancement [boehm88spiral-model]_.
 On the outer edges of the system, new research is taking place and should
-not be hampered by process or documentation beyond the immediate
+not be hampered by requiring formal process or documentation beyond the 
+immediate
 needs of the group members involved in the development of that particular part.
 For this reason we have adopted some conventions from Extreme Programming, 
 such as continuing analysis of design objectives along 
@@ -280,15 +281,14 @@
 visually
 describe software architectures and constructs in diagrams
 [booch-jacobson-rumbaugh98uml-user-guide]_. It was originally
-developed for descriptions on an abstract level (many constructs
+developed for descriptions on an abstract level (many constructs of it
 cannot be directly expressed in any programming language)
 [booch-jacobson-rumbaugh98uml-user-guide-onpage-12]_, but the current
 trend in research 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]_. 
-Another use of UML is in reverse engineering, where
-diagrams may be produced from the source code
+[harrison-barton-raghavachari00uml-to-java]_, or diagrams may be produced 
+directly from the source code
 [pierce-tilley02connecting-documentation-rose]_.
 
 In this article we focus on the more conventional use of UML
@@ -296,8 +296,8 @@
 architecture on a general level. 
 UML can function as a common language for 
 communication within a software development team, and for this purpose 
-human-drawn (non-autogenerated) diagrams that show the semantically meaningful
-features at the right level of abstraction are preferred:
+we prefer human-drawn (non-autogenerated) diagrams that show the semantically 
+meaningful features at the right level of abstraction:
 
    "You draw diagrams to visualize a system from different
    perspectives, so a diagram is a projection into a system.