12.3. Valid Attribute Types

There are some things that should not be represented as attributes, but rather as associations. This section explores valid attributes.

Keep Attributes Simple

Intuitively, most simple attribute types are what are often thought of as primitive data types, such as numbers. The type of an attribute should not normally be a complex domain concept, such as a Sale or Airport. For example, the following currentRegister attribute in the Cashier class in Figure 12.2 is undesirable because its type is meant to be a Register, which is not a simple attribute type (such as Number or String). The most useful way to express that a Cashier uses a Register is with an association, not with an attribute..

The attributes in a domain model should preferably be simple attributes or data types. Very common attribute data types include: Boolean, Date, Number, String (Text), Time Other common types include: Address, Color, Geometrics (Point, Rectangle), Phone Number, Social Security Number, Universal Product Code (UPC), SKU, ZIP or postal codes, enumerated types

To repeat an earlier example, a common confusion is modeling a complex domain concept as an attribute. To illustrate, a destination airport is not really a string; it is a complex thing that occupies many square kilometers of space. Therefore, Flight should be related to Airport via an association, not with an attribute, as shown in Figure 12.3.

Relate conceptual classes with an association, not with an attribute.

Conceptual vs. Implementation Perspectives: What About Attributes in Code?

The restriction that attributes in the domain model be only of simple data types does not imply that C++ or Java attributes (data members, instance fields) must only be of simple, primitive data types. The domain model focuses on pure conceptual statements about a problem domain, not software components.

Later, during design and implementation work, it will be seen that the associations between objects expressed in the domain model will often be implemented as attributes that reference other complex software objects. However, this is but one of a number of possible design solutions to implement an association, and so the decision should be deferred during domain modeling.

Data Types

Attributes should generally be data types. This is a UML term that implies a set of values for which unique identity is not meaningful (in the context of our model or system) [RJB99]. For example, it is not (usually) meaningful to distinguish between:

• Separate instances of the Number 5.

• Separate instances of the String 'cat'.

• Separate instances of PhoneNumber that contain the same number.

• Separate instances of Address that contain the same address.

By contrast, it is meaningful to distinguish (by identity) between two separate instances of a Person whose names are both “Jill Smith” because the two instances can represent separate individuals with the same name.

In terms of software, there are few situations where one would compare the memory addresses of instances of Number, String, PhoneNumber, or Address; only value-based comparisons are relevant. By contrast, it is conceivable to compare the memory addresses of Person instances, and to distinguish them, even if they had the same attribute values, because their unique identity is important.

Thus, all primitive types (number, string) are UML data types, but not all data types are primitives. For example, PhoneNumber is a non-primitive data type.

These data type values are also known as value objects.

The notion of data types can get subtle. As a rule of thumb, stick to the basic test of “simple” attribute types: Make it an attribute if it is naturally thought of as number, string, boolean, date, or time (and so on); otherwise, represent it as a separate conceptual class.

If in doubt, define something as a separate conceptual class rather than as an attribute.