[ Team LiB ] Previous Section Next Section

Properties

Properties represent structural features of a class. As a first approximation, you can think of properties as corresponding to fields in a class. The reality is rather involved, as we shall see, but that's a reasonable place to start.

Properties are a single concept, but they appear in two quite distinct notations: attributes and associations. Although they look quite different on a diagram, they are really the same thing.

Attributes

The attribute notation describes a property as a line of text within the class box itself. The full form of an attribute is:

visibility name: type multiplicity = default {property-string}

An example of this is:

- name: String [1] = "Untitled" {readOnly}

Only the name is necessary.

  • This visibility marker indicates whether the attribute is public (+) or private (-); I'll discuss other visibilities on page 83.

  • The name of the attribute梙ow the class refers to the attribute梤oughly corresponds to the name of a field in a programming language.

  • The type of the attribute indicates a restriction on what kind of object may be placed in the attribute. You can think of this as the type of a field in a programming language.

  • I'll explain multiplicity on page 38.

  • The default value is the value for a newly created object if the attribute isn't specified during creation.

  • The {property-string} allows you to indicate additional properties for the attribute. In the example, I used {readOnly} to indicate that clients may not modify the property. If this is missing, you can usually assume that the attribute is modifiable. I'll describe other property strings as we go.

Associations

The other way to notate a property is as an association. Much of the same information that you can show on an attribute appears on an association. Figures 3.2 and 3.3 show the same properties represented in the two different notations.

Figure 3.2. Showing properties of an order as attributes

graphics/03fig02.gif

Figure 3.3. Showing properties of an order as associations

graphics/03fig03.gif

An association is a solid line between two classes, directed from the source class to the target class. The name of the property goes at the target end of the association, together with its multiplicity. The target end of the association links to the class that is the type of the property.

Although most of the same information appears in both notations, some items are different. In particular, associations can show multiplicities at both ends of the line.

With two notations for the same thing, the obvious question is, Why should you use one or the other? In general, I tend to use attributes for small things, such as dates or Booleans梚n general, value types (page 73)梐nd associations for more significant classes, such as customers and orders. I also tend to prefer to use class boxes for classes that are significant for the diagram, which leads to using associations, and attributes for things less important for that diagram. The choice is much more about emphasis than about any underlying meaning.

    [ Team LiB ] Previous Section Next Section