11.3 A First Attempt at Producing an Object Model for the ATM

We begin by collecting all of the class candidates in our system. We are basically looking for nouns in the requirement specification. We will ignore the fact that the ATM (and its pieces) and the Bank (and its pieces) are in completely different address spaces on two different processors. We can ignore this fact during analysis time due to a design technique of using proxies, which we will explore when we start discussing the communication between items in the ATM application and items in the Bank application. Likewise, we ignore how objects are stored in our domain. The fact that accounts are in some central database within the bank is irrelevant. A good trick is to think of everything as living in memory. Later, in low-level design, we worry about the actual storage. We can get away with this trick because when an object of one class sends a message to an object of another class, that object will reside in memory. We can always "fake" this by hiding the actual access of the object within its class.

Given these assumptions, we can come up with the object model in Figure 11.2 by examining nouns in the domain and exploiting natural aggregations in the system. Natural aggregations result when tangible items are physically contained in another item; for example, ATMs contain card readers, banks contain accounts.

This first object model has captured the natural aggregations inherent in ATMs and Banks. Notice the lack of associations in this model. I argue that most of the associations in this system cannot be captured without examining the behavior of the system. Why are ATMs associated with Banks? They need a bank to process transactions. Why are Transactions associated with Accounts? They need accounts to process themselves. The association exists only to satisfy some behavioral aspect of the system, that is, a uses relationship. This is in contrast to a system that lacks interesting behavior. Why are assignments associated with grades in an automated grading system? Because they just are; it is defined in the requirement specification.

One could argue that the inheritance relationships require behavior as well. After all, do the Transaction and Account classes have derived classes or are they concrete classes? The answer depends on whether or not the derived classes have interesting differences in behavior. If Savings and Checking accounts behave differently, then their design in our object model makes sense. If they do not behave differently, then Savings and Checking will end up irrelevant classes since all of their behavior will factor up to the Account class. There are two schools of thought on this subject. Data-driven analysis states that inheritance should be added up front and then eliminated during design time if the derived classes end up being irrelevant classes. Behavior-driven analysis states that inheritance is added at design time, only when commonality is found between two existing classes. Either view can be useful. We arbitrarily choose the first principle in this example, that is, we add inheritance wherever it is suspected and eliminate it at design time if necessary. (See Section 5.12 for a full discussion on the migration of either design choice to a correct design.)