Detailed Design

A major task of detailed design is to spell out, in detail, the attributes and methods needed by each class (the second and third "compartments" of the representation for each class in a class diagram.)

The methods needed by each class are implicit in the responsibilities assigned to the class in the CRC cards, and become explicit in the Interaction Diagrams. A responsibility listed for a class on its CRC card generally maps into a method or methods in the detailed design. Likewise, any time an object belonging to a given class is shown as the recipient of a message in either a Sequence or Collaboration Diagram, the class needs a corresponding method. Many of the needed attributes are also either explicitly or implicitly present in the diagrams; the need for others becomes evident as the code for the class is being written. (Thus detailed design and coding are a "round trip" process - detailed design dictates coding, and coding leads to elaboration of the detailed design.)

In designing this system, a few key design decisions were made:

• The class ATM is made an active class - that is, the ATM object has its own thread. Using the Java thread facllity leads to defining a run() method in this class whose body is executed by the ATM's thread. The fact that class ATM is active is indicated in class diagrams by enclosing it in a heavier outline.
   
• Certain signals initiate computation - e.g. the signals from the operator console when the state of the switch is changed, or from the card reader when a card is inserted. In the GUI simulation of the ATM, these signals are sent by the "actionPerformed()" method of the appropriate GUI button; in a real ATM they would be sent by the physical components themselves, which might then also need to be active classes. (Note: this forms an exception to the rule that a responsibility on a CRC card translates into a method in the design - in this case the class sends a signal, rather than receiving it, so it does not need a method directly corresponding to the responsibility.)
   
• The Transaction hierarchy consists of the abstract class Transaction and four concrete subclasses (Withdrawal, Deposit, Transfer and Inquiry). The class Transaction has a "virtual constructor" called makeTransaction() which asks the customer to choose a transaction type and then constructs and returns an object of the appropriate subclass. The Transaction class is made responsible for carrying out the Transaction use case and the Invalid PIN extension; for the former, it makes use of abstract methods getSpecificsFromCustomer() and completeTransaction() which are implemented concretely by each subclass.
   
• The class Receipt is abstract. The completeTransaction() method of each kind of transaction creates a concrete instance that contains the information relevant to that kind of transaction.
   
• The class Status is abstract. The send() method of NetworkToBank constructs a concrete instance that contains the information appropriate to the response received from the bank to a particular message.

In the design below, each class is developed in isolation. No attempt is made to connect each class to related classes as in the class diagram, because the resulting picture would not fit on a displayable web page. Therefore, this detailed design should be viewed in conjunction with the Class Diagram developed earlier.

• Detailed design for class ATM
   
• Component parts of the ATM
   
  • Detailed design for class CardReader
  • Detailed design for class CashDispenser
  • Detailed design for class CustomerConsole
  • Detailed design for class EnvelopeAcceptor
  • Detailed design for class Log
  • Detailed design for class NetworkToBank
  • Detailed design for class OperatorPanel
  • Detailed design for class ReceiptPrinter
  
  
• Detailed design for class Session
   
• The Transaction class hierarchy
   
  • Detailed design for class Transaction
  • Detailed design for class Withdrawal
  • Detailed design for class Deposit
  • Detailed design for class Transfer
  • Detailed design for class Inquiry
  
  
• Classes representing banking concepts, used by the above
   
  • Detailed design for class AccountInformation
  • Detailed design for class Balances
  • Detailed design for class Card
  • Detailed design for class Message
  • Detailed design for class Money
  • Detailed design for class Receipt
  • Detailed design for class Status

Page of links for non frames-enabled browsers.

Copyright © 2000, 2001, 2002 - Russell C. Bjork. Permission for non-commercial reproduction for educational use is hereby granted; all other rights are reserved.