UML 2.5.1 Visibility: Protected Modifier Mapping Across Architectural Layers

Answer

In UML 2.5.1 a # (protected) visibility is defined as “visible to the owning classifier and its descendants via generalization.” The UML language has no notion of architectural layers, modules or deployment boundaries, so it cannot limit protected visibility to a single package or layer. In other words, the specification provides no formal mechanism to restrict protected visibility across separate architectural layers.

How to model strict layer‑to‑layer encapsulation

1. Model each layer as a separate UML package. Place all classes that belong to a given architectural layer inside one package.
2. Use package visibility (~) on the boundary. Declaring an attribute or operation as ~ makes it visible only to elements that belong to the same package.
3. Avoid cross‑package inheritance when strict isolation is required. If a subclass must live in another layer, expose the required members through interfaces or DTOs that are also package‑visible.
4. Map to the target language carefully. When generating code, remember that # maps differently: Java protected is package‑plus‑subclass, C# protected is subclass‑only, C++ protected is subclass‑only, and Python relies on convention.
5. Consider a custom profile. If your modeling tool supports it, create a stereotype such as <<layerProtected>> that enforces layer boundaries via tool‑specific validation rules.

Why protected cannot enforce layer boundaries

• UML’s visibility kinds are defined only for NamedElement and apply to its owning Classifier and any Generalization relationships.
• Package visibility (~) is the only kind that respects namespace membership; protected ignores package boundaries for subclasses.
• Architectural layers are a conceptual design decision, not a UML namespace type, so they are outside the scope of the visibility model.

Practical verification steps

1. Open your UML tool (e.g., Enterprise Architect, Papyrus, Modelio).
2. Create two packages: Domain and DTO.
3. Define a class Domain::Entity with a protected attribute #id.
4. Attempt to subclass DTO::EntityDto from Domain::Entity and generate code for Java and C#.
5. Verify that in Java the generated EntityDto can access id (because protected includes same package), whereas in C# it cannot (protected is subclass‑only).
6. If the generated code exposes id in a public API, change the visibility to ~ or move the class into the same package.

What to check next

Which implementation language are you targeting? The mapping of protected visibility differs between Java, C#, C++, and other languages, and that may influence the exact strategy you need to adopt.