0.2.24 From a UML Object to a C# Object

UML and C# Can Describe the Same Object in Different Ways

You have already read UML object diagrams that show:

  • object identity;
  • object type;
  • field values;
  • and relationships.

C# can represent the same underlying idea as a running object.

That means a UML object and a C# object are not competing definitions.

They are two representations that can describe the same system concept.

Consider this soccer object:

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

The UML snapshot says:

  • the object identity is player1 ;
  • its type is Player ;
  • its name is "Jordan" ;
  • its jersey number is 7 ;
  • it is currently available.

A corresponding introductory C# setup might look like:

Player player1 = new Player();

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

The notation is different.

The meaning is closely connected.

Read the UML Header First

Start with:

player1 : Player

The UML uses:

identity : type

C# places the type and variable/reference name in another order:

Player player1

Read this introductory declaration as:

The UML and C# syntax are not identical, but both give you clues about identity and type.

new Creates the Object

This C# statement:

Player player1 = new Player();

contains an important new idea.

The expression:

new Player()

creates a new Player object.

The name:

player1

provides the program with a way to refer to that object.

At this point, keep the idea simple:

new creates an object instance of the specified type.

The next Learning Activity looks more closely at that operation.

Field Assignments Match the UML Values

Now compare the UML field:

name = "Jordan"

with the C# assignment:

player1.name = "Jordan";

The C# statement says:

The same connection appears with:

player1.jerseyNumber = 7;
player1.isAvailable = true;

The UML shows a snapshot of the values.

The C# statements create or change the running object's state.

The Dot Connects the Object to a Member

In:

player1.name

the dot separates:

  • the object reference, player1 ;
  • from the member being accessed, name .

You will study member access more deeply later.

For now, read the expression as:

The same pattern appears in:

player1.jerseyNumber
player1.isAvailable
Order Matters When Building the Runtime State

The UML diagram shows the completed snapshot all at once.

C# reaches that state by executing instructions in order.

First:

Player player1 = new Player();

creates the object.

Then:

player1.name = "Jordan";

assigns the name.

Then:

player1.jerseyNumber = 7;

assigns the jersey number.

Then:

player1.isAvailable = true;

assigns availability.

The debugger lets you pause between those moments and observe the object as its state develops.

One UML Object Should Map to One Intended C# Object

Suppose the UML snapshot contains:

player1 : Player

You do not need to create a new Player every time you assign another field.

This would create multiple objects:

Player player1 = new Player();
player1.name = "Jordan";

player1 = new Player();
player1.jerseyNumber = 7;

The second new Player() creates another object and changes what player1 refers to.

That does not represent one object gradually receiving the UML values.

For one UML instance, create the intended object once and assign its current values to that same object.

Relationships Will Eventually Become C# References

A UML object diagram can also connect objects.

For example:

player1 : Player  --------  team1 : Team

In C#, object relationships are represented through references between objects.

You do not need to build complex object graphs yet.

At this point, simply recognize the connection:

UML relationship → C# object reference

Later programming work will make those relationships more explicit.

Three Views of the Same Idea

A single soccer object can now be viewed three ways.

UML
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
C# source
Player player1 = new Player();
player1.name = "Jordan";
player1.jerseyNumber = 7;
Debugger

While the program is paused, Visual Studio can show the actual runtime Player object and its current field values.

Those views serve different purposes:

  • UML communicates the modeled snapshot visually.
  • C# contains executable instructions that create and modify the object.
  • Debugger state shows the object that exists while the program is running.

Learning to connect those representations is more important than memorizing any one syntax form by itself.