Modeling Attributes

The class diagram in Fig. 22.12 lists some of the attributes for the classes in our system—the descriptive words and phrases in Fig. 22.11 helped us identify these attributes. For simplicity, Fig. 22.12 does not show the associations among classes—we showed these in Fig. 22.10. This is a common practice of systems designers when designs are being developed. Recall from Section 22.4 that in the UML, a class’s attributes are placed in the middle compartment of the class’s rectangle. We list each attribute’s name and type separated by a colon (:), followed in some cases by an equal sign (=) and an initial value.

Fig. 22.12. Classes with attributes.

Consider the userAuthenticated attribute of class ATM:

This attribute declaration contains three pieces of information about the attribute. The attribute name is userAuthenticated. The attribute type is Boolean. In C++, an attribute can be represented by a fundamental type, such as bool, int or double, or a class type. We’ve chosen to model only primitive-type attributes in Fig. 22.12—we discuss the reasoning behind this decision shortly. [Note: Figure 22.12 lists UML data types for the attributes. When we implement the system, we’ll associate the UML types Boolean, Integer and Double with the C++ fundamental types bool, int and double, respectively.]

We can also indicate an initial value for an attribute. The userAuthenticated attribute in class ATM has an initial value of false. This indicates that the system initially does not consider the user to be authenticated. If an attribute has no initial value specified, only its name and type (separated by a colon) are shown. For example, the accountNumber attribute of class BalanceInquiry is an Integer. Here we show no initial value, because the value of this attribute is a number that we do not yet know—it will be determined at execution time based on the account number entered by the current ATM user.

Figure 22.12 does not include any attributes for classes Screen, Keypad and DepositSlot. These are important components of our system, for which our design process simply has not yet revealed any attributes. We may still discover some, however, in the remaining design phases or when we implement these classes in C++. This is perfectly normal for the iterative process of software engineering.

Figure 22.12 also does not include attributes for class BankDatabase. Recall that attributes can be represented by either fundamental types or class types. We’ve chosen to include only fundamental-type attributes in the class diagram in Fig. 22.12 (and in similar class diagrams throughout the case study). A class-type attribute is modeled more clearly as an association (in particular, a composition) between the class with the attribute and the class of the object of which the attribute is an instance. For example, the class diagram in Fig. 22.10 indicates that class BankDatabase participates in a composition relationship with zero or more Account objects. From this composition, we can determine that when we implement the ATM system in C++, we’ll be required to create an attribute of class BankDatabase to hold zero or more Account objects. Similarly, we’ll assign attributes to class ATM that correspond to its composition relationships with classes Screen, Keypad, CashDispenser and DepositSlot. These composition-based attributes would be redundant if modeled in Fig. 22.12, because the compositions modeled in Fig. 22.10 already convey the fact that the database contains information about zero or more accounts and that an ATM is composed of a screen, keypad, cash dispenser and deposit slot. Software developers typically model these whole/part relationships as compositions rather than as attributes required to implement the relationships.

The class diagram in Fig. 22.12 provides a solid basis for the structure of our model, but the diagram is not complete. In Section 22.6, we identify the states and activities of the objects in the model, and in Section 22.7 we identify the operations that the objects perform. As we present more of the UML and object-oriented design, we’ll continue to strengthen the structure of our model.