Now, let’s take what we’ve learned in the previous tutorial and apply it. In this example we are asked to create a class diagram for a banking system. It must have the following classes:
- Bank
- ATM
- Customer
- Account
- Transaction
- Checking Account
- Savings Account
Let’s determine possible class members for each of the above.
The bank class represents a physical bank. It has a location and a unique id. This bank also manages several accounts. **There’s an association!** What type of association is this? Is a bank entirely composed of accounts (composition)? Or are accounts ‘part of’ a bank (aggregation)? It looks like aggregation. It can’t be composition because that would mean that both classes live and die together. That’s not quite right because you can have a bank without accounts and you can have accounts without a bank. We’ll add a method called getAccounts().
The ATM class represents a physical ATM. Right off the bat, we can come up with three methods for the ATM: withdraw(), deposit(), checkBalance(). Each of these methods takes the card number as input. In terms of attributes, an ATM has a location and is managed by a specific bank.
The customer class represents a real customer. This customer has a name, address, date of birth (dob), card number, and pin. For this person to be considered a customer, they must have an account. **There’s another association!** This isn’t aggregation or composition, it’s just a bi-directional association (drawn using a blank line no arrows).
The account class represents a bank account. Common attributes of bank accounts include account number, balance, etc. You can deposit() withdraw() money from the account. In addition, banks might offer two types of accounts: a checking account and a savings account. These two can thus be considered child classes of the account class and can inherit from it too. We’ll denote this by using a solid black line with an unfilled arrow going into the account class.
