0.2.5 Relationships Between Objects

Objects Rarely Make Sense in Isolation

A computerized system can contain many objects.

The useful meaning often comes from the way those objects are connected.

Consider these soccer objects:

• player1 : Player
• team1 : Team
• match1 : Match

Knowing that those objects exist is helpful.

But a coach also needs to know things such as:

• Which team does player1 belong to?
• Which match is team1 preparing for?
• Which players belong to that team?

Those are relationships between objects.

A Relationship Connects Specific Objects

Suppose Jordan plays for the Wildcats.

The objects might be:

player1 : Player

and

team1 : Team

A relationship connects those specific objects:

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

The line tells us that the two objects are related in the modeled situation.

The surrounding explanation or diagram context tells us what that relationship means.

In this example:

player1 belongs to team1.

The relationship is about the specific objects, not every possible player and every possible team.

Relationships Add Context

Consider the object:

player1 : Player

• name = Jordan
• isAvailable = true

Available for what?

Without additional context, the value may be incomplete.

Now connect the model to a match and a team:

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

team1 : Team      --------  match1 : Match

The model now gives the information more context.

Jordan is not simply “available” in the abstract.

The modeled objects and their relationships help explain the soccer situation being represented.

A Relationship Is Different From a Field Value

A simple field value describes information about one object.

For example:

player1 : Player

• jerseyNumber = 7
• isAvailable = true

The value 7 is information about player1.

The value true is information about player1.

A relationship connects player1 to another object.

For example:

player1 is related to team1.

This distinction becomes important in object-oriented systems because one object may need access to another object, not merely a text description of it.

At this stage, focus on the model rather than on how programming code creates that connection.

Use Objects Instead of Repeating Their Information

Imagine the team is represented like this:

team1 : Team

• name = Wildcats
• coachName = Rivera

And the player is represented like this:

player1 : Player

• name = Jordan
• teamName = Wildcats
• coachName = Rivera

This repeats information from the team inside the player.

That may be unnecessary if the model can instead represent the player as related to the actual team1 object.

Then information about the team can remain with the team.

Conceptually:

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

The relationship expresses that the player's context includes that team.

This often produces a clearer model because each object can hold the information that belongs to it.

One Object Can Relate to Several Others

Suppose the Wildcats have three modeled players:

• player1
• player2
• player3

All three may relate to the same team object:

player1 : Player  ----                       player2 : Player  ------ team1 : Team
                       /
player3 : Player  ----/

The exact layout of a UML diagram may look different, but the meaning is straightforward:

Several distinct player objects are connected to one team object.

The team is not duplicated just because several players belong to it.

One Object Can Participate in Different Relationships

The same team can also relate to a match.

For example:

player1 : Player  --------  team1 : Team  --------  match1 : Match

Now team1 participates in more than one relationship.

It is related to a player.

It is also related to a match.

Real computerized systems often form networks of connected objects rather than isolated boxes.

Relationships Should Support the Model's Purpose

Not every possible real-world connection belongs in the model.

A player could be related to:

• a team;
• a coach;
• a parent;
• a school;
• a favorite professional club;
• a shoe manufacturer;
• a social-media account.

For the current lineup purpose, only some of those relationships matter.

Abstraction still controls the model.

The question remains:

Does this relationship help the model represent what the system needs to know?

If not, it may not belong in the current model.

Relationships and UML Object Diagrams

In a UML object diagram, lines can connect specific objects to show relationships present in the current snapshot.

A small conceptual soccer model might contain:

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

          |
          |
          |

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

          |
          |
          |

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

The objects show what exists in the snapshot.

The values show selected information about those objects.

The connecting lines show which objects are related.

Later activities will show you how these ideas appear in formal UML object diagrams and how to create them with Violet.

A Relationship Is About the Actual Objects

Suppose two objects represent two different teams:

• team1 : Team
• team2 : Team

Even if both temporarily have the same displayed name, they remain different objects.

A relationship to team1 does not automatically mean a relationship to team2.

Relationships connect particular object identities.

That is why object identity matters.

The model must make clear which object is connected to which other object.

The Model Is Becoming a System

Earlier, a model might have looked like a collection of facts.

Now the pieces begin to work together:

Objects represent specific things.

Fields represent selected information about those things.

Values show the current state of those fields.

Relationships connect objects that matter to one another.

Together, those ideas allow a model to describe a meaningful snapshot of a computerized system.

That is the foundation you will use when you begin reading complete UML object diagrams.