1.1.2 How to Infer an Object Diagram Design From Descriptive Text

Descriptive Text Can Contain the Information Needed for a Model

A requirement or scenario may describe a system in ordinary language.

Your job is to identify the parts that belong in a UML object diagram.

An object diagram focuses on a specific snapshot.

It can show:

The challenge is deciding which words in the description provide each kind of information.

Begin by Finding Specific Things

Consider this soccer description:

Jordan is a player wearing jersey number 7. Jordan plays for the Wildcats. Casey is another player on the Wildcats and wears jersey number 1.

The description contains several specific things:

Those are candidates for object instances.

You are not yet drawing the diagram.

First identify what the text says exists.

Determine the Type of Each Thing

Jordan and Casey are both players.

The Wildcats are a team.

A possible object plan is:

Plain text
player1 : Player
player2 : Player
team1 : Team

The text supplied the real-world meaning.

The object identities are labels used to distinguish the instances in the model.

If the course or assessment supplies required identities, use those exact identities.

Do not rename a required object simply because another name feels more natural.

Extract Values That Belong to the Objects

The description says:

Jordan wears jersey number 7.

That can support a value such as:

Plain text
jerseyNumber = 7

for the Jordan Player object.

It also says:

Casey ... wears jersey number 1.

That value belongs to the Casey Player object.

A conceptual object plan becomes:

Plain text
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7
Plain text
player2 : Player
-------------------------
name = "Casey"
jerseyNumber = 1

The diagram should contain the information supported by the description and needed for the modeling purpose.

Keep Values With the Object They Describe

Suppose the description says:

The Wildcats play at North Field.

The field or relationship representing North Field should not be placed inside Jordan merely because Jordan is on the team.

Ask:

Which object does this information actually describe?

That question prevents values from drifting into the wrong object.

Look for Relationship Language

Words and phrases can signal relationships.

Examples include:

In the soccer description:

Jordan plays for the Wildcats.

That tells you player1 and team1 are related.

Likewise, Casey is related to the same team1.

Conceptually:

Plain text
player1 : Player  --------\
                            \
                             team1 : Team
                            /
player2 : Player  --------/

The exact Violet layout can differ.

The relationship meaning should remain clear.

Distinguish Types From Instances

The word:

Plain text
Player

describes a type.

Jordan describes a specific player in the scenario.

An object diagram needs the instance.

Do not create one box named only:

Plain text
Player

when the task is asking for the current objects in a described situation.

A useful question is:

Which particular Player exists in this snapshot?

Do Not Add Details That the Text Does Not Support

Suppose the description says nothing about:

Do not add values for those fields simply because a real soccer player could have them.

Model the supplied situation.

A diagram becomes unreliable when invented detail is mixed with stated detail.

Do Not Turn Every Noun Into an Object

Consider:

Jordan wears jersey number 7.

The word number is a noun.

That does not mean the diagram needs a Number object.

Likewise, a sentence may mention:

Those can be field values rather than separate object instances.

Ask whether the thing needs its own identity, state, or relationship in the current model.

Build the Diagram in Layers

A useful modeling sequence is:

1. Identify object instances

What specific things exist?

2. Determine their types

What kind of object is each one?

3. Extract supported field values

What does the text say about each object?

4. Identify relationships

How are the specific objects connected?

5. Read the result back as prose

Does the diagram tell the same story as the description?

This sequence keeps you from drawing lines before you know what the objects mean.

Translate Back to Plain Language

Suppose your planned model contains:

Plain text
player1 : Player
name = "Jordan"
jerseyNumber = 7

connected to:

Plain text
team1 : Team
name = "Wildcats"

Read it as:

player1 is a Player named Jordan, Jordan's jersey number is 7, and that Player object is related to the Wildcats Team object.

Then compare that sentence with the source description.

If the model says more than the text supports, revise it.

If it misses a required relationship or value, revise it.

Descriptive Text Is Evidence for the Model

The goal is not to create the most detailed possible diagram.

The goal is to create a model that can be traced back to the description.

For every important object, value, and relationship, you should be able to answer:

What part of the descriptive text supports this?