In a previous lesson, we identified the following real-world entities that are involved in managing a checkbook: account, checking account, savings account, CD, money market account, credit card, charge card, Visa, MasterCard, American Express, Discover, stock, bond, social security number, money, check, ATM card, budget, mutual fund, bank, loan, mortgage, checkbook, ledger, cash. Since then, you narrowed the list to CheckingAccount, Check, Deposit, and Bank. You improved the design of Check by creating classes called Money and Date to hold attributes of Check. (It is not uncommon to discover additional classes you need at later stages of modeling.)
Draw class diagrams for these six classes (CheckingAccount, Check, Deposit, Bank, Money, and Date) and any others you feel belong in the system. The diagrams should indicate the names of the classes, the names of the attributes, and the types of each attribute. When an attribute is an instance of another class, draw a line to that class. You may prefer to create separate detailed diagrams for each class and an overview diagram for the relationships.

The following three classes should be included in your project, but we've spelled them out for you because you probably wouldn't come up with them with unless you are familiar with object-oriented design.
Your project should include a Bank class that represents any institution where an account is stored and a CheckList class and a DepositList class that hold lists of checks and deposits respectively.

Recall that although we speak of a phone number, no arithmetic is ever performed on it, and it may contain punctuation, spaces, and alphabetic characters as well as digits: for example, (800) JKL-BANK. Therefore, a phone number is really a string data type, not a number.
Next come the list classes. Note that I do not specify any algorithm for storing the list at this point.