0.2.11 Object Instances in UML Object Diagrams

A Type Is General; an Object Instance Is Specific

Consider the word:

Player

That describes a kind of thing in a soccer system.

It does not identify one particular player.

Now consider:

player1 : Player

That describes one specific object instance.

The part before the colon identifies the object.

The part after the colon identifies its type.

Read it as:

This identity-and-type pattern is central to UML object diagrams.

Several Objects Can Share One Type

A soccer team can contain many players.

A diagram might include:

player1 : Player
player2 : Player
player3 : Player

Each object has the same type, Player.

The objects remain separate because their identities are different.

Their values might also differ:

player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
player2 : Player
-------------------------
name = "Casey"
jerseyNumber = 1

The model represents two specific Player objects, not one Player definition.

Identity Is Not the Same as a Person's Display Name

The object identity and a field value can look similar, but they have different jobs.

For example:

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

player1 is the object's identity in the model.

"Jordan" is a value stored in the name field.

A different model might use another internal object identity while still storing "Jordan" as the player's name.

The object identity helps the model distinguish one instance from another.

The field value describes information about that instance.

Two Objects Can Have Matching Values

Suppose the diagram contains:

player3 : Player
-------------------------
name = "Alex"
jerseyNumber = 10
player4 : Player
-------------------------
name = "Alex"
jerseyNumber = 10

The values happen to match.

The object identities do not.

The diagram therefore represents two distinct objects.

This is an important modeling idea:

Matching values do not automatically mean matching identity.

A computerized system often needs to distinguish specific objects even when their visible information is temporarily identical.

The Type Tells You What Information Makes Sense

If an object is:

player1 : Player

you would expect the displayed fields to describe a player.

If another object is:

match1 : Match

you would expect fields that describe a match.

For example:

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

It would be unusual for a Match object to contain a jerseyNumber field because that information describes a player rather than a match.

The object type helps you interpret the values inside the box.

One Real Situation Can Contain Many Types

A single soccer snapshot might include:

player1 : Player
team1 : Team
match1 : Match

These are three object instances of three different types.

Together they can represent a richer situation than any one object can represent alone.

For example:

  • player1 can represent Jordan;
  • team1 can represent the Wildcats;
  • match1 can represent Saturday's match.

Relationships can then connect those specific objects.

UML Object Diagrams Show Instances, Not Just Categories

This is one of the most important distinctions to keep clear.

A class-oriented idea asks:

An object diagram asks:

For this part of the course, keep your attention on the second question.

You are reading and creating diagrams of specific instances.

Read the Header First

Whenever you encounter a UML object box, begin with its header.

For:

player2 : Player

ask:

  • Which object? player2
  • What type? Player

Only then move on to its field values and relationships.

That simple habit prevents a common beginner mistake: confusing one object instance with the general type it belongs to.