In this module, you have worked with structured data in tables.
For example, a soccer roster might contain:
| Player ID | Name | Jersey Number | Position |
|---|---|---|---|
| P001 | Jordan | 7 | Forward |
| P002 | Casey | 1 | Goalkeeper |
A spreadsheet emphasizes records and fields.
A UML class diagram can describe the same information from a software-modeling perspective.
Instead of showing every current row, the class diagram describes the kind of object the software can represent.
If one row represents one player, a useful software class is:
Player
The table fields can suggest attributes for that class.
Conceptually:
Player
--------------------------------
playerId : string
name : string
jerseyNumber : int
position : string
The class diagram does not show Jordan and Casey as current rows.
It describes the structure that Player objects can use.
Consider the table headers:
Player ID
Name
Jersey Number
Position
Those fields can correspond to class attributes:
playerId
name
jerseyNumber
position
The two representations use different notation, but they can describe closely related information.
Spreadsheet:
column → field across many records
Class diagram:
attribute → information available on objects of that class
A structured-data table may contain values such as:
P001
Jordan
7
Forward
A UML class diagram can make the expected types explicit:
Player
--------------------------------
playerId : string
name : string
jerseyNumber : int
position : string
The class diagram says more than “this information exists.”
It tells a software designer what kind of value each attribute is expected to contain.
Suppose a soccer workbook separates teams and players.
| Team ID | Team Name |
|---|---|
| T001 | Wildcats |
| Player ID | Name | Team ID |
|---|---|---|
| P001 | Jordan | T001 |
| P002 | Casey | T001 |
The structured data uses the value:
T001
to connect player records to the team record.
A UML class model can represent two related software types:
Player -------- Team
Conceptually:
Player
--------------------------------
playerId : string
name : string
jerseyNumber : int
Team
--------------------------------
teamId : string
name : string
The relationship communicates that Player and Team objects are connected in the software model.
A spreadsheet or ERD may require identifiers because records need stable identities.
A software class diagram may also contain an identifier when the software needs it.
But the diagrams do not have to contain identical attribute lists simply because they describe the same domain.
Ask what each model is for.
If the application needs to retain a playerId, the class attribute is useful.
If the ID exists only for a data-storage purpose that the software model does not need to expose at this level, the model may differ.
The purpose controls the representation.
Consider:
Player
--------------------------------
playerId : string
name : string
jerseyNumber : int
This can be read as:
A Player is a software type whose objects can contain a player ID, name, and jersey number.
Compare that with one spreadsheet row:
P001 | Jordan | 7
The row says:
This particular record currently contains these values.
That is the difference between describing a type and displaying a record.
A table may contain fifty player rows.
The UML class diagram does not need fifty Player boxes.
One:
Player
class can describe the common structure for many Player objects.
That is similar to how one table header defines the field structure for many records.
Suppose you model:
Player -------- Team
The line should correspond to an actual relationship in the system.
Do not connect classes merely because their tables happen to appear in the same workbook.
For the soccer example, a meaningful statement is:
Players belong to teams.
That gives the relationship a purpose.
Both representations can show:
Their emphasis differs.
An ERD is primarily a data-oriented model.
A UML class diagram is primarily a software-oriented model.
The next Learning Activity compares those two views directly.