Identifying Attributes | UML 2 For Dummies

After you become familiar with your classes and learn how to name them, you need to consider their properties. To be an interesting and useful class, instances of the class (objects) should have some interesting and useful properties. UML calls these properties attributes.

Finding these attributes is usually not difficult. You can often identify attributes by considering how you would describe the objects within a class and how you could differentiate among them. For example, the color of an object might be interesting and may differ, so color could be an attribute. The weight of an object might be interesting and may differ, so weight could be an attribute.

Depending on your background, you may feel comfortable thinking about attributes as member variables or data slots. Each data slot has a data value placed inside it. Either way you look at it, attributes are the specific features or values that an object of a class may have.

Tip If you have a background in using or designing databases, you may find it helpful to match UML terms with database terminology. They’re not exactly equivalent, but seeing the parallels in Table 3-3 will give you a head start to understanding. Don’t be enamored too much with this comparison. It works well for the data aspects of a class, but a class is a larger concept than just a table because the class encompasses both data and behavior.

Table 3-3: Parallel UML and Database Terms
UML Term	Parallel Database Term
Class	Table
Object	Record
Attribute	Field or Column

After you identify an attribute, you may want to indicate the attribute’s type. (A type specifies what kind of data that attribute can hold.) When you do supply it with a type, place the type’s name after the attribute’s name as follows:

 attribute:Type

The type of an attribute can be the taken from your programming language’s possibilities—or (since UML allows it) you can develop your own. UML also defines several intrinsic data types:

Integer: This includes all positive and negative whole numbers, as in the following list:
. . . , _2, –1, 0, 1, 2, . . .
Boolean: Boolean values specify a state of logical truth, such as True or False.
String: A string is a sequence of characters and spaces in code (as in the example “A Typical String”).

Ultimately, it’s going to be necessary to specify the type of all the attributes to produce an executable system. However, you can delay typing (specifying the type) until you know it and wish to share it with your model readers. Many UML tools provide a default type for attributes as you add them to the model.

Naming attributes and types

Attributes follow the same naming conventions that object’s names follow (see the section “Naming Objects and Classes” earlier in this chapter), but they don’t usually begin with an article (a, an, the) because they’re only properties. The following are some attributes of a Person class:

name: String uses an Intrinsic UML type.
age: Integer uses an Intrinsic UML type.
weight: Double uses a Language Defined type.

Some attributes of a Lease class could be as follows:

date: Date uses a Language Defined type.
duration: Integer uses an Intrinsic UML type.

Sometimes an object may need to have an attribute borrowed from another class—or refer to an object of another class. You can show this situation by using a class name in the Type field. For example, on a Lease class, you might want to indicate a particular Crash Dummy being leased and the person renting the Crash Dummy. You could set it up as follows, where CrashDummy and Person are classes:

 hiredDummy: CrashDummy renting: Person

You can find much more about referencing objects of other classes in Chapter 4.

When you name types, generally follow the same conventions that you would follow when naming classes. (See the section “Following UML rules for naming classes,” earlier in this chapter.) To distinguish classes from types, end your user-defined type names with the word Type. It is also standard convention to prefix Boolean attributes with the word is. For a Person class, some additional attributes could be as follows:

phoneNumber: PhoneNumberType uses a user-defined type.
streetAddress: AddressType uses a user-defined type.
isSingle: Boolean uses a Boolean attribute.

Enumerating the possibilities

If you find that an attribute has a value that’s taken from a (usually small) fixed list of discrete, possible values, you want to construct what is called an enumeration data type. It’s good modeling practice to clearly identify these types by ending their names with the word Kind, as in the following examples:

GenderKind could have the values Male or Female.
TrafficLightColorKind could have the values Red, Yellow, or Green.
SuccessKind could have the values Succeed or Fail.

You may ultimately want to expand a data type such as GenderKind to include every single esoteric possibility. But as with all typing (and all modeling, for that matter), too much detail may be counterproductive.

Defining default values

When your system is up and running, slots for the attribute values are created every time an object is created, but the contents of the slots are undefined. You probably want to determine default values to initialize your attributes, and may do so when you define them at modeling time, as follows for a member of the Person class:

 attributeName: AttributeType = default value name: String = ‘’ age: Integer = 0 weight: Double = 0.0 gender: GenderKind = male phoneNumber: PhoneNumberType = 000 000-0000 isSingle: Boolean = true

These default values are used only when a new object is created at runtime, and the type of the default value has to be compatible with the type of the attribute.

Technical Stuff UML is constantly improving. Occasionally, the UML gurus change things that probably don’t really need changing. In UML 1.4, the value assigned to an attribute when an object is first created was called the initial value. In UML 2, the gurus changed this to the default value—less precise (but more common) terminology.

Multiplicity

In normal situations, you want your objects to have one attribute value for each attribute you’ve identified. UML allows for more. Perhaps your friend has two telephone numbers, or more than one name. UML enables you to indicate exactly how many values an attribute has (called the multiplicity) and even allows for a range. You place the multiplicity in square brackets after the attribute’s type, as follows:

 attributeName: AttributeType [Multiplicity]

You can express the multiplicity by following the examples in Table 3-4.

Table 3-4: UML Multiplicities or How Many Do We Have
UML Multiplicity	Meaning
1	Exactly 1 (the default)
2	Exactly 2
1..3	From 1 to 3 (inclusive)
3, 5	Either 3 or 5
1..*	At least one, and at most, unlimited
*	Unlimited (includes 0)
0..1	Either 0 or 1

Tip Attributes and analysis

During the early phases of development, it’s often premature to consider low-level features (such as data types, slots, or fields). Instead, concentrate on the knowledge responsibilities that an object might have. Ask yourself, What questions could be directed to the object that the object should be expected to reply to? Questions about the object’s state, status, or condition are all natural knowledge responsibilities; typically all are treated as attributes.

In early development steps (such as analysis), you also need not compress and eliminate spaces in the attribute names. Keeping the names normal-looking helps you spell-check the names—and also helps show that your early-stage attributes are merely conceptual, not meant to be directly implemented.

Similarly, consider using the conceptual approach to units of measurement (such as Degrees Celsius) instead of implementation data types (such as int for integer) in the early stages of developing your model. The reviewers of your models are likely to be users and business analysts. They’re not expected to know what double or int means, but can catch on to standard units. If you’re modeling a thermometer class for a domain expert (for example), and want to convey that you’ve got a handle on the subject, current Temperature: Degrees Celsius makes the point better than currentTemperature: Double. For the Lease class, the analysis step would probably benefit more from duration: Weeks than from duration: Integer.

The default multiplicity for an attribute is 1, so you shouldn’t bother to indicate it explicitly unless the fact that the multiplicity is 1 is surprising. If an attribute value may be omitted, perhaps because its value is not always defined or known when the object is created, allow for zero in the multiplicity. Such attributes are commonly described as having nulls allowed.

Look at the follow attributes on a Person class. A person must have at least one name, but may also have a nickname. The second name is only created when needed, so only initialize the first.

 name: String [1..2] = "Michael"

If a person’s age were optional, you should include zero in the multiplicity. As a person cannot have more than one age, the upper limit on the multiplicity should be one.

 age: Integer [0..1]

On the other hand, if you decide that it might be better to always have an age attribute for every Person, use a multiplicity of one. You should also consider whether you need a default value, as in the following example:

 age: Integer [1] = 0

If you have a high-multiplicity attribute and you want to initialize several of its possible values, you can do it as follows:

 phoneNumber: PhoneNumberType [2] 
            =(000 000-0000, 000 000-0000)

This initializes both possible phoneNumber values to the default value of 000 000-0000.