Relax Visibility of Generated Members

[schmalzing]

Issue description

When generating Java code from class diagrams, members modeled as private or package-private should be relaxed to protected in the generated code.

This behavior must be ensured consistently across all relevant generator paths. The current implementation has not been reviewed comprehensively, and it is therefore unclear whether every generated representation of a private model member is handled accordingly.

In particular, generated accessor methods need to be considered. If a getter or setter derives its visibility from the corresponding attribute, it must use protected visibility as well when the attribute is modeled as private. Otherwise, the generated field and its generated accessors may expose inconsistent visibility.

Reproduction

Create a class diagram containing private attributes and methods, for example:

classdiagram CD1 {
  class A {
    private String value;
    private void validate();
  }
}

Generate the corresponding Java sources using CD2Pojo and inspect all generated members and generated accessors related to value and validate.

Actual behavior

The visibility-relaxation behavior for members modeled as private is currently not verified across all relevant generation paths.

Depending on the affected generated artifact, private model members, generated fields, getters, setters, or other generated references may still use private visibility or may derive their visibility inconsistently from the original model member.

As a result, generated classes may not provide the intended extension points for subclasses, or the generated attribute and its corresponding accessors may expose different visibility levels.

Expected behavior

CD2Pojo should consistently generate protected visibility for all Java members that originate from model members declared as private, wherever visibility relaxation is intended.

For the example above, the generated code may look like:

public class A {
  protected String value;

  protected void validate() {
    // ...
  }

  protected String getValue() {
    return this.value;
  }

  protected void setValue(String value) {
    this.value = value;
  }
}

If getters and setters derive their visibility from the corresponding attribute, they must apply the same transformation from private to protected.

Impact

Inconsistent visibility generation can prevent handwritten subclasses from accessing or overriding generated members, mockups, and tests.

Furthermore, differing visibility between a generated attribute and its getter or setter can lead to an inconsistent generated API and make extension behavior dependent on the particular generated artifact being used. Since the behavior is distributed across generator paths, such issues may only become visible when compiling or extending generated code.