Added option to skip redundant dependency relationships
This commit is contained in:
@@ -37,7 +37,8 @@ diagrams:
|
||||
```
|
||||
|
||||
## Classes and their properties
|
||||
The basic class diagram generated by `clang-uml` and rendered using PlantUML looks like this:
|
||||
The basic class diagram generated by `clang-uml` and rendered using PlantUML
|
||||
looks like this:
|
||||
|
||||

|
||||
|
||||
@@ -45,12 +46,15 @@ Member types and method return types are rendered at the end after `:` sign.
|
||||
|
||||
Static methods and members are underlined.
|
||||
|
||||
In case method argument lists are too long and not required for diagram readability, they can be suppressed completely
|
||||
or abbreviated by setting `generate_method_arguments` option to either `none`, `abbreviated` or `full` (default).
|
||||
In case method argument lists are too long and not required for diagram
|
||||
readability, they can be suppressed completely or abbreviated by setting
|
||||
`generate_method_arguments` option to either `none`, `abbreviated` or `full`
|
||||
(default).
|
||||
|
||||
|
||||
### Excluding private or protected members from the diagram
|
||||
In order to only include public members in the class diagrams, we can add the following inclusion filters:
|
||||
In order to only include public members in the class diagrams, we can add the
|
||||
following inclusion filters:
|
||||
```yaml
|
||||
include:
|
||||
access:
|
||||
@@ -68,7 +72,8 @@ To render only classes without any properties an exclusion filter can be added:
|
||||
|
||||
## Relationships
|
||||
|
||||
The following table presents the PlantUML arrows representing each relationship in the class diagrams.
|
||||
The following table presents the PlantUML arrows representing each relationship
|
||||
in the class diagrams.
|
||||
|
||||
| UML | PlantUML |
|
||||
| ---- | --- |
|
||||
@@ -81,17 +86,18 @@ The following table presents the PlantUML arrows representing each relationship
|
||||
| Nesting (inner class/enum) |  |
|
||||
|
||||
|
||||
By default, a member from which a relationship has been added to the diagram between 2 classes will also be rendered
|
||||
inside the class. This behaviour can be however disabled by adding the following option to the
|
||||
diagram definition:
|
||||
By default, a member from which a relationship has been added to the diagram
|
||||
between 2 classes will also be rendered inside the class. This behaviour can be
|
||||
however disabled by adding the following option to the diagram definition:
|
||||
```yaml
|
||||
include_relations_also_as_members: false
|
||||
```
|
||||
|
||||
### Relationships to classes in containers or smart pointers
|
||||
`clang-uml` will automatically detect class members as well as method arguments, which reference or own
|
||||
values of types relevant for a given diagram but wrapped in smart pointers or containers and still generate
|
||||
relationship between these classes, for instance the following code:
|
||||
`clang-uml` will automatically detect class members as well as method arguments,
|
||||
which reference or own values of types relevant for a given diagram but wrapped
|
||||
in smart pointers or containers and still generate relationship between these
|
||||
classes, for instance the following code:
|
||||
|
||||
```cpp
|
||||
class A { };
|
||||
@@ -114,9 +120,9 @@ results in the following diagram:
|
||||
|
||||
## Inheritance diagrams
|
||||
|
||||
A common type of class diagram is an inheritance diagram, where only subclasses of a specific base class are
|
||||
included and only the inheritance relationships are rendered. This can be easily achieved in `clang-uml` through
|
||||
inclusion filters:
|
||||
A common type of class diagram is an inheritance diagram, where only subclasses
|
||||
of a specific base class are included and only the inheritance relationships are
|
||||
rendered. This can be easily achieved in `clang-uml` through inclusion filters:
|
||||
```yaml
|
||||
include:
|
||||
subclasses:
|
||||
@@ -126,9 +132,10 @@ inclusion filters:
|
||||
```
|
||||
|
||||
## Including packages in the diagram
|
||||
By default, `clang-uml` will render all element names including a namespace (relative to `using_namespace` property),
|
||||
e.g. `ns1::ns2::MyClass`.
|
||||
In order to generate packages in the diagram for each namespace instead, the following option must be set to `true`:
|
||||
By default, `clang-uml` will render all element names including a namespace
|
||||
(relative to `using_namespace` property), e.g. `ns1::ns2::MyClass`.
|
||||
In order to generate packages in the diagram for each namespace instead, the
|
||||
following option must be set to `true`:
|
||||
|
||||
```yaml
|
||||
generate_packages: true
|
||||
@@ -138,8 +145,9 @@ which results in the following diagram:
|
||||
|
||||

|
||||
|
||||
In case the code base is structured based on subdirectory instead of namespaces, packages can be generated
|
||||
based on the location of a given declaration in the filesystem tree, by adding also the following option:
|
||||
In case the code base is structured based on subdirectory instead of namespaces,
|
||||
packages can be generated based on the location of a given declaration in the
|
||||
filesystem tree, by adding also the following option:
|
||||
|
||||
```yaml
|
||||
package_type: directory
|
||||
@@ -149,13 +157,15 @@ which results in the following diagram:
|
||||
|
||||

|
||||
|
||||
> In this case make sure that the root path of the configuration file is properly configured
|
||||
> for your project, if necessary add `relative_to` option to denote the root path
|
||||
> against which all relative paths in the config file are calculated.
|
||||
> In this case make sure that the root path of the configuration file is
|
||||
> properly configured for your project, if necessary add `relative_to` option to
|
||||
> denote the root path against which all relative paths in the config file are
|
||||
> calculated.
|
||||
|
||||
## Class context diagram
|
||||
Sometimes it's helpful to generate a class diagram depicting only direct relationships of a given class, e.g.
|
||||
within the classes' documentation page, this can be easily achieved using `context` inclusion filter:
|
||||
Sometimes it's helpful to generate a class diagram depicting only direct
|
||||
relationships of a given class, e.g. within the classes' documentation page,
|
||||
this can be easily achieved using `context` inclusion filter:
|
||||
|
||||
```yaml
|
||||
include:
|
||||
@@ -164,23 +174,25 @@ within the classes' documentation page, this can be easily achieved using `conte
|
||||
```
|
||||
|
||||
## Disabling dependency relationships
|
||||
In many cases, dependency relationships between classes can clutter the diagram too much, for instance consider this
|
||||
diagram:
|
||||
Dependency relationships are inferred whenever a class uses another class, thus
|
||||
often dependency relationship will be rendered in addition to other
|
||||
relationships such as association or inheritance. By default, `clang-uml` will
|
||||
remove these redundant dependency relationships, however if it is necessary to
|
||||
retain them it can be done using the following option:
|
||||
|
||||

|
||||
```yaml
|
||||
skip_redundant_dependencies: false
|
||||
```
|
||||
|
||||
where the dependency relationships do not bring much information into the diagram. In such cases it might
|
||||
be useful to disable dependency relationships for this diagram completely using the following exclusion filter:
|
||||
In many cases, dependency relationships between classes can clutter the diagram
|
||||
too much. In such cases it might be useful to disable dependency relationships
|
||||
completely for this diagram completely using the following exclusion filter:
|
||||
```yaml
|
||||
exclude:
|
||||
relationships:
|
||||
- dependency
|
||||
```
|
||||
|
||||
Dependency relationships are inferred whenever a class uses another class, thus often dependency relationship
|
||||
will be rendered in addition to other relationships such as association or inheritance. In the future there might
|
||||
be an option to remove the redundant dependency relationships from the diagram automatically.
|
||||
|
||||
It is also possible to only disable dependency relationships generated from
|
||||
template arguments to other templates. By default, the following code:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user