0.2.12 Fields in UML Object Diagrams

Fields Describe the Current State of an Object

An object instance tells you which specific thing is being represented.

Fields tell you selected information about that object.

For example:

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

The object is player1.

Its type is Player.

The fields shown are:

name
jerseyNumber
position
isAvailable

The values shown are:

"Jordan"
7
"Forward"
true

Together, those values describe part of the object's current state.

Read Each Row as “Field Has Value”

A useful reading habit is to turn each row into a sentence.

name = "Jordan"

becomes:

jerseyNumber = 7

becomes:

isAvailable = true

becomes:

Reading the diagram this way keeps the field name and its current value separate.

Field Names Describe the Information

A field name should help explain what the value means.

Consider:

7

By itself, the number is ambiguous.

It could represent:

a jersey number;
goals scored;
years of experience;
or something else.

The field name provides the context:

jerseyNumber = 7

Now the meaning is much clearer.

Values Can Have Different Kinds of Information

A UML object diagram may show several kinds of simple values.

Text

name = "Jordan"
position = "Forward"

Quotation marks help show that the values are text.

Numbers

jerseyNumber = 7
goals = 2

True/false state

isAvailable = true

The field's name should make the meaning of the Boolean value understandable.

isAvailable = true

is clearer than a vague field such as:

status = true

Values Belong to a Specific Object

Suppose two players have different availability.

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

player2 : Player
-------------------------
name = "Casey"
isAvailable = false

The field name isAvailable appears in both objects.

The values are independent because the objects are different.

Do not read the field as one shared value for every Player.

Each object instance has its own current state.

A Value Can Change Without Changing the Object's Identity

Suppose Jordan becomes unavailable.

Earlier snapshot:

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

Later snapshot:

player1 : Player
-------------------------
name = "Jordan"
isAvailable = false

The object is still player1 : Player.

The state changed.

Object diagrams can therefore help you reason about how the same object looks at different moments.

Only Show Fields That Matter to the Model

A soccer player has many characteristics in the real world.

A lineup model may need:

name;
position;
availability.

It probably does not need:

favorite snack;
shoe brand;
preferred music.

UML does not require you to fill the object box with every fact you know.

Abstraction still applies.

The diagram should display the fields needed to communicate the current purpose clearly.

Keep Values With the Object They Describe

Suppose the diagram has both a player and a match.

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

match1 : Match
-------------------------
opponent = "Rangers"
location = "North Field"

The player's jersey number belongs with the player object.

The match location belongs with the match object.

A clear model puts information with the object it actually describes.

This becomes especially important as diagrams grow.

Fields Tell Only Part of the Story

Fields describe an object's own state.

They do not always explain how one object is connected to another.

For example, the player object may show:

name = "Jordan"

and the team object may show:

name = "Wildcats"

A relationship line can communicate that the specific player belongs to the specific team.

That relationship is different from simply repeating the team name as text inside every player.

The next part of object-diagram reading is understanding those object references and relationships.