1.1.23 How to Translate a UML Object Diagram to C# Code

Begin with the Object Diagram, Not with C# Syntax

A UML object diagram describes a particular snapshot of a system. Before writing C#, read the model in a consistent order:

1. Identify each object instance.
2. Identify the type of each object.
3. Read the field values shown inside each object.
4. Follow the relationships between objects.

Consider this small soccer model:

player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7

team1 : Team
-------------------------
name = "Wildcats"

player1 -------- team1

The diagram says that two objects exist, each has selected state, and the two objects are related.

Translate Object Headers into Object Creation

The UML header:

player1 : Player

gives you an object identity and a type.

A basic C# creation statement can be:

Player player1 = new Player();

Likewise:

team1 : Team

can map to:

Team team1 = new Team();

At this point, both objects exist in memory. Their scenario-specific field values and relationship still need to be established.

Translate Field Values into Assignments

The UML state:

name = "Jordan"
jerseyNumber = 7

can guide assignments such as:

player1.name = "Jordan";
player1.jerseyNumber = 7;

For the Team:

team1.name = "Wildcats";

Each assignment should preserve:

• the correct object;
• the correct field;
• the correct value;
• the compatible field type.

Translate Relationships into Object References

The UML relationship:

player1 -------- team1

means the two specific objects are connected.

If the supplied Player type has a field that refers to a Team, the C# relationship may be represented as:

player1.team = team1;

The exact member name comes from the supplied project. Do not invent a different field merely because the diagram contains a line.

Use a Translation Order

A reliable order is:

UML objects
    ↓
C# object creation
    ↓
simple field assignments
    ↓
object-reference assignments
    ↓
runtime inspection

This order helps prevent a common error: trying to use a related object before it has been created or connected.

Read the Finished C# Back Against the UML

A small translation can look like:

Player player1 = new Player();
Team team1 = new Team();

player1.name = "Jordan";
player1.jerseyNumber = 7;
team1.name = "Wildcats";

player1.team = team1;

Now read the code as a model:

• one Player object exists;
• one Team object exists;
• the Player has the required values;
• the Team has the required value;
• the Player refers to the Team.

If that story differs from the UML, the translation is not finished.

The Debugger Provides Runtime Evidence

After the statements execute, inspect the objects in Visual Studio.

You should be able to follow:

UML snapshot
    ↓
C# statements
    ↓
runtime objects and values

The diagram describes the intended state. The source contains the instructions. The debugger shows the state that actually exists.

Preserve the Model Exactly

Do not add extra objects, values, or relationships just because the C# class permits them.

For each important statement, ask:

Which object, value, or relationship in the UML does this statement represent?

That traceability is the foundation for moving between design and code.