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.
Consider this soccer description:
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.
Jordan and Casey are both players.
The Wildcats are a team.
A possible object plan is:
player1 : Player
player2 : Player
team1 : TeamThe 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.
The description says:
That can support a value such as:
jerseyNumber = 7for the Jordan Player object.
It also says:
That value belongs to the Casey Player object.
A conceptual object plan becomes:
player1 : Player
-------------------------
name = "Jordan"
jerseyNumber = 7player2 : Player
-------------------------
name = "Casey"
jerseyNumber = 1The diagram should contain the information supported by the description and needed for the modeling purpose.
Suppose the description says:
The field or relationship representing North Field should not be placed inside Jordan merely because Jordan is on the team.
Ask:
That question prevents values from drifting into the wrong object.
Words and phrases can signal relationships.
Examples include:
In the soccer description:
That tells you player1 and team1 are related.
Likewise, Casey is related to the same team1.
Conceptually:
player1 : Player --------\
\
team1 : Team
/
player2 : Player --------/The exact Violet layout can differ.
The relationship meaning should remain clear.
The word:
Playerdescribes a type.
Jordan describes a specific player in the scenario.
An object diagram needs the instance.
Do not create one box named only:
Playerwhen the task is asking for the current objects in a described situation.
A useful question is:
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.
Consider:
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.
A useful modeling sequence is:
What specific things exist?
What kind of object is each one?
What does the text say about each object?
How are the specific objects connected?
Does the diagram tell the same story as the description?
This sequence keeps you from drawing lines before you know what the objects mean.
Suppose your planned model contains:
player1 : Player
name = "Jordan"
jerseyNumber = 7connected to:
team1 : Team
name = "Wildcats"Read it as:
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.
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: