|
1 | 1 | # Architecture |
2 | 2 |
|
| 3 | +<!-- toc --> |
| 4 | + |
| 5 | +* [Overview](#overview) |
| 6 | +* [Configuration model](#configuration-model) |
| 7 | +* [Diagram model](#diagram-model) |
| 8 | + * [Common model](#common-model) |
| 9 | + * [Diagram filters](#diagram-filters) |
| 10 | +* [Translation unit visitors](#translation-unit-visitors) |
| 11 | +* [Diagram generators](#diagram-generators) |
| 12 | +* [Command line handler](#command-line-handler) |
| 13 | +* [Tests](#tests) |
| 14 | + * [Unit tests](#unit-tests) |
| 15 | + * [Test cases](#test-cases) |
| 16 | + * [Real code tests](#real-code-tests) |
| 17 | + |
| 18 | +<!-- tocstop --> |
| 19 | + |
| 20 | +This section presents general architecture and components of `clang-uml`. |
| 21 | + |
| 22 | +> All diagrams below are generated by `clang-uml` and updated automatically. |
| 23 | +
|
| 24 | +## Overview |
| 25 | + |
| 26 | +`clang-uml` is written in C++17 and |
| 27 | +uses [Clang LibTooling API](https://releases.llvm.org/16.0.0/tools/clang/docs/LibTooling.html) |
| 28 | +to traverse |
| 29 | +the AST (Abstract Syntax Tree) of the source code and extract any information |
| 30 | +relevant for a specified diagram. |
| 31 | + |
| 32 | +The code is divided into several packages (namespaces), the main of them are: |
| 33 | + |
| 34 | +- [`clanguml::config`](./namespaceclanguml_1_1config.html) - configuration |
| 35 | + handling |
| 36 | +- [`clanguml::common`](./namespaceclanguml_1_1common.html) - common interfaces |
| 37 | +- [`clanguml::class_diagram`](./namespaceclanguml_1_1class__diagram.html) - |
| 38 | + specializations for class diagrams |
| 39 | +- [`clanguml::sequence_diagram`](./namespaceclanguml_1_1sequence__diagram.html) - |
| 40 | + specializations for sequence diagrams |
| 41 | +- [`clanguml::include_diagram`](./namespaceclanguml_1_1include__diagram.html) - |
| 42 | + specializations for include diagrams |
| 43 | +- [`clanguml::package_diagram`](./namespaceclanguml_1_1package__diagram.html) - |
| 44 | + specializations for package diagrams |
| 45 | + |
| 46 | + |
| 47 | + |
| 48 | +## Configuration model |
| 49 | + |
| 50 | +The configuration model consists of classes representing the configuration |
| 51 | +specified in the YAML configuration files. |
| 52 | + |
| 53 | +Depending on the option, it can either: |
| 54 | + |
| 55 | +- be specified only at the top level of the configuration file |
| 56 | +- only in the specific diagram configuration |
| 57 | +- either of the above |
| 58 | + |
| 59 | +The first group of options are stored in |
| 60 | +the [`config::config`](structclanguml_1_1config_1_1config.html) class. |
| 61 | + |
| 62 | +The second group is stored in a specific diagram config subclass, e.g. |
| 63 | +[`config::sequence_diagram`](structclanguml_1_1config_1_1sequence__diagram.html) |
| 64 | + |
| 65 | +The options in the last group are modeled in the |
| 66 | +[`config::inheritable_diagram_options`](./structclanguml_1_1config_1_1inheritable__diagram__options.html). |
| 67 | + |
| 68 | + |
| 69 | + |
| 70 | +The YAML configuration file is parsed |
| 71 | +using [yaml-cpp](https://github.com/jbeder/yaml-cpp) library: |
| 72 | + |
| 73 | + |
| 74 | + |
| 75 | +For each possible option type, there must an implementation of a |
| 76 | +YAML decoder - e.g. |
| 77 | +[`YAML::convert<filter>`](./structYAML_1_1convert_3_01filter_01_4.html) |
| 78 | +(for converting YAML nodes to configuration model classes) |
| 79 | +and a YAML emitter - e.g. |
| 80 | +[`operator<<`](./group__yaml__emitters.html#ga4c8bc075684b08daa379aef609bb6297) |
| 81 | +(for generating YAML from configuration model classes). |
| 82 | + |
| 83 | +## Diagram model |
| 84 | + |
| 85 | +The diagram model namespace is divided into the [`common`](#common-model) model |
| 86 | +namespace and 1 namespace for each supported diagram type. |
| 87 | + |
| 88 | + |
| 89 | + |
| 90 | +### Common model |
| 91 | + |
| 92 | +The [common diagram model namespace](./namespaceclanguml_1_1common_1_1model.html), |
| 93 | +provides a set of classes representing typical UML and C++ concepts such as |
| 94 | +diagram elements, packages, templates, and others which are shared by more than |
| 95 | +1 diagram type. |
| 96 | + |
| 97 | + |
| 98 | + |
| 99 | +The diagram elements are composed into a hierarchy spanning all major |
| 100 | +namespaces, |
| 101 | +depending on whether the element is specific for a single diagram type ( |
| 102 | +e.g. [`participant`](./structclanguml_1_1sequence__diagram_1_1model_1_1participant.html)), |
| 103 | +or whether it's common for several diagram types ( |
| 104 | +e.g. [`package`](./classclanguml_1_1common_1_1model_1_1package.html)). |
| 105 | + |
| 106 | +### Diagram filters |
| 107 | + |
| 108 | +In order to ease the generation of diagrams, `clang-uml` has a (very) simple |
| 109 | +intermediate UML model, which covers only the features necessary for |
| 110 | +generation of the supported diagram types. The model can be extended if |
| 111 | +necessary to add new features. |
| 112 | + |
| 113 | + |
| 114 | + |
| 115 | +## Translation unit visitors |
| 116 | + |
| 117 | +The first stage in the diagram generation involves traversing the AST of |
| 118 | +each translation unit from the `compile_commands.json` compilation database, |
| 119 | +which matched at least one pattern specified in the `glob` pattern of the |
| 120 | +configuration file. |
| 121 | + |
| 122 | +Each visitor is implemented in a subclass of |
| 123 | +[`translation_unit_visitor`](./classclanguml_1_1common_1_1visitor_1_1translation__unit__visitor.html), |
| 124 | +and must also implement relevant methods from Clang's |
| 125 | +[RecursiveASTVisitor](https://clang.llvm.org/doxygen/classclang_1_1RecursiveASTVisitor.html). |
| 126 | + |
| 127 | + |
| 128 | + |
| 129 | +The output of the `translation_unit_visitor` for each diagram type is an |
| 130 | +intermediate diagram model, which is then passed to the relevant diagram |
| 131 | +generator. |
| 132 | + |
| 133 | +## Diagram generators |
| 134 | + |
| 135 | +Diagram generators convert the `clang-uml`'s internal UML model into actual |
| 136 | +diagram in one of the supported formats: |
| 137 | + |
| 138 | +- PlantUML |
| 139 | +- JSON |
| 140 | + |
| 141 | +Each diagram generator extends a common interface appropriate for the |
| 142 | +selected output format, i.e.: |
| 143 | + |
| 144 | +- [PlantUML](classclanguml_1_1common_1_1generators_1_1plantuml_1_1generator.html) |
| 145 | +- [JSON](classclanguml_1_1common_1_1generators_1_1json_1_1generator.html) |
| 146 | + |
| 147 | +and renders the output to a file. For each diagram type there is a separate |
| 148 | +generator for each supported output format. |
| 149 | + |
| 150 | +## Command line handler |
| 151 | + |
| 152 | +The [cli_handler](classclanguml_1_1cli_1_1cli__handler.html) is a command line |
| 153 | +handler class is a wrapper around [CLI11](https://github.com/CLIUtils/CLI11), |
| 154 | +and implements handlers for various actions, validates command line parameters |
| 155 | +and reports errors. |
| 156 | + |
| 157 | +## Tests |
| 158 | + |
| 159 | +### Unit tests |
| 160 | + |
| 161 | +Basic set of units tests are stored in |
| 162 | +[tests/test_*.cc](https://github.com/bkryza/clang-uml/tree/master/tests) |
| 163 | +test files. The unit tests do not aim to cover the entire codebase, only |
| 164 | +specific algorithms or methods, which should behave as expected and if their |
| 165 | +errors can be difficult to diagnose when running the test cases on C++ code. |
| 166 | + |
| 167 | +### Test cases |
| 168 | + |
| 169 | +These tests are the main tests of `clang-uml`. Each test case tests one or |
| 170 | +more feature of a specific diagram type. Each of them has a separated directory |
| 171 | +in the `tests` directory and its own `.clang-uml` with diagram configuration |
| 172 | +as well as a `test_case.h` file which contains the tests assertions. |
| 173 | + |
| 174 | +Any other sources in that directory are compiled and then used to generate the |
| 175 | +diagrams, whose contents should be then verified within `test_case.h` |
| 176 | +for correctness. All the sources should be wrapped within a namespace: |
| 177 | +`clanguml::` |
| 178 | + |
| 179 | +These test directories are numbered in consecutive numbers using the following |
| 180 | +convention: |
| 181 | +- Start with a letter `t` |
| 182 | +- The first digit of the number is the diagram type: |
| 183 | + - `0` - class diagram |
| 184 | + - `2` - sequence diagram |
| 185 | + - `3` - package diagram |
| 186 | + - `4` - include diagram |
| 187 | + - `9` - other test cases |
| 188 | +- The rest of the name is the consecutive number of the test case |
| 189 | + |
| 190 | +Each test case is also referenced in |
| 191 | +[test_cases.yaml](https://github.com/bkryza/clang-uml/blob/master/tests/test_cases.yaml) |
| 192 | +where it has assigned a title. That file is used to generate the [test cases |
| 193 | +documentation page](./md_docs_2test__cases.html). |
| 194 | + |
| 195 | +### Real code tests |
| 196 | + |
| 197 | +Each release is tested on a set of open-source C++ projects, to be sure that |
| 198 | +at least the new version does not crash or introduce some obvious regressions. |
| 199 | + |
| 200 | +The tests are stored in a separate |
| 201 | +repository: [clang-uml-examples](https://github.com/bkryza/clang-uml-examples). |
| 202 | + |
0 commit comments