Introduction

Representing a C# property in UML is about showing the public contract clearly while keeping implementation detail at the right level. In class diagrams, properties can be modeled either as attributes with accessor hints or as explicit getter and setter operations. The best representation depends on diagram audience and whether the model is conceptual, design-level, or code-close.

Understand What a C# Property Means

A C# property encapsulates access to underlying state through get and set accessors. It may map to a private field, computed logic, validation rules, or external data access.

Because UML models behavior and structure, the diagram should communicate:

• property name and type
• visibility
• mutability such as read-only or write-only
• optional accessor visibility differences

You usually do not need to show backing fields unless they matter to design reasoning.

Standard UML Notation for Properties

A common notation is attribute style inside class compartment:

+ Name: string

Where:

• '+ means public'
• '- means private'
• '# means protected'
• type follows colon

For C# properties, many teams annotate accessor intent in braces-style text or stereotypes, for example readOnly.

Example diagram-style text:

• '+ Id: int readOnly'
• '+ Name: string'
• '+ Password: string writeOnly'

This keeps class view compact while still communicating usage constraints.

Mapping C# Property Variants

Auto-implemented read and write property

C#:

public string Name { get; set; }

UML representation can be:

• '+ Name: string'

If mutability details matter, add note that both read and write are allowed.

Read-only property

C#:

public int Id { get; }

UML representation:

• '+ Id: int readOnly'

Property with private setter

C#:

public DateTime CreatedAt { get; private set; }

UML representation options:

• '+ CreatedAt: DateTime plus note set is private'
• or explicit operations + getCreatedAt(): DateTime and - setCreatedAt(value: DateTime) in detailed diagrams

Attribute Style Versus Operation Style

Two valid strategies exist.

Attribute style

Pros:

• concise
• easy to scan
• ideal for high-level design

Cons:

• may hide accessor-specific rules

Operation style

Pros:

• explicit accessor visibility and behavior
• useful for code generation or low-level design

Cons:

• verbose in larger classes

In most architecture diagrams, attribute style is preferred, with notes for unusual access rules.

Example with PlantUML

PlantUML is a practical way to keep UML diagrams versioned in source control.

1@startuml
2class User {
3  +Id: int <<readOnly>>
4  +Name: string
5  +Email: string
6  +PasswordHash: string <<writeRestricted>>
7}
8
9note right of User::PasswordHash
10Setter is private in implementation.
11end note
12@enduml

This style communicates intent clearly without modeling every method.

Backing Fields and Encapsulation

In C#, properties often wrap private fields.

1private string _email;
2public string Email
3{
4    get => _email;
5    set
6    {
7        if (string.IsNullOrWhiteSpace(value))
8            throw new ArgumentException("Email required");
9        _email = value;
10    }
11}

In UML, avoid showing both _email and Email unless internal state constraints are central to the discussion. Over-modeling implementation details can make diagrams noisy.

Modeling Computed Properties

Computed properties have no stored backing value.

public int Age => DateTime.UtcNow.Year - BirthYear;

Represent as read-only property in UML, optionally with a note that value is derived. This helps readers avoid assuming persisted state.

Team Conventions Matter

UML has flexibility, so consistency is critical. Establish one property convention for your team and use it across diagrams.

A practical convention set:

• attribute style by default
• annotate read-only and restricted setters
• show backing fields only when required for reasoning
• use notes for validation-heavy properties

This keeps diagrams readable across projects and reviewers.

Common Pitfalls

• Showing every backing field and property pair, which clutters class diagrams.
• Omitting mutability details for read-only or restricted-set properties.
• Mixing attribute and operation style randomly across one diagram set.
• Using notation that team tools cannot render consistently.
• Treating UML as code dump instead of communication artifact.

Summary

• Model C# properties in UML with clarity first, detail second.
• Attribute-style notation is usually best for readable class diagrams.
• Add mutability and accessor-visibility hints when they affect design.
• Use operation-style notation only when accessor behavior must be explicit.
• Consistent team conventions make UML diagrams useful and maintainable.