Language and formatting improvements.

This commit is contained in:
Diomidis Spinellis 2005-12-26 22:21:39 +00:00
parent 3581178a23
commit 8f8024e767
4 changed files with 47 additions and 24 deletions

View File

@ -65,15 +65,16 @@ Matching is done against the end of each entity's name.
For instance, "<code>-hide Widget</code>" would hide "<code>com.foo.widgets.Widget</code>" and
"<code>com.foo.widgets.BigWidget</code>".
</dd>
<dt>-hideall</dt><dd>Hide all entities from the graph. Used with views to show only a specific
<dt>-hideall</dt><dd>Hide all entities from the graph.
Used with views to show only a specific
subset of classes in each class diagram.
</dd>
<dt>-d</dt><dd>Destination folder for .dot files generated from views.
</dd>
<dt>-view</dt><dd>Specify the fully qualified name of a class that contains a view definition. Only
the class diagram specified by this view will be generated.
<dt>-view</dt><dd>Specify the fully qualified name of a class that contains a view definition.
Only the class diagram specified by this view will be generated.
</dd>
<dt>-views</dt><dd>Look into the source path and generate a class diagram for every view that is found.
<dt>-views</dt><dd>Generate a class diagram for every view found in the source path.
</dd>
<dt>-apidocroot</dt><dd>Specify the URL that should be used as the "root" for local classes.
This URL will be used as a prefix, to which the page name for the local class or

View File

@ -1,20 +1,38 @@
<?xml version="1.0" ?>
<!-- $Id$ -->
<notes>
Documenting a big project usually requires multiple diagrams, each design to show a specific and limited portion of the system.
Documenting a big project often requires multiple diagrams:
each to show a specific and limited portion of the system.
Each diagram is usually composed of few classes, possibily using a different detail level.<p/>
Following the approach of the UMLOptions class, we introduced the <code>@view</code> tag, that marks a special class used to describe a single class diagram.
Similarly to UMLOptions, the view can define his own general options, but what makes it interesting is the ability to specify package based <em>overrides</em> that allow to adopt different options based on the package the classes are in.
The <code>@view</code> tag, marks a special class used to describe a single class diagram.
Similarly to UMLOptions, the view can define its own general options,
but what makes it interesting is the ability to specify package based <em>overrides</em> that allow to adopt different options based on the package the classes are in.
The general syntax of an override is:
<pre>@opt_override REGEXP ([!]option)*</pre>
where REGEXP is a java regular expression that will match a single class, a group of classes, a package, and option is one of the UMLGraph options that
are usually specified with the <code>@option</code> tag. A ! before the option disables the option for the specified package.
<fmtcode ext="java">
/**
* @opt_override REGEXP ([!]option)*
*/
</fmtcode>
where
<ul>
<li><em>REGEXP</em> is a Java regular expression that will match a single class, a group of classes, or a package, and</li>
<li> <em>option</em> is one of the UMLGraph options that
are usually specified with the <code>@option</code> tag.
</li>
</ul>
A ! before the option disables the option for the specified package.
<p />
For example:
<pre>@opt_override net.test.* !operations types</pre>
will add type information and disable operations listing for every class in the net.test package (and its subpackages).<p/>
Multiple overrides can be specified in the same view, and they will be evaluated in the specification order (so, the last one wins in case of conflict).
<fmtcode ext="java">
/**
* @opt_override net.test.* !operations types
*/
</fmtcode>
will add type information and disable the listing of operations for every class in the net.test package (and its subpackages).<p/>
Multiple overrides can be specified in the same view, and they will be evaluated in the order they are specified
(so, the last one wins in case of conflict).
For example:
<pre>
<fmtcode ext="java">
/**
* @view
* @hidden
@ -23,11 +41,13 @@ For example:
* @opt_override net.test2.* !hideall attributes operations visibility
*/
class NetTest2PackageDiagram {}
</pre>
defines a class diagram for the net.test2 package. Everything in this package is shown, classes in the net.test1 package are shown as well,
</fmtcode>
defines a class diagram for the net.test2 package.
Everything in this package is shown, classes in the net.test1 package are shown as well,
but without details (probably because they are somewhat related to the net.test2 classes), the rest is hidden.<p/>
Each view will generate a .dot file whose name is the name of the view (only the class name). Use the <code>-d</code> command line
parameter to better specify in which folder the .dot files should be generated.
Oh, if you're wondering why we used ".*" as the regular expression to hide all the classes (and not simply *), that's because
this is not a file system like wildcard, but a java regular expression: see the <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html">Pattern</a> javadoc for further details.
parameter to specify in which folder the .dot files should be generated.
If you're wondering why we used ".*" as the regular expression to hide all the classes (and not simply *), that's because
the specification is not a filename globbing pattern, but a Java regular expression:
see the <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html">Pattern</a> class documentation for further details.
</notes>

View File

@ -14,8 +14,8 @@
<ch><ti>Class Diagram Example: Real Example (Catalina Classes)</ti><fi>ceg-cat</fi></ch>
<ch><ti>Class Diagram Example: Class Stereotypes and Tagged Values</ti><fi>ceg-ster</fi></ch>
<ch><ti>Class Diagram Example: Colors, Global and Local Options</ti><fi>ceg-color</fi></ch>
<ch><ti>Class Diagram Example: Multiple Views (command line)</ti><fi>ceg-mv</fi></ch>
<ch><ti>Class Diagram Example: Multiple Views (internal support)</ti><fi>ceg-mvi</fi></ch>
<ch><ti>Class Diagram Example: Multiple Views Through Command-Line Options</ti><fi>ceg-mv</fi></ch>
<ch><ti>Class Diagram Example: Multiple Views Using the Built-in Support</ti><fi>ceg-mvi</fi></ch>
<ch><ti>Sequence Diagrams</ti><fi>seq-intro</fi></ch>
<ch><ti>Syntax of Sequence Diagram Definitions</ti><fi>seq-syntax</fi></ch>
<ch><ti>Defining a Simple Sequence Diagram</ti><fi>seq-simple</fi></ch>

View File

@ -7,11 +7,13 @@
<ul>
<li> Correct the handling of qualified class names following
the extends keyword (Arnaud Rogues).</li>
<li> A <em>views</em> feature provides the ability to specify package-based
option overrides in UMLOptions like classes,
and to generate multiple diagrams out of a code base in a single pass.
See the new tags @view, @opt_override, @hideall, and the command line
parameters -d, -view, -views (Andrea Aime)</li>
<li> Javadoc documentation (Andrea Aime).</li>
<li> Centralized option handling in the Option class (even for command line arguments) (Andrea Aime).</li>
<li> Addded "views", that is, the ability to specify package based option overrides in UMLOptions like classes,
and to generate multiple diagrams out of a code base in a single pass. See the new tags @view, @opt_override,
@hideall, and the command line parameters -d, -view, -views (Andrea Aime)</li>
</ul>
<dt>Version 4.1 2005/11/15</dt><dd>