/[gzz]/manuscripts/UMLLink/umllink.rst
ViewVC logotype

Diff of /manuscripts/UMLLink/umllink.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.29 by tjl, Tue Jan 21 15:04:09 2003 UTC revision 1.30 by humppake, Wed Jan 22 10:37:04 2003 UTC
# Line 10  Introduction Line 10  Introduction
10  UML, the blah, has recently become blah blah  UML, the blah, has recently become blah blah
11    
12  UML book (Booch, Jacobson, Rumbaugh)  UML book (Booch, Jacobson, Rumbaugh)
13  p.24:  p.24::
14    
15      "You draw diagrams to visualize a system from different      "You draw diagrams to visualize a system from different
16      perspectives, so a diagram is a projection into a system.      perspectives, so a diagram is a projection into a system.
# Line 20  p.24: Line 20  p.24:
20  Recently, various approaches have been developed towards  Recently, various approaches have been developed towards
21  unifying software architecture documents and code (REFS)  unifying software architecture documents and code (REFS)
22    
23     * and why they seem to end up generating either the documentation
24       from the code or the code from the documentation
25     * do we need critics against graphical coding with UML somewhere?
26       This could be found at least in articles supporting
27       domain spesific languages (which may be used for graphical coding)
28    
29  In this article, we present the tools we developed  In this article, we present the tools we developed
30  for using UML diagrams as multiple-ended hyperlinks  for using UML diagrams as multiple-ended hyperlinks
31  between the architectural documents and javadoc.  between the architectural documents and javadoc generated
32    java source documentation.
33    
34  Background  Background
35  ==========  ==========
# Line 34  XXX!!! Line 41  XXX!!!
41    
42  ... something that mentions the architectural documents  ... something that mentions the architectural documents
43    
44    - our development process seems to be closing Boehm's spiral model
45      of software development, though our spiral is endless and we
46      have probably several of them running simultaneously :)
47    
48       * ...
49       * determining objectives, alternatives, constraints
50       * evaluatin alternatives, identifying and resolving risks
51       * developing, verifying
52       * planning next phase
53       * ...
54    
55      "It fosters the development of spesificatinos that are not necessarily
56      uniform, exhaustive, or formal, in that they defer detailed elaboration of
57      low-risk software elements and avoid unnecessary breakage in their
58      design until the high-risk elements of the design are stabilized."
59    
60      "Overall, risk-driven documents, particularly spesifications and plans, are
61      importatn features of the spiral model. Grean amount of detail are not
62      necessary unless the absence of such detail jeopardizes the project."
63    
64      Boehm, B. (1988). "A spiral model for software development and
65      enhancement". IEEE Computer 21 (5), pp. 61-72.
66    
67    - architectural documents as parts of design, redesign and maintenance
68    
69      David Lorge Parnas and Paul C. Clements. A rational design process:
70      How and why to fake it. IEEE TSE, SE-12(2):251--257, February 1986.
71      (couldn't get the original yet :/ not available digitally)
72    
73      + phases of design process:
74      
75        1) designing and documenting module structure
76        2) designing and documenting module interfaces
77        3) designing and documenting "käyttösuhdehierarkia"
78           (should really get the original document :)
79        4) designing and documentin module inner structures
80        5) implementing
81        6) maintenance, re-design, re-implementing (keeping
82           also document up-to-date) this probably included
83           the importance of good documentation for new-comers
84    
85  - creating UML diagrams to natural part of our design (pegboard) and  - creating UML diagrams to natural part of our design (pegboard) and
86    documenting (architecture docs) process    documenting (architecture docs) process
87    
88    + how our development process diffs from "the common way"?    + how our development process diffs from "the common way"?
89    + too small budget for large tookillls like Rational Rose    + too small budget for large tools like Rational Rose
90    
91  UML  UML
92  ---  ---
# Line 113  Javadoc Line 161  Javadoc
161     project's java source code     project's java source code
162    
163   - easy to find a given class, easy to check methods   - easy to find a given class, easy to check methods
164    
165     + the javadoc output filestructure follows the     + the javadoc output filestructure follows the
166       hierarchical tree structure of java packages and classes       hierarchical tree structure of java packages and classes
167    
# Line 299  UML diagram component Line 348  UML diagram component
348   - users are programmers --> allow a simple programming language   - users are programmers --> allow a simple programming language
349    
350   - placement: currently metapost; looking at ways to make   - placement: currently metapost; looking at ways to make
351    interactively editable.     interactively editable.
352    
353    + elements are easy to create by script language    + elements are easy to create by script language
354    + graphical placing could need an GUI    + graphical placing could need an GUI

Legend:
Removed from v.1.29  
changed lines
  Added in v.1.30

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26