Attributes

Attributes are very similar to associations.

At the conceptual level, a Customer's name attribute indicates that Customers have names . At the specification level, this attribute indicates that a Customer object can tell you its name and has a way of setting a name. At the implementation level, a Customer has a field (also called an instance variable or a data member) for its name.

Depending on the detail in the diagram, the notation for an attribute can show the attribute's name, type, and default value. The UML syntax is visibility name: type = defaultValue, where visibility is the same as for operations, described in the next section.

So what is the difference between an attribute and an association?

From the conceptual perspective, there is no difference. An attribute carries just another kind of notation that you can use if it seems convenient . Attributes are usually single-valued. Usually, a diagram doesn't indicate whether an attribute is optional or mandatory, although you can do this by putting the multiplicity after the attribute name in square brackets ”for example, dateReceived[0..1] : Date.

The difference occurs at the specification and implementation levels. Attributes imply navigability from the type to the attribute only. Furthermore, it is implied that the type contains solely its own copy of the attribute object, implying that any type used as an attribute has value rather than reference semantics.

I'll talk about value and reference types later on. For the moment, it's best to think of attributes as small, simple classes, such as strings, dates, money objects, and non-object values, such as int and real.