Question
Which visibility keyword interpretations cause accidental public access in UML code generation?
Sky Finch
0 reputation · 01 Sept 2024, 06:44 UTC
26.7K views
Loading…
0 reputation · 01 Sept 2024, 06:44 UTC
UML 2.5 specifies four visibility keywords—public, private, protected, and package—to enforce access boundaries on class members during model-to-code transformation.
Despite this formalism, code generation tools apply these keywords inconsistently: some enforce the declared access, others default to public for unspecified members, and many reset or ignore the isDerived attribute flag during model synchronization.
This variability can produce mismatched access modifiers and unintended data exposure, particularly in collaborative workflows where multiple tools process the same UML model.
The resulting discrepancies risk accidental public visibility of elements intended to remain private or protected, undermining the model's access-control intent.
Which visibility keyword interpretations lead to accidental public access across common UML code generators? Does the isDerived flag survive model synchronization without explicit preservation, and what alternatives maintain derived-status semantics? What practical workflows can modelers adopt to detect and reconcile these inconsistencies before code deployment?
The visibility interpretations that most often produce accidental public access are:
unifiedmodelinglanguagepublic when the UML model omits a visibility attribute entirely.public or protected instead of package-private (no modifier).private/protected modifiers and resets them to public.The isDerived flag (leading slash) is not an access modifier and is routinely dropped during XMI interchange or tool synchronization unless the exchange explicitly preserves it. Alternatives that survive interchange better include tagged values, stereotypes, or OCL-derived constraints.
UML 2.x defines four VisibilityKind literals unambiguously: public (+), private (-), protected (#), package (~). The specification is clear; the risk lies in tool implementation.
| Visibility in Model | Typical Java Mapping | Common Divergence |
|---|---|---|
public (+) | public | Rarely differs |
private (-) | private | May revert to public on round-trip |
protected (#) | protected | May revert to public on round-trip |
package (~) | (no modifier) | Often emitted as public or protected |
| unset/absent | public (default) | Silent widening — highest risk |
Caution: Package-private in Java appears as no modifier in source. "No keyword in generated code" can mean either correct package mapping or a generator bug; context is required to distinguish them.
visibility attribute and that isDerived appears where expected.private/protected never appear as public in generated sources.Which specific code generator(s) and version(s) are in your workflow? The exact mapping table is vendor- and version-specific; knowing the tool lets me confirm whether its documented defaults match the patterns above or introduce additional quirks.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.