[Gzz-commits] manuscripts/UMLLink umllink.rst

[Asko Soukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Asko Soukka <address@hidden>    03/01/22 05:37:04

Modified files:
        UMLLink        : umllink.rst 

Log message:
        bit about dev process

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

Patches:
Index: manuscripts/UMLLink/umllink.rst
diff -u manuscripts/UMLLink/umllink.rst:1.29 
manuscripts/UMLLink/umllink.rst:1.30
--- manuscripts/UMLLink/umllink.rst:1.29        Tue Jan 21 10:04:09 2003
+++ manuscripts/UMLLink/umllink.rst     Wed Jan 22 05:37:04 2003
@@ -2,7 +2,7 @@
 A free software toolchain for bidirectional linking between UML diagrams and 
Javadoc
 
====================================================================================
 
-:Last-Modified: $Date: 2003/01/21 15:04:09 $
+:Last-Modified: $Date: 2003/01/22 10:37:04 $
 
 Introduction
 ============
@@ -10,7 +10,7 @@
 UML, the blah, has recently become blah blah
 
 UML book (Booch, Jacobson, Rumbaugh)
-p.24: 
+p.24:: 
 
     "You draw diagrams to visualize a system from different
     perspectives, so a diagram is a projection into a system.
@@ -20,9 +20,16 @@
 Recently, various approaches have been developed towards
 unifying software architecture documents and code (REFS)
 
+ * and why they seem to end up generating either the documentation
+   from the code or the code from the documentation
+ * do we need critics against graphical coding with UML somewhere?
+   This could be found at least in articles supporting 
+   domain spesific languages (which may be used for graphical coding)
+
 In this article, we present the tools we developed
 for using UML diagrams as multiple-ended hyperlinks
-between the architectural documents and javadoc.
+between the architectural documents and javadoc generated
+java source documentation.
 
 Background
 ==========
@@ -34,11 +41,52 @@
 
 ... something that mentions the architectural documents
 
+- our development process seems to be closing Boehm's spiral model
+  of software development, though our spiral is endless and we
+  have probably several of them running simultaneously :)
+
+   * ...
+   * determining objectives, alternatives, constraints
+   * evaluatin alternatives, identifying and resolving risks
+   * developing, verifying
+   * planning next phase
+   * ...
+
+  "It fosters the development of spesificatinos that are not necessarily
+  uniform, exhaustive, or formal, in that they defer detailed elaboration of
+  low-risk software elements and avoid unnecessary breakage in their
+  design until the high-risk elements of the design are stabilized."
+
+  "Overall, risk-driven documents, particularly spesifications and plans, are
+  importatn features of the spiral model. Grean amount of detail are not
+  necessary unless the absence of such detail jeopardizes the project."
+
+  Boehm, B. (1988). "A spiral model for software development and 
+  enhancement". IEEE Computer 21 (5), pp. 61-72.
+
+- architectural documents as parts of design, redesign and maintenance
+
+  David Lorge Parnas and Paul C. Clements. A rational design process: 
+  How and why to fake it. IEEE TSE, SE-12(2):251--257, February 1986.
+  (couldn't get the original yet :/ not available digitally)
+
+  + phases of design process:
+  
+    1) designing and documenting module structure
+    2) designing and documenting module interfaces
+    3) designing and documenting "käyttösuhdehierarkia"
+       (should really get the original document :)
+    4) designing and documentin module inner structures
+    5) implementing
+    6) maintenance, re-design, re-implementing (keeping
+       also document up-to-date) this probably included
+       the importance of good documentation for new-comers
+
 - 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
+  + too small budget for large tools like Rational Rose
 
 UML
 ---
@@ -113,6 +161,7 @@
    project's java source code
 
  - easy to find a given class, easy to check methods
+
    + the javadoc output filestructure follows the
      hierarchical tree structure of java packages and classes
 
@@ -299,7 +348,7 @@
  - users are programmers --> allow a simple programming language
 
  - placement: currently metapost; looking at ways to make 
-  interactively editable.
+   interactively editable.
 
   + elements are easy to create by script language
   + graphical placing could need an GUI