UML 2.5 Stereotype Application Lacks Mandatory Visibility Constraints

Short answer

UML 2.5 defines stereotypes as a profile mechanism for extending metaclasses, but it does not impose a constraint that forces tools to preserve or enforce the base element's visibility when a stereotype is applied. Visibility (private, package, protected, public) is a property of the named element itself; applying a stereotype adds tagged values and semantics, it does not redefine access rules. So the gap you describe is real: the standard is silent, and behavior is tool-defined. In practice, manual or scripted validation is the accepted practice — there is no vendor obligation to enforce visibility on your behalf.

Confirmed facts vs. likely explanation

Confirmed by the specification's structure: UML 2.5's Profiles clause describes how stereotypes extend metaclasses and how they are applied; it does not attach visibility-preservation constraints to stereotype application. Visibility remains an attribute of NamedElement/PackageableElement, orthogonal to profiling.

Likely explanation: The omission is intentional scope separation. Stereotypes are a metadata extension mechanism, not an access-control mechanism. The spec authors left rendering and code-generation semantics to tool vendors and to transformation languages (e.g., MOFM2T/Acceleo, or proprietary generators). The side effect is exactly what you observed: a private class carrying a stereotype may be rendered or generated as public if the tool's transformation ignores the visibility attribute.

Should vendors enforce it, or is manual validation accepted?

Manual validation is the de facto standard. Vendors treat visibility as data the transformation template may or may not consult, not as a rule the tool must enforce. If your models are security-relevant, assume the tool will not protect you and build enforcement into your pipeline.

A practical validation approach

1. Model-level checks. Write validation rules that run before export or generation. In Eclipse-based toolchains, an OCL constraint or EMF validation rule can assert that any element carrying a given stereotype retains its declared visibility. In Enterprise Architect, a script (VBScript/JScript) or a model validation add-in can walk stereotyped elements and flag visibility mismatches. MagicDraw supports validation suites via its API or OCL constraints.
2. Generation-level checks. If you generate code, put the rule in the template: the generator should read the element's visibility and emit the corresponding access modifier, regardless of stereotype. A template that hardcodes public for stereotyped elements is the defect to fix.
3. Output-level checks. As a safety net, lint the generated artifacts. For example, a simple grep over generated Java for stereotype-marker interfaces or annotations on public classes that should be package-private:

grep -rn "public class" generated/ | grep -f private-elements.txt

Verifying tool compliance without a standard mandate

Because there is no normative baseline, build a small conformance test yourself:

1. Create a minimal model: one class per visibility kind (public, package, private), each with the stereotype applied.
2. Export to XMI and confirm the visibility attribute survives the round trip — XMI export usually preserves it, which tells you the model is fine and the problem is in rendering/generation.
3. Run the diagram renderer and the code generator. Diff the outputs against expected visibility. Any promotion to public is a tool-specific behavior you must override in settings or templates.
4. Re-run after any tool upgrade; defaults can change between versions.

Assumptions and uncertainty

This reflects UML 2.5 (formal/2015-era specification) and general, long-standing tool behavior; specific vendor defaults in current Enterprise Architect or MagicDraw releases should be verified against your installed version, since vendors do change templates and validation options. One missing detail that would change the recommendation: whether your concern is diagram rendering only or code generation — the fix location (view filter vs. transformation template) differs.