So far, you have considered a soccer system in terms of players, teams, and matches.
Now the model needs to become more specific.
A computerized system may need to distinguish:
A specific thing represented inside a computerized system can be thought of as an object.
For example:
Each is one distinct thing the system may need to represent.
Consider the word player.
That describes a general kind of thing.
Now consider:
Jordan, jersey number 7, a forward for the Wildcats.
That describes one specific player.
In a model, that specific player could be represented as an object named something like:
player1
A different player might be:
player2
The names player1 and player2 are identifiers used inside the model. They help distinguish one object from another.
The important idea is that each object represents one particular instance.
The system also needs information about the object.
For player1, useful information might include:
| Field | Value |
|---|---|
| name | Jordan |
| jerseyNumber | 7 |
| position | Forward |
| isAvailable | true |
Each named piece of information is a field.
A field represents one piece of state that the model keeps about an object.
The object is the whole represented thing.
The fields are pieces of information that describe its current state.
It is easy to mix up an object and one of its fields.
Consider:
Object: player1
Field: name
Value: "Jordan"
player1 represents the specific player object.
name identifies one piece of information stored about that player.
"Jordan" is the current value of that field.
The same pattern could apply to another player:
Object: player2
Field: name
Value: "Casey"
Both objects can have a field called name.
The value is different because the objects represent different players.
A real player has far more characteristics than a software model usually needs.
The model might represent:
It might leave out:
That is abstraction again.
Fields are not a list of everything that is true about an object.
They are the selected information the model needs for its purpose.
Field values can change.
Suppose player1 begins with:
| Field | Value |
|---|---|
| name | Jordan |
| jerseyNumber | 7 |
| position | Forward |
| isAvailable | true |
If Jordan becomes unavailable for the match, the object is still player1.
The isAvailable field changes:
| Field | Value |
|---|---|
| name | Jordan |
| jerseyNumber | 7 |
| position | Forward |
| isAvailable | false |
The object did not become a different player simply because one value changed.
Its state changed.
This distinction becomes increasingly important when you work with computerized objects later.
A match object would need different fields than a player object.
For example:
Object: match1
| Field | Value |
|---|---|
| date | Saturday |
| opponent | Rangers |
| location | North Field |
A team object might be:
Object: team1
| Field | Value |
|---|---|
| name | Wildcats |
| ageGroup | U20 |
The fields depend on what kind of thing the object represents and what information the system needs.
There is no reason for match1 to have a jerseyNumber field.
There is no reason for player1 to have an opponent field.
The model becomes clearer when information belongs to the object it actually describes.
Names such as player1, team1, and match1 are especially useful in diagrams and technical discussions.
They let us say:
player1belongs toteam1.
or:
team1is participating inmatch1.
That is more precise than repeatedly saying “the player,” “the team,” and “the match” when several of each may exist.
These identifiers do not have to be the names a learner or customer sees on a screen.
They are names used to distinguish objects inside the model.
A simple lineup model might contain:
player1player2team1match1The model now contains several specific objects, each with selected fields and values.
The next step is learning how a more formal model communicates an object's identity, its type, and its current values.
When reading or creating a model, keep three levels clear:
Object
One specific represented thing.
Field
One named piece of information belonging to that object.
Value
The current information stored in that field.
For example:
player1→jerseyNumber→7
The object is player1.
The field is jerseyNumber.
The value is 7.
Keeping those ideas separate makes later UML diagrams much easier to read.