0.6.18 Modeling Data in a Class Diagram

In this module, you have worked with structured data in tables.

For example, a soccer roster might contain:

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

Suppose a soccer workbook separates teams and players.

T001

Player -------- Team

Player
--------------------------------
playerId : string
name : string
jerseyNumber : int

Team
--------------------------------
teamId : string
name : string

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:

Compare that with one spreadsheet row:

P001 | Jordan | 7

The row says:

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:

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.