Working with Object-Orientation in UML
What You'll Learn in This Hour:
- How to model a class
- How to show a class's features, responsibilities, and constraints
- How to discover classes
Now it's time to put the UML together with the object-oriented concepts
you learned in the last hour. In this hour, you'll firm up your knowledge
of object-orientation as you learn more about the UML.
Visualizing a Class
As I pointed out in the first hour, a rectangle is the icon that represents
a class in the UML. From Hours 1, "Introducing the UML," and 2, "Understanding
Object-Orientation," recall that the name of the class is, by convention,
a word with an initial uppercase letter. It appears near the top of the rectangle.
If your class has a two-word name, join the two words together and capitalize
the first letter of the second word (as in WashingMachine in Figure
3.1).
Another UML construct, the package, can play a role in the name of a class.
As I pointed out in Hour 1, a package is the UML's way of organizing a
diagram's elements. As you might recall, the UML represents a package as
a tabbed folder. The package's name is a text string (see Figure
3.2).
)
Figure
3.1 The UML class icon.
)
Figure
3.2 A UML package.
If the WashingMachine class is part of a package called Household,
you can give it the name Household::WashingMachine. The double colons
separate the package name on the left from the classname on the right. This
type of classname is called a pathname (see Figure
3.3).
)
Figure
3.3 A class with a pathname.
Attributes
An attribute is a property of a class. It describes a range of values that
the property may hold in objects (that is, in instances) of that class.
A class may have zero or more attributes. By convention, a one-word attribute
name is written in lowercase letters. If the name consists of more than one
word, the words are joined and each word other than the first word begins with
an uppercase letter. The list of attribute names begins below a line separating
them from the classname, as Figure 3.4
shows.
)
Figure
3.4 A class and its attributes.
Every object of the class has a specific value for every attribute. Figure
3.5 presents an example. Note that an object's name begins with a lowercase
letter, precedes a colon that precedes the classname, and the whole name is
underlined.
Naming Objects . . . or Not
The name myWasher:WashingMachine is a
named instance. It's also possible to have an anonymous instance like
:WashingMachine.
)
Figure
3.5 An object has a specific value for every one of its class's attributes.
The UML gives you the option of indicating additional information for attributes.
In the icon for the class, you can specify a type for each attribute's
value. Possible types include string, floating-point number, integer, and
Boolean (and other enumerated types). To indicate a type, use a colon to separate
the attribute name from the type. You can also indicate a default value for
an attribute. Figure 3.6 shows these
ways of specifying attributes.
)
Figure
3.6 An attribute can show its type as well as a default value.
Naming Values
An enumerated type is a data type defined by a list of named values. Boolean,
for instance, is an enumerated type because it consists of the values
"true" and "false." You can define your own enumerated types
like State, which consists of the values "solid," "liquid,"
and "gas."
Operations
An operation is something a class can do, and hence it is something that you
(or another class) can ask the class to do. Like an attribute name, an operation's
name is all in lowercase if it's one word. If the name consists of more
than one word, join the words and begin all words after the first with an uppercase
letter. The list of operations begins below a line that separates the operations
from the attributes, as in Figure 3.7.
)
Figure
3.7 The list of a class's operations appears below a line that separates
them from the class's attributes.
Just as you can indicate additional information for attributes, you can
indicate additional information for operations. In the parentheses that follow
an operation name, you can show the parameter that the operation works on, along
with that parameter's type. One kind of operation, the function, returns a
value after it finishes doing its work. For a function, you can show the value
it returns and that value's type.
These pieces of information about an operation are called the operation's
signature. Figure 3.8 shows a couple
of ways to represent the signature. The first two operations show the type of
the parameter. The third and fourth show the type of the return value.
)
Figure
3.8 Signatures for operations.
Attributes, Operations, and Visualization
We've been dealing with classes in isolation thus far and showing all
the attributes and operations of a class. In practice, however, you'll
show more than one class at a time. When you do that, it's typically not
useful to always display all the attributes and operations. To do so might make
the diagram way too busy. Instead, you can just show the classname and leave
either the attribute area or the operation area empty (or leave them both empty),
as Figure 3.9 shows.
)
Figure
3.9 In practice, you don't always show all of a class's attributes
and operations.
Sometimes it might be helpful to show some (but not all) of the attributes
or operations. To indicate that you've only shown some of them, you follow
the list of the ones you've shown with three dots ". . . ". This
is called an ellipsis, and omitting some or all of the attributes or operations
is called eliding a class. Figure 3.10
shows the use of an ellipsis.
)
Figure
3.10 An ellipsis indicates that the displayed attributes or operations aren't
the whole set.
If you have a long list of attributes or operations, you can use a keyword
to organize in ways that will make the list comprehensible. As I mentioned in
Hour 1, a keyword is enclosed inside two pairs of small angle brackets called
guillemets. For an attribute list, you can use a keyword as a heading
for a subset of the attributes, as in Figure
3.11.
)
Figure
3.11 You can use a keyword to organize a list of attributes or operations.
Responsibilities and Constraints
The class icon enables you to specify still another type of information about
a class. In an area below the operations list, you can show the class's
responsibility. The responsibility is a description of what the class has to
do—that is, what its attributes and operations are trying to accomplish. A
washing machine, for example, has the responsibility of taking dirty clothes as
input and producing clean clothes as output.
In the icon, you indicate responsibilities in an area below the area that contains
the operations (see Figure 3.12).
)
Figure
3.12 In a class icon, you can write the class's responsibilities in
an area below the operations list area.
The idea here is to include enough information to describe a class in an
unambiguous way. Indicating the class's responsibilities is an informal way
to eliminate ambiguity.
A slightly more formal way is to add a constraint, a free-form text enclosed
in curly brackets. The bracketed text specifies one or more rules the class
follows. For example, suppose in the WashingMachine class you wanted
to specify that the capacity of a washer can be only 16, 18, or 20 pounds (and
thus "constrain" the WashingMachine class's capacity
attribute). You would write {capacity = 16 or 18 or 20 lbs} near the
WashingMachine class icon. Figure
3.13 shows how to do it.
)
Figure
3.13 The rule in curly brackets constrains the capacity attribute to be
one of three possible values.
More on Constraints
The UML works with still another—and much more formal—way of adding
constraints that make definitions more explicit. It's an entire language
called Object Constraint Language (OCL). An advanced and sometimes useful tool,
OCL has its own set of rules, terms, and operators. The Web site of the Object
Management Group
(http://www.omg.org) provides
documentation on OCL.
Attached Notes
Above and beyond attributes, operations, responsibilities, and constraints,
you can add still more information to a class in the form of notes attached to
the class.
You'll usually add a note to an attribute or operation. Figure
3.14 shows a note referring to a government standard that tells where to
find out how serial numbers are generated for objects in the WashingMachine
class.
){kind=small}
Figure
3.14 An attached note provides further information about the class.
Bear in mind that a note can contain a graphic as well as text.
Classes—What They Do and How to Find Them
Classes are the vocabulary and terminology of an area of knowledge. As you
talk with clients, analyze their area of knowledge, and design computer systems
that solve problems in that area, you learn the terminology and model the terms
as classes in the UML.
In your conversations with clients, be alert to the nouns they use to
describe the entities in their business. Those nouns will become the classes in
your model. Be alert also to the verbs that you hear because these will
constitute the operations in those classes. The attributes will emerge as nouns
related to the class nouns. After you have a core list of classes, question the
clients as to what each class is supposed to do within the business. Their
answers will tell you the class responsibilities.
Suppose you're an analyst building a model of the game of basketball,
and you're interviewing a coach in order to understand the game. The
conversation might go something like this:
Analyst: "Coach, what's basketball all about?"
Coach: "The goal of the game is to shoot the ball through the
basket and score more points than your opponent. Each team consists of five
players: two guards, two forwards, and a center. Each team advances the ball
toward the basket with the objective of ultimately shooting the ball through the
basket."
Analyst: "How does it advance the ball?"
Coach: "By dribbling and passing. But the team has to take a shot
at the basket before the shot clock expires."
Analyst: "Shot clock?"
Coach: "Yes. That's 24 seconds in the pros, 30 seconds in
international play, and 35 seconds in college to take a shot after a team gets
possession of the ball."
Analyst: "How does the scoring work?"
Coach: "Each basket counts two points, unless the shot is from
behind the three-point line. In that case, it's three points. A free throw
counts one point. A free throw, by the way, is the penalty a team pays for
committing a foul. If a player fouls an opponent, play stops and the opponent
gets to shoot at the basket from the free-throw line."
Analyst: "Tell me a little more about what each player
does."
Coach: "The guards generally do most of the dribbling and
passing. They're typically shorter than the forwards, and the forwards are
usually shorter than the center. All the players are supposed to be able to
dribble, pass, shoot, and rebound. The forwards do most of the rebounding and
intermediate-range shooting, while the center stays near the basket and shoots
from close range."
Analyst: "How about the dimensions of the court? And by the way,
how long does a game last?"
Coach: "In international play, the court is 28 meters long by 15
meters wide. The basket is 10 feet off the ground. In the pros, a game lasts 48
minutes, divided into four 12-minute quarters. In college and international
play, it's 40 minutes divided into two 20-minute halves. A game clock keeps
track of the time remaining."
This could go on and on, but let's stop and take stock of where we are.
Here are the nouns you've uncovered: ball, basket, team, players, guards,
forwards, center, shot, shot clock, three-point line, free throw, foul,
free-throw line, court, and game clock.
Here are the verbs: shoot, advance, dribble, pass, foul, and rebound. You
also have some additional information about some of the nouns—like the
relative heights of the players at each position, the dimensions of the court,
the total amount of time on a shot clock, and the duration of a game.
Finally, your own commonsense knowledge could come into play as you generate
a few attributes on your own. You know, for example, that the ball has
attributes like volume and diameter.
Using this information, you can create a diagram like the one in Figure
3.15. It shows the classes, and provides some attributes, operations, and
constraints. The diagram also shows responsibilities. You could use this diagram
as a foundation for further conversations with the coach, to uncover more information.
)
Figure
3.15 An initial class diagram for modeling the game of basketball.
Summary
The rectangle is the UML icon for representing a class. The name, attributes,
operations, and responsibilities of the class fit into areas within the
rectangle. You can use a stereotype to organize lists of attributes and
operations. You elide a class by showing just a subset of its attributes and
operations. This makes a class diagram less busy.
You can show an attribute's type and an initial value, and you can show
the values an operation works on and their types as well. For an operation, this
additional information is called the signature.
To reduce the ambiguity in a class description, you can add constraints. The
UML also allows you to say more about a class by attaching notes to the
rectangle that represents it.
Classes represent the vocabulary of an area of knowledge. Conversations with
a client or an expert in that area reveal nouns that can become classes in a
model and verbs that can become operations. You can use a class diagram as a way
of stimulating the client to talk more about his or her area and reveal
additional knowledge.
Q&A
You mention using "commonsense" knowledge to round out
the class diagram for basketball. That's all well and good, but what
happens when I have to analyze an area that's new to me—where
common sense won't necessarily help?
Typically, you'll be thrust into an area that's new for you.
Before you meet with a client or with an expert in the field, try to become
a "subexpert." Prepare for the meeting by reading as much related
documentation as possible. Ask your interviewee for some papers or manuals
they might have written. When you've finished reading, you'll
know some of the fundamentals and you'll be able to ask pointed questions.
At what point will I want to show an operation's signature?
Probably after the analysis phase of a development effort, as you get
into design. The signature is a piece of information that programmers will
find helpful.
I've been working for my company for a long time and have in-depth
knowledge of its business. Do I still have to create a class model of the
business area the company works in?
It's a good idea to do that. When you have to model your knowledge,
you may be surprised at what you don't know.
Workshop
To review what you've learned about object-orientation, try your hand at
these quiz questions. The answers appear in Appendix A, "Quiz
Answers."
Quiz
How do you represent a class in the UML?
What information can you show on a class icon?
What is a constraint?
Why would you attach a note to a class icon?
Exercises
-
Here's a brief (and incomplete) description of hockey:
-
If you know more about basketball than I've put in Figure
3.15, add information to that diagram.
-
Go back to the conversation between the analyst and the basketball coach.
Take a look at the coach's responses and find at least three areas
where you could pursue additional lines of questioning. For example, at
one point the coach mentions a "three-point line." Further questioning
would reveal the specifics of that term.
-
Here's a preview of what's next: If you had to draw some connections
among the classes in Figure 3.15, what
might they look like?
A hockey team consists of a center, a goalie, two wings, and two defensemen.
Each player has a stick, which he uses to advance a puck on the ice. The objective
is to use the stick to shoot the puck into a goal. Hockey is played on a rink
with maximum dimensions of 100 feet wide by 200 feet long. The center's
job is to pass the puck to the wings, who are typically the better shooters
on the team. The defensemen try to stop the opposing players from getting
into position to shoot the puck into the goal. The goalie is the last line
of defense, blocking opposition shots. Each time he stops the puck from getting
into the goal, he's credited with a "save." Each goal is worth
one point. A game lasts 60 minutes, divided into three periods of 20 minutes
each.
Use this information to come up with a diagram like the one in Figure
3.15. If you know more about hockey than I've put in the description,
add that information to your diagram.
