I'd like to track my UML diagrams with an SVN repository. I have a StartUML project, where I am drawing several diagrams that describe the requirements and architecture of my software project, and I'd like to manage and track changes for each diagram. I am wondering if there is a way to manage and version StartUML diagrams with SVN. I appreciate any help or suggestion on how to use a version control system like SVN with a StarUML project. Many thanks.
-
Well, don't. Any (UML) model is a complex network, not just some text where you replace some characters. Just adding a single relation might change the meaning of the whole thing. Even if you make snapshots: how would you know what the changes made acually _mean_? – qwerty_so Jul 01 '22 at 21:56
-
@qwerty_so The question is not about tracking the semantics. Source code control don't track semantics of code either, and just track changed lines. It's about keeping track of versions of a model. If people are able to write a version number on a model diagrams, it makes sense to find back previous versions. This is even more justified, if your model is maintained in sync with some technical documentation or with the code. The fact of being able to restore a consistent set of code + documentation + model more than justifies version control ing all of them together. – Christophe Jul 01 '22 at 22:25
-
But it will indeed be difficult to attribute individual changes in the model to individual authors because the text format is difficult to read. – Christophe Jul 01 '22 at 22:26
1 Answers
Source code management systems like SVN and GIT are designed to manage and track changes of text files. They are much less efficient with binary files.
Fortunately, StartUML stores the model in a file using the .MDJ
format which appears to be plain JSON text format. So as long as the source code management system scans the MDJ extension (if the file is stored in a tracked repository and if you commit it), it will monitor changes to the JSON file exactly as for the other source code files:
- Changes are stored efficiently.
- You can change between versions exactly in the way you'd navigate between versions for normal source file. You just need to close the model in StartUML and reload it again afterwards.
- If you master the JSON format, you could do a git blame to see which line comes from which commit. You could even manage merge conflicts, however, only if you're fluent with JSON ;-)
Unfortunately, you have not very much control on the layout of the tracked file: small visual changes might lead to lots of changed lines. Moreover, unless you succeed in extracting each JSON part corresponding to a separate diagram in a separate file, the changes will be tracked at model level.
The tool seems to offer a fragment export/import function that allows to manually select model elements/diagrams to be individually saved in a separate file. However, it seems not appropriate for a systematic tracking of diagram changes, since it relies on an additional operation from a user, which can easily be forgotten. Unreliable versioning is in this regard worse than no versioning at all.
If you want to have things under tighter control, you could use the approach of "model as code", and use tools such as plantuml to write your diagrams as you'd do with code, grouping related items together and having separate (human readable) files for separate diagrams, and let the tool generate the diagrams based on text (you wouldn’t version the binary files corresponding to the rendering; only the text files).

- 68,716
- 7
- 72
- 138
-
-
many thanks all for your suggestions/comments. The issue is that I am using StarUML for tracking requirements with UML model, but also for documenting the software architecture. I am trying to understand if with UML diagrams there is a common strategy for versioning and tracking the modification. I know that it is not a text like the source code, but I am wondering if there is a "pattern" or "strategy" for UML diagrams. – Frank Jul 04 '22 at 10:26
-
@Frank there’s no common version management strategy for UML. It’s a question of mindset. Requirements for example are rarely discovered at once, and successive changes to the model are often viewed as iterative refinements of THE model and not successive versions. For design models that evolve with the software, a common strategy is to archive the version in sync with the release. If versioning parts is important you may consider use of a stereotype «versioned element» associated with a set of tagged values for versioning info. But it’ll be a manual (error prone) process – Christophe Oct 22 '22 at 07:07