Identifying Attributes and Operations

Until now we haven't paid much attention to attributes or operations. In this section we see how to identify both.

Attributes

We have already encountered several attributes, particularly during the class identification exercise. Recall that we identified many nouns that were actually attributes (rather than classes) because they didn't have structure and behavior in their own right but merely served as structural components of something else.

In the case of Remulak Productions, nouns such as first name, name, and last name are part of the Customer class. Attributes such as address line 1, address line 2, address line 3, city, state, postal code, and country are part of the Address class, whereas attributes such as quantity, extended price, and line discount are part of the OrderLine class. Soon the attributes that form the structural backbone of the Remulak classes begin to take shape.

Recall that the previous UML class diagram showed three compartments for a class, containing the class name, attributes, and operations. The attributes go in the second compartment and have a defined structure; an example is shown in Figure 5-12.

The attribute name is entered in camelback notation; that is, the first letter is lowercase, and the remaining full word components are uppercase. A colon separates the name from the attribute type. The type may be a primitive attribute defined for the particular language environment or a complex type such as another class or structure. Any default initial value for a particular attribute may also be specified as shown. Visibility specifies the attribute's accessibility to the outside consumer. In UML, there are three types of visibility: public (+), private (–), and protected (#).

We don't want to get hung up on completing the entire attribute definition. We might not know the type or default initial values, if any, at this time. Eventually, however, we will need all of this information before we can generate any program code and use it meaningfully.

Operations

Operations define the behavior supported by a given class. At this point we might not have a clear idea of the exact operations that each class will support; that will be driven by the work to be done as specified in the use-cases. The operations will take more shape as the project moves into the dynamic modeling stage, which is explored in Chapter 7. However, answering some basic questions will help us begin to identify the operations:

• What does the class know how to do?

• What is the class expected to do for others?

• What are the responsibilities of the class?

For example, the Order class should know how to calculate some type of total due, and it should know if anything is back-ordered.

The operation goes in the third compartment of the class and has a defined structure, as illustrated in Figure 5-13. Like the attribute name, the operation name is entered in camelback notation. After the operation name, the parameters (arguments) that make up the input to the operation are defined (within parentheses). The argument specification conveniently takes the same form as the attribute specification outlined in the attribute section. Multiple input arguments are allowed and are separated by commas. Finally, the type of the output returned by the operation, if any, may be specified.

The entire set of arguments, with the exception of the return type, is called the operation signature. Operation signatures are important to polymorphism, as we will see when the nuances of polymorphism are explored during the Elaboration and Construction phases of the project.

As with attributes, we don't worry about completing the entire signature for each operation because we might not know them at this point. We will need to complete all of this information before we can generate any program code and use it meaningfully, but from experience I have found that the developers, not the designers, are the biggest contributors to the pool of private operations.