Skip to content

Qualifier labels and associations' lines not correctly drawn for qualified associations #1467

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
travkin79 opened this issue Jun 23, 2023 · 4 comments
Labels

Comments

@travkin79
Copy link
Contributor

travkin79 commented Jun 23, 2023

Problem description
When using qualified associations the qualifier labels overlap with classes, are placed on the wrong side of an association, or the association's line between the qualifier and the target class is not visible. In addition, the length of edges cannot be modified if a direction is added to the association definition.

I have a few examples to illustrate that.

This issue is a follow up of a previous discussion in the user forum. That discussion contains hints to additional issues with qualified associations.

Steps to reproduce - Example 1

  1. Create a diagram as follows
@startuml
    interface Map<K,V>
    class HashMap<Long,Customer>

    Map <|.. HashMap
    Shop [customerId: long] ---> "customer\n1" Customer
    HashMap [id: Long] -r-> "value" Customer
@enduml
  1. Observe the rendered result. Here, the qualifier label "id: Long" overlaps with the class Customer and hides the association line between the classes HashMap and Customer or it doesn't exist at all. There has to be a bigger distance between the classes HashMap and Customer for the association to be drawn correctly.
    Please notice that the association length between the classes Shop and Customer could successfully be drawn longer than usually by writing ---> instead of -->.

image

Expected behavior
I expected the diagram to look something like
image

Steps to reproduce - Example 2

  1. Create a diagram as follows
@startuml
    class HashMap<K,V>

    HashMap [key: K] -u-> V1
    HashMap [key: K] -r-> V2
    HashMap [key: K] -d-> V3
    HashMap [key: K] -l-> V4
@enduml
  1. Observe the rendered result. Here, the qualifier labels are not correctly placed in case of associations drawn in the left or up direction. In these cases the labels have to be placed near the HashMap class. In addition, changing the association line's length does not work with a direction hint, i.e. replacing HashMap [key: K] -r-> V2 with HashMap [key: K] -r----> V2 doesn't change the line's length.

image

Expected behavior
I expected the qualified associations to be drawn the same way as the case HashMap [key: K] -d-> V3, but with adapted direction. The result should like something like the following. Increasing the length of the edge in source code (e.g. replacing HashMap [key: K] -r-> V2 with HashMap [key: K] -r----> V2) should increase the rendered association's length.

image

travkin79 added a commit to travkin79/plantuml that referenced this issue Jul 24, 2023
Otherwise, qualifier labels of qualified associations pointing left or up are drawn on the wrong end of the association.
travkin79 added a commit to travkin79/plantuml that referenced this issue Jul 24, 2023
travkin79 added a commit to travkin79/plantuml that referenced this issue Jul 24, 2023
arnaudroques added a commit that referenced this issue Jul 24, 2023
@travkin79
Copy link
Contributor Author

Hi @arnaudroques,
I tried fixing this in PR #1489. Could you take a look at it?

The two examples from above now look as follows:

Case 1:
case1

Case 2:
case2

Drawing arrow heads remains an issue. The arrow head pointing at V4 is missing in case 2. It gets even worse if used with more than one qualifier per association like in the following example. But maybe that should be a separate issue ticket.

@startuml
class HashMap<K,V>
    HashMap [a1] <|-u-> [e] V1
    HashMap [b2] *.r.> [f] V2
    HashMap [c3] o.d.> [g] V3
    HashMap [d4] +-l-> [h] V4

    MoreComplex [x: String] ..> X
    MoreComplex [y: int] --> Y
    MoreComplex [z: boolean] ..> Z
@enduml

case3

@arnaudroques
Copy link
Contributor

You made a good job but there were a small regression on this diagram (for example)

Now my solution is not perfect because we keep running through all links when calling isShielded().

However, I suggest that we first fix all qualified association issues before making any premature optimization.
I let you do some tests to see if the current code is working for you.

Drawing arrow heads remains an issue

That's another story and you should probably open another issue for that.
Here, maybe the generated dot code is not good.
I don't know if you are familiar with Graphviz... (but you will be if you dive in that issue :-)
We will talk about that in the new issue!

@travkin79
Copy link
Contributor Author

travkin79 commented Jul 24, 2023

Thank you. Good you found one of the few cases where the shield size calculation was still necessary in the modified isShielded() method.

I'm not sure, we can avoid running through all the links (in worst case) when calling isShielded(), because we need to know if the current node has at least one link with a qualifier on the node's end.

I've made a few tests with a couple of diagrams. Your change fixed the component diagram examples, but didn't break my example. I think, we can close this ticket now. We'll open another issue for the arrow heads problem. Thank you for the very quick replies and merges.
I'm not familiar with Graphviz, yet, but I'm beginning to dig deeper. :-)

@The-Lum
Copy link
Collaborator

The-Lum commented Jul 19, 2024

[Just for the record]
There are some new overlapping defects about "qualified association":

Regards,
Th.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants