- Introduction
- 16.1 Applying UML: Common Class Diagram Notation
- 16.2 Definition: Design Class Diagram
- 16.3 Definition: Classifier
- 16.4 Ways to Show UML Attributes: Attribute Text and Association Lines
- 16.5 Note Symbols: Notes, Comments, Constraints, and Method Bodies
- 16.6 Operations and Methods
- 16.7 Keywords
- 16.8 Stereotypes, Profiles, and Tags
- 16.9 UML Properties and Property Strings
- 16.10 Generalization, Abstract Classes, Abstract Operations
- 16.11 Dependency
- 16.12 Interfaces
- 16.13 Composition Over Aggregation
- 16.14 Constraints
- 16.15 Qualified Association
- 16.16 Association Class
- 16.17 Singleton Classes
- 16.18 Template Classes and Interfaces
- 16.19 User-Defined Compartments
- 16.20 Active Class
- 16.21 Whats the Relationship Between Interaction and Class Diagrams?
This chapter is from the book
This chapter is from the book
This chapter is from the book
16.4 Ways to Show UML Attributes: Attribute Text and Association Lines
Attributes of a classifier (also called structural properties in the UML[1]) are shown several ways:
- attribute text notation, such as currentSale : Sale.
- association line notation
- both together
Figure 16.3 shows these notations being used to indicate that a Register object has an attribute (a reference to) one Sale object.
)
Figure 16.3 Attribute text versus association line notation for a UML attribute.
The full format of the attribute text notation is:
visibility name : type multiplicity = default {property-string}
Also, the UML allows any other programming language syntax to be used for the attribute declaration, as long as the reader or tool are notified.
As indicated in Figure 16.1, visibility marks include + (public), - (private), and so forth.
Guideline: Attributes are usually assumed private if no visibility is given.
Notice in Figure 16.3 that this attribute-as-association line has the following style:
- a navigability arrow pointing from the source (Register) to target (Sale) object, indicating a Register object has an attribute of one Sale
- a multiplicity at the target end, but not the source end
- use the multiplicity notation
- a rolename (currentSale) only at the target end to show the attribute name
- no association name
Guideline: When showing attributes-as-associations, follow this style in DCDs, which is suggested by the UML specification. It is true that the UML metamodel also allows multiplicity and rolenames at the source end (e.g., the Register end in Figure 16.3), and also an association name, but they are not usually useful in the context of a DCD.
Guideline: On the other hand, when using class diagrams for a domain model do show association names but avoid navigation arrows, as a domain model is not a software perspective. See Figure 16.4.
){kind=small}
Figure 16.4 Idioms in association notation usage in different perspectives.
Note that this is not a new kind of association notation. It’s the same UML notation for associations explored while applying class diagrams to domain modeling. This is an elaboration of the notation for use in the context of a software perspective DCD.
Guideline: When to Use Attribute Text versus Association Lines for Attributes?
This question was first explored in the context of domain modeling. To review, a data type refers to objects for which unique identity is not important. Common data types are primitive-oriented types such as:
- Boolean, Date (or DateTime), Number, Character, String (Text), Time, Address, Color, Geometrics (Point, Rectangle), Phone Number, Social Security Number, Universal Product Code (UPC), SKU, ZIP or postal codes, enumerated types
Guideline: Use the attribute text notation for data type objects and the association line notation for others. Both are semantically equal, but showing an association line to another class box in the diagram (as in Figure 16.3) gives visual emphasis—it catches the eye, emphasizing the connection between the class of objects on the diagram. See Figure 16.5 for contrasting examples.
){kind=small}
Figure 16.5 Applying the guidelines to show attributes in two notations.
Again, these different styles exist only in the UML surface notation; in code, they boil down to the same thing—the Register class of Figure 16.5 has three attributes. For example, in Java:
public class Register
{
private int id;
private Sale currentSale;
private Store location;
// …
}
The UML Notation for an Association End
As discussed, the end of an association can have a navigability arrow. It can also include an optional rolename (officially, an association end name) to indicate the attribute name. And of course, the association end may also show a multiplicity value such as ‘*’ or ‘0..1’. Notice in Figure 16.3 that the rolename currentSale is used to indicate the attribute name.
And as shown in Figure 16.6, a property string such as {ordered} or {ordered, List} is possible. {ordered} is a UML-defined keyword that implies the elements of the collection are (the suspense builds…) ordered. Another related keyword is {unique}, implying a set of unique elements.
The keyword {List} illustrates that the UML also supports user-defined keywords. I define {List} to mean the collection attribute lineItems will be implemented with an object implementing the List interface.
How to Show Collection Attributes with Attribute Text and Association Lines?
Suppose that a Sale software object holds a List (an interface for a kind of collection) of many SalesLineItem objects. For example, in Java:
public class Sale
{
private List<SalesLineItem> lineItems =
new ArrayList<SalesLineItem>();
// …
}
Figure 16.6 shows two ways to illustrate a collection attribute in class diagrams.
)
Figure 16.6 Two ways to show a collection attribute in the UML.
Notice also the optional use of property strings such as {ordered}.