Refactor pyerverse Association Logic

[Julfried]

Type of Changes

	Type
✓	🐛 Bug fix
✓	🔨 Refactoring

Description

Closes #9045

Summary

Fixed incorrect UML semantics in pyreverse for aggregation vs composition relationships. The previous implementation had no explicit CompositionsHandler class and did not differentiate between Aggregation and Composition properly, treating most relationships as aggregation by default.

Problem

Pyreverse previously lacked proper UML relationship semantics. So I would proposes the following distinction for Python class relationships:

fields.py

# Test for https://github.com/pylint-dev/pylint/issues/9045

class P:
    pass

class A:
    x: P  # just type hint, no ownership → Association

class B:
    def __init__(self, x: P):
        self.x = x  # receives object, not created → Aggregation

class C:
    x: P
    def __init__(self, x: P):
        self.x = x  # receives object, not created → Aggregation

class D:
    x: P
    def __init__(self):
        self.x = P()  # creates object → Composition

class E:
    def __init__(self):
        self.x = P()  # creates object → Composition

fields.mmd

classDiagram
  class A {
    x
  }
  class B {
    x
  }
  class C {
    x
  }
  class D {
    x
  }
  class E {
    x
  }
  class P {
  }
  P --> A : x
  P --* D : x
  P --* E : x
  P --o B : x
  P --o C : x

Changes Made

1. Added CompositionsHandler

Created dedicated handler following chain of responsibility pattern:
CompositionsHandler → AggregationsHandler → AssociationsHandler

2. Updated Printers

• Added EdgeType.COMPOSITION enum value
• Updated MermaidJS and PlantUML printers with correct arrows per Mermaid docs
• For the Dot printer I used plain arrows, but I did not manage to find something in the dot language documentation

3. Prevented Duplicate Relationships

Modified extract_relationships() to process relationships by priority and avoid duplicates.

Currently I only made the modifications needed to implement the new Associations Logic. If you like the proposed distinction I would work on making the tests pass :)

[github-actions]

🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉

This comment was generated for commit d0ea86e

[DudeNr33]

I like the addition! 👍

I only left two remarks for cases where at least from the comment it seems like the relationship is processed by the wrong handler. Am I missing something?

It would be great if you can add tests for all possible output formats as all printers where changed. You can specify multiple output formats for a single functional test in the [testoptions].

[DudeNr33]

Wouldn't this be composition as well as in the example P is instantiated by the class?

[Julfried]

Thanks, I would agree here. I think we need to differentiate here aswell (I need to handle list comprehensions in both the AggregationsHandler and the CompostionsHandler)

[DudeNr33]

From the PR description the type annotation case would be association, not aggregation?

[Julfried]

Agree, thank you. That case needs to move aswell

[Julfried]

Thanks for the review. I agree that the logic is not complete and it needs some more work and I need to figure out all the possible edge cases. Also I think some of the other tests have changed , and I need to rebase aswell. I think this will take some time, but lets see how it goes :)