Class Diagram Views

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.

The @view tag, marks a special class used to describe a single class diagram. Similarly to UMLOptions, the view can define its own general options, but allows to define overrides that allow to adopt different options for different classes based on regular expressions matching. The general syntax for defining a view is:

/**
* @view
* @opt [!]viewOption1
* @opt [!]viewOption2
* ...
* @match matchtype regularExpression1
* @opt [!]option1.1 [argument]
* @opt [!]option1.2 [argument]
* ...
* @match matchtype regularExpression2
* @opt [!]option2.1 [argument]
* @opt [!]option2.2 [argument]
* ...
*/

At the moment UMLGraph supports only the 'class' match type, in the future other types of match will be added (tags, implemented interfaces, superclasses, just to name a few possibilities).
The view options are applied to every class in the view (so they are the global options for this class diagram).
The regular expression will be used to match a single class, a group of classes, or a package, and the options that follow will be applied to those classes.
Multiple matches will be evaluted in the order of specification.
Refer to the Pattern class documentation for details on a proper regular expression specification.

Each view will generate a .dot file whose name is the name of the view, unless the "output" option is specified to override it.

View inheritance

View classes can inherit from other view classes, allowing views to share a set of common matches. The standard java inheritance mechanism is used to specify inheritance.
Abstract view classes won't be used to generate diagrams, the common idiom is to declare a base abstract view to share common options and overrides, and have concrete view classes that extend for diagram generation.