Increase support of Plantuml diagrams for ArchUnit

[udelledo]

Hi, I'm not entirely sure this should be opened an issue, but from what I could see, an issue seems to be the best way to start a discussion on possible improvements before jumping into coding.

I'm a user of Plantuml and I'm starting to play around with ArchUnit.

I would like to be able to reuse more of the diagrams that I generally write during development.

After checking the documentation and playing a with the library a bit, I realized that the current support for plantuml is very useful for layered architecture to ensure that all different layers of a project play nice together, but the limitation on how the diagrams are interpreted (i.e. allowing only one occurrence of a stereotype) per diagram, "forces" users to create a number of different tests that load a different list of classes to validate against the same diagram, or a number of diagrams with different views.

I would like to be able to parse diagrams like this one or this one, and I'm willing to implent the parsing of these type of diagram, but I wanted to confirm if this would be an acceptable feature to integrate.

Thanks

[hankem]

First of all, thanks for bringing up the idea – and sorry for the late feedback! 🙈

I just had a closer look at your diagrams. Do I understand correctly that your goal is to draw multiple components of each type <<..listener..>> and <<..service..>>, but still draw the dependencies (redundantly) between those components?

I'd worry that the redundancy allows for a lot of inconsistencies (which would probably have to be rejected?), e.g. like in this diagram: Should <<..listener..>> now be allowed to depend on <<..service..>>, or <<..sql..>>, or both? And should [A listener] --> [A service] in your example additionally be considered as specific dependency between specific [A listener] and [A service] classes?

Based on your second example, but trying to stay unambiguous, I could imagine to declare dependencies between packages instead of components, as in this diagram. Would this fit your use case, too?

[udelledo]

Hi Manfred, thanks for the feedback, and I'm sorry too about the tardiness of my reply....

To clarify your doubts, the way I was picturing the behavior is that when a narrower dependency is described in a diagram there should be no assumption on broader dependencies.

Building on top of the first link, I enriched the diagram a bit

In this case I would expect no general assumption are made between packages other that the services belong to the package, but the dependencies should be checked only for concrete classes.

Describing the example I might have a third listener that is used to work with a legacy service that was storing data in a sql db, to a newer service that stores the data in a NoSQL db. The listener should never interact directly with the DAO, but only use the Another service class to manipulate the data.

Basically what I would like to achieve is that in a single diagram I can express at the same time:

• specific classes belongs to specific packages (i.e. all listeners classes belong to a listener package): this should not really be checked as a failure of the test, but a human reading the diagram would see this.
• The dependencies between classes are only the one described by the relations in the diagram: this is the type of failure I would expect from the test.

The use case for this would be that the plantuml diagram is easily accessible in the repository (some git services offers automatic rendering of plantuml files) so humans browsing the project could grasp with a simple look at the diagram what's what (provided a good legend, and the diagram itself is not messy)

And the test would make sure that the code does not have unexpected dependencies (i.e. no new usage of the legacy service)

Please let me know if this clarifies your doubts