[Gzz-commits] manuscripts/UMLLink article.rst

[Asko Soukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Asko Soukka <address@hidden>    03/02/14 12:02:29

Modified files:
        UMLLink        : article.rst 

Log message:
        onpageupdate

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

Patches:
Index: manuscripts/UMLLink/article.rst
diff -u manuscripts/UMLLink/article.rst:1.28 
manuscripts/UMLLink/article.rst:1.29
--- manuscripts/UMLLink/article.rst:1.28        Fri Feb 14 11:52:09 2003
+++ manuscripts/UMLLink/article.rst     Fri Feb 14 12:02:29 2003
@@ -5,7 +5,7 @@
 .. Alternative title: "Free Software toolchain for bidirectional 
    linking between UML diagrams and Javadoc"
 
-.. :Stamp: $Id: article.rst,v 1.28 2003/02/14 16:52:09 tuukkah Exp $
+.. :Stamp: $Id: article.rst,v 1.29 2003/02/14 17:02:29 humppake Exp $
 
 .. Points for HT people
    ====================
@@ -148,10 +148,10 @@
 [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]_ (pp12), but 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
+[booch-jacobson-rumbaugh98uml-user-guide-onpage-12]_, but 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
 [pierce-tilley02connecting-documentation-rose]_.
@@ -167,7 +167,7 @@
    perspectives, so a diagram is a projection into a system.
    For all but the most trivial systems, a diagram represents an elided
    view of the elements that make up a system."
-   [booch-jacobson-rumbaugh98uml-user-guide]_ (pp24) 
+   [booch-jacobson-rumbaugh98uml-user-guide-onpage-24]_
 
 .. (could other stakeholders be identified and described to some
    extent somewhere? it might be interesting to think also towards
@@ -211,7 +211,7 @@
 software design process is not generally possible, but acceptable
 results could be achieved by faking "the ideal process". Their ideal
 software design process contains the following steps
-[parnas-clements86rational]_ (pp252--255):
+[parnas-clements86rational-onpage-252-255]_:
 
   a) establish and document requirements
   b) design and document the module structure
@@ -233,19 +233,19 @@
 productive for the project. Sometimes sufficient mentoring could not
 even be possible, because members of such a projects could be
 geographically widely scattered. This results in the Mythical Man
-Month effect [brooks75mythical-man-month]_ (pp16): adding a new member
+Month effect [brooks75mythical-man-month-onpage-16]_: adding a new member
 into software design process could rather delay than speed up the
 project.
 
   "Men and months are interchangeable commodities only when a task can be 
   partitioned among many workers with no communication."
-  [brooks75mythical-man-month]_ (pp18)
+  [brooks75mythical-man-month-onpage-18]_
 
   "The added burden of communication is made up of two
   parts, training and intercommunication. Each worker must be trained
   in the technology, the goal of the effort, the overall strategy, and
   the plan of work.-- --Intercommunication is worse."
-  [brooks75mythical-man-month]_ (pp18)
+  [brooks75mythical-man-month-onpage-18]_
 
 Eventually, the greater is the amount of programmers or higher the
 turnover within them, the more important it is to have a good
@@ -253,7 +253,7 @@
 have to depend completely on the old staff for their information. An
 up to date and rational set of documents available for them could
 ameliorate the Mythical Man Month effect
-[parnas-clements86rational]_ (pp255).
+[parnas-clements86rational-onpage-255]_.
 
 Because our group is doing experimental research with a rather small
 group and as an open Free Software project, we need a flexible model
@@ -262,7 +262,7 @@
 of software development and enhancement [boehm88spiral-model]_. From
 the modern models our development process is influenced by Extreme
 Programming [beck99xp]_. The Spiral Model is cyclic and repetitive,
-and every cycle has the following phases [boehm88spiral-model]_ (pp64):
+and every cycle has the following phases [boehm88spiral-model-onpage-64]_:
 
  * analysis: determining objectives, alternatives, constraints
  * design: evaluating alternatives, identifying and resolving risks
@@ -383,12 +383,12 @@
 
 The usability of hypertext-based documentation may suffer from user's
 disorientation: the tendency to lose one's sense of location and
-direction in a nonlinear document [conklin87hypertext]_
-(pp38--40). That means, users don't know where they are in the
-documentation network or how to get to some other place that they know
-to exist in the network. In our documentation this gets even more
-complex, because we have two distinct pieces of documentation, which
-should have somehow unified navigation.
+direction in a nonlinear document
+[conklin87hypertext-onpage-38-40]_. That means, users don't know where
+they are in the documentation network or how to get to some other
+place that they know to exist in the network. In our documentation
+this gets even more complex, because we have two distinct pieces of
+documentation, which should have somehow unified navigation.
 
 Edwards and Hardman [edwards-hardman89lost-in-hyperspace]_ argue that
 the most appropriate types of navigation devices would be based on
@@ -397,7 +397,7 @@
 in the form of a survey-type map. They conlude that users should be
 allowed to develop a cognitive map of one view of the data structure
 before being given the opinion of navigating through the data some
-other way. [edwards-hardman89lost-in-hyperspace]_ (pp123)
+other way. [edwards-hardman89lost-in-hyperspace-onpage-123]_
     
 We didn't need to look long for a common navigational metaphor to
 unify the two distinct pieces. Since the most of our UML diagrams
@@ -610,18 +610,18 @@
        and been reduced to pointing at objects in the immediate
        environment.-- --We have lost all the power of language, and
        can no longer talk about objects that are not immidiately
-       visible." [gentner-nielsen96anti-mac]_ (pp74)
+       visible." [gentner-nielsen96anti-mac-onpage-74]_
 
 The direct manipulation user interface do not necessarily improve
 performance: users must learn the meaning of the graphical components,
 graphic presentation could be misleading, graphical presentation could
 take excessive screen display space
-[shneiderman83direct-manipulation]_ (pp64). The direct manipulation
+[shneiderman83direct-manipulation-onpage-64]_. The direct manipulation
 interfaces could be also rather slow to use, since in a such interface
 user have to directly manipulate everything. Instead of an executive
 who gives high-level instructions, the user is reduced to an assembly
 line worker who must carry out the same task over and over
-[gentner-nielsen96anti-mac]_ (pp74). The UML langage has XXX different
+[gentner-nielsen96anti-mac-onpage-74]_. The UML langage has XXX different
 symbols and XXX different connections between them. It is a quite
 challanging for a direct manipulation interface to make all these
 alternatives as easily available as they could be typed within lexical