mirror of https://github.com/dspinellis/UMLGraph
Improvements after reviewing
This commit is contained in:
parent
6e9eea3f90
commit
e8fcbbf72c
|
|
@ -3,6 +3,12 @@
|
|||
* $Id$
|
||||
*/
|
||||
|
||||
/**
|
||||
* @opt nodefontname "Arial"
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions{}
|
||||
|
||||
class HttpResponseBase
|
||||
extends ResponseBase
|
||||
implements HttpResponse, HttpServletResponse {}
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Running the UmlGraph doclet on the specification will generate
|
|||
a
|
||||
<a href="http://www.graphviz.org/">Graphviz</a>
|
||||
diagram specification that can be automatically processed to
|
||||
create Postscript, GIF, SVG, JPEG, fig, or Framemaker drawings.
|
||||
create PNG, SVG, EMF, Postscript, GIF, JPEG, fig, or Framemaker drawings.
|
||||
<p />
|
||||
The following is an example of a specification and the resulting UML class
|
||||
diagram:
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ collaborations, and packages
|
|||
<li>dependency relationships (specified using the <em>javadoc</em> <code>@depend</code> tag)
|
||||
</li>
|
||||
</ul>
|
||||
All relationship tags appart from <code>@extends</code> take four arguments:
|
||||
All relationship tags apart from <code>@extends</code> take four arguments:
|
||||
<ol>
|
||||
<li> The source adornments (role, multiplicity, and visibility)
|
||||
</li>
|
||||
|
|
|
|||
|
|
@ -16,20 +16,20 @@ Java code.
|
|||
Note however that UMLGraph was not originally designed for this purpose;
|
||||
the resulting graphs may be large and unwieldy.
|
||||
<p />
|
||||
There are various ways to invoke UmlGraph,
|
||||
There are various ways to invoke UMLGraph,
|
||||
each providing a different balance between convenience and flexibility.
|
||||
<h2>Option 1: Using the Supplied Script</h2>
|
||||
This is the simplest option.
|
||||
If <code>umlgraph</code> (or <code>umlgraph.bat</code>) is correctly
|
||||
installed,
|
||||
you can run UmlGraph by simply specifying the basename of
|
||||
you can run UMLGraph by simply specifying the basename of
|
||||
the Java file containing the diagram specification and the file type of
|
||||
the generated diagram (e.g. gif, ps, png, svg).
|
||||
Example:
|
||||
<fmtcode ext="sh">
|
||||
umlgraph Test png
|
||||
</fmtcode>
|
||||
Any additional UmlGraph or <em>javadoc</em> arguments can be added at
|
||||
Any additional UMLGraph or <em>javadoc</em> arguments can be added at
|
||||
the end of the command line.
|
||||
This command will read the specification file (e.g. Test.java) and
|
||||
generate directly a diagram of the appropriate type
|
||||
|
|
@ -41,7 +41,7 @@ You can accomplish this in two ways.
|
|||
<ol>
|
||||
<li>
|
||||
Specify the location of <code>tools.jar</code> as a part of Java's classpath
|
||||
and specify the full name of the UmlGraph doclet as an argument to Java.
|
||||
and specify the full name of the UMLGraph doclet as an argument to Java.
|
||||
This is an invocation example under Windows
|
||||
<fmtcode ext="bat">
|
||||
java -classpath "lib/UmlGraph.jar;c:\program files\java\jdk1.6.0_02\lib\Tools.jar"
|
||||
|
|
@ -58,7 +58,7 @@ file in a directory that also contains the Java SDK <code>tools.jar</code> file.
|
|||
You can accomplish this either by copying <code>UmlGraph.jar</code> to the SDK
|
||||
<code>lib</code> directory where <code>tools.jar</code> resides,
|
||||
or by copying the JDK <code>tools.jar</code> file into the directory
|
||||
where you installed UmlGraph.
|
||||
where you installed UMLGraph.
|
||||
You then run
|
||||
<fmtcode ext="sh">
|
||||
java -jar /path/to/UmlGraph.jar yourfile1.java ...
|
||||
|
|
@ -76,7 +76,7 @@ java -jar /usr/jvm/java-1.5.0/lib/UmlGraph.jar -private Simple.java
|
|||
Specifying some packages before the list of source files will designate
|
||||
those packages as <em>local</em>.
|
||||
When you specify a package list,
|
||||
the SVG output UmlGraph generates will contain
|
||||
the SVG output UMLgraph generates will contain
|
||||
local hyperlinks for the local classes
|
||||
and hyperlinks to the Sun Java API documentation for all other classes.
|
||||
<p />
|
||||
|
|
|
|||
|
|
@ -11,12 +11,13 @@
|
|||
class UMLOptions{}
|
||||
|
||||
/**
|
||||
* @opt nodefontname "Helvetica-Bold"
|
||||
* @opt nodefontname "Arial"
|
||||
* @opt nodefontcolor "white"
|
||||
* @composed - - - Red
|
||||
* @composed - - - Green
|
||||
* @composed - - - Blue
|
||||
* @opt attributes
|
||||
* @opt operations
|
||||
* @opt visibility
|
||||
* @opt types
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@
|
|||
<ch><ti>Class Diagram Example: Class Stereotypes and Tagged Values</ti><fi>ceg-ster</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Fonts, Colors, Global and Local Options</ti><fi>ceg-color</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Multiple Views Through Command-Line Options</ti><fi>ceg-mv</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Inner support for views</ti><fi>ceg-view-spec</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Built-in Support for Views</ti><fi>ceg-view-spec</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Views With Different Specification Details</ti><fi>ceg-view-details</fi></ch>
|
||||
<ch><ti>Class Diagram Example: Views for Different Packages</ti><fi>ceg-view-packages</fi></ch>
|
||||
<ch><ti>Running the Doclet from Ant</ti><fi>ant</fi></ch>
|
||||
|
|
|
|||
|
|
@ -34,8 +34,9 @@ Creating models in a declarative, textual notation offers a number of advantages
|
|||
It is more difficult for designers to get away, as they often do now, with drawing for a model a nice picture of the implementation they have in mind.</li>
|
||||
<li> The declarative representation is also highly malleable, the existing visual structure does not hinder drastic changes, nor is effort wasted on the tidy arrangement of graph nodes a psychological barrier against massive design refactoring.</li>
|
||||
<li> Declarative models are also highly automatable: they can be easily generated from even higher-level descriptions by trivial scripts and tools operating on design process inputs such as database schemas, existing code, or structured requirements documents.</li>
|
||||
<li> Text macro processors can be used for configuration management, while revision control and team integration activities can utilize the same proven tools and processes that are currently used for managing source code.
|
||||
Thus with a tool like CVS or RCS one can keep track of design revisions, create and merge branches, and monitor model changes, while a system like CVS can allow work to be split into teams.</li>
|
||||
<li> With a declarative specification under the programmer's control a macro processors can be used for configuration management, allowing the same model to be used for generating diverse diagrams.</li>
|
||||
<li> Revision control and team integration activities can utilize the same proven tools and processes that are currently used for managing source code.
|
||||
Thus with a tool like Subversion or Git one can keep track of design revisions, create and merge branches, monitor model changes, and split work among a team.</li>
|
||||
<li> Finally, the declarative approach can readily utilize existing text processing tools for tasks that a drawing editor system may not provide.</li>
|
||||
</ul>
|
||||
Consider how your favorite model editor handles the following tasks and how you could handle them using a simple Perl script or a text-processing pipeline applied to the declarative model specification:
|
||||
|
|
|
|||
|
|
@ -1,3 +1,10 @@
|
|||
/**
|
||||
* @opt nodefontname "Helvetica"
|
||||
* @opt edgefontname "Helvetica"
|
||||
* @hidden
|
||||
*/
|
||||
class UMLOptions{}
|
||||
|
||||
/**
|
||||
* @opt shape node
|
||||
* @note Located in the
|
||||
|
|
|
|||
Loading…
Reference in New Issue