0.4.10 Attributes and Data Types in UML Class Diagrams

Attributes Describe the Information a Class Can Hold

In a UML class diagram, an attribute represents information associated with objects of that class.

For a soccer Player class, useful attributes might include:

name
jerseyNumber
heightMeters
isAvailable

A class diagram becomes more precise when it also identifies the type of each attribute.

Attribute Notation Connects Name and Type

A common UML attribute form is:

attributeName : Type

Conceptually:

Player
--------------------------------
name : string
jerseyNumber : int
heightMeters : double
isAvailable : bool

Read each line from left to right.

name : string

means:

Player has an attribute named name whose value is text.

jerseyNumber : int

means:

Player has an attribute named jerseyNumber whose value is a whole number.

The exact type names shown here connect directly to the basic C# types you will encounter next.

Attribute Name and Type Serve Different Purposes

Consider:

isAvailable : bool

isAvailable tells you what the information means.

bool tells you what kind of value can represent that information.

The attribute name provides semantic meaning.

The type provides structural information.

Both matter.

Use Types That Match the Modeled Information

A simple Player class might be:

Player
--------------------------------
name : string
jerseyNumber : int
heightMeters : double
isAvailable : bool

The choices reflect the information:

• string for text;
• int for a whole number;
• double for a number that can include a fractional part;
• bool for true/false state.

The type should make sense for the attribute's purpose.

Class Attributes Do Not Contain One Player's Current Values

A class diagram says:

jerseyNumber : int

It does not say:

jerseyNumber = 7

The first describes the structure available to Player objects.

The second is a current value that belongs in an object snapshot.

This is a useful distinction.

Class diagram

Player
-------------------------
jerseyNumber : int

Object diagram

player1 : Player
-------------------------
jerseyNumber = 7

The class says what kind of information exists.

The object shows the value for one particular instance.

Different Classes Own Different Attributes

A Match class might contain:

Match
--------------------------------
opponent : string
location : string
hasStarted : bool

A Team class might contain:

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

Attributes should belong to the class whose objects they actually describe.

A player's jersey number should not be placed in Match simply because the match uses players.

Good modeling keeps information with the concept it describes.

Relationships Avoid Repeating Whole Objects as Text

Suppose Player and Team are related.

You could model:

Player -------- Team

instead of putting all Team information inside Player as copied text.

The class relationship communicates that Player objects can be connected to Team objects.

The exact implementation comes later.

For now, the model should show structure clearly.

A Small Soccer Class Model

A simple conceptual model could contain:

Player
--------------------------------
name : string
jerseyNumber : int
isAvailable : bool

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

Match
--------------------------------
opponent : string
location : string
hasStarted : bool

with relationships connecting Player to Team and Team to Match.

The model communicates:

• the kinds of objects;
• the information each kind can contain;
• the type of each attribute;
• and the important structural relationships.

Type Information Prepares the Model for Code

A class-diagram attribute such as:

isAvailable : bool

connects naturally to a C# field or variable whose type is bool.

Likewise:

jerseyNumber : int

connects to a C# whole-number value.

This does not mean UML and C# are the same language.

It means the model and the program can agree about the kind of information being represented.

That agreement helps keep requirements, diagrams, and code aligned.