Why does adding an element cause major diagram repositioning? (deployment, class)

0 votes
asked Oct 18, 2021 in Question / help by mawi (620 points)

Another try at a semi-complicated deployment diagram (content is deployment:ish).

Background: I add components one by one, it works (see on plantuml server here)

until I get to "aabb9" (i e a9)...

Problem: When I add aabb9 to be the target of an "up" arrow from aabb5, I expect aabb9 to be placed above aabb5, where there is space. Like this:


Instead, the diagram layout is almost completely redone by the engine, and seemingly, the previously defined relationships are no longer "respected". So the (bad) result becomes:
enter image description here

Notice how the first nodes now come rightmost, and my relationships specified to be going to the right from those two (aabb1 & aabb2), are no longer "respected"/drawn as entered. Here is that same drawing with the line uncommented, and the "bad"/undesired result.

So, below here is the code that works, but if you uncomment the last line, it goes bananas and "relayouts" the whole thing.

Any clues to this? It would be cool to be able to create these simple diagrams with text...

Thanks! /mawi

@startuml
skinparam ranksep 5
skinparam nodesep 5

rectangle "aabb1" {
    node aabb1 as a1
    node aabb2 as a2
}
a1 --[hidden]> a2

control "aabb3" as a3
database "aabb4" as a4
queue "aabb5" as a5
control "aabb6" as a6
control "aabb7" as a7
database "aabb8" as a8
control "aabb9" as a9

a1 -right-> a3: Range
a2 -right-> a3: 3D Models
a3 -down-> a4: Range & Models
a3 -> a5: product.\nupsert

a5 -down-> a6: product.\nupsert
a6 -> a5: product.\nprocessed

a5 -> a7: product.processed
a7 -> a8: Data
a7 -> a5: product.\nstored

'a5 -up-> a9: product.stored

@enduml

1 Answer

+1 vote
answered Oct 18, 2021 by The-Lu (46,400 points)
selected Oct 19, 2021 by mawi
 
Best answer

Hello M.,

Just add (I do not know why wink):

a9 -[hidden]-> a5
a5 -up-> a9: product.stored

Then we observed the expected result:

Regards,
Th.

commented Oct 19, 2021 by Martin (8,280 points)

A minor refinement is to use:

a9 <-- a5: product.stored

I also took out all the other directions because they're not needed (for this cut of the diagram).

(click for online server)

commented Oct 19, 2021 by mawi (620 points)

Thanks!

I have worked a bit with this again (after having skipped it for many years), and I think the layout generation is still too "random" to be usable for larger diagrams (unless there is a special requirement to use plantuml for whatever reason). Its like you say, one has no idea why something works, the only working approach is trial and error for each change. It would likely be impossible to create a large deployment diagram with many nodes, ranks and columns and count on it to be right.

In this case, the right answer was to add the node flow from the independent/new node to the rest of the diagram, and not the other way around. But! I tried applying this heuristic consistently as I continued drawing, and found it does not work consistently either. I added a new element to the right of aabb6 (below aabb7) and needed to do reverse in order to avoid relayout craziness.

I really long for a dependable handling of the diagram descriptions that yields deterministic results and less bananas. In the end, it will be so cool!

commented Oct 19, 2021 by Martin (8,280 points)
edited Oct 19, 2021 by Martin
Vertically it works best if you always put the higher node first in the arrow, and avoid using U/D by using arrow direction instead.  (arrow should be --> or longer).

Similarly for horizontally, try putting the left node first and using -> or <- rather than using L/R.

(I'm not saying this works in all cases.)
...