CIS501 Assignment 5 (Project 1, Implementation)

10 points; due Weds., April 8

You will implement your design for the banking system. Construct a VS Solution, consisting of multiple Projects, implementing the database assembly, the ATM assembly, and the Teller assembly. There will also be a Unit-Test project for the database assembly (see below).

You will use threads to implement two ATMs and one Teller, and the three threads share the database. Use the techniques we studied in Lecture 9 to construct the threads and to ensure exclusive access to objects in the database.

Implementing the database assembly

The collections of customer objects and account objects, plus one or more controllers, constitute the system's database. The database is much simpler than the databases you implement with commercial products like Oracle, but it is a database nonetheless (more on this below).

The database will be shared by multiple threads of ATMs and Teller(s), so you must use locks in the methods that grant access to customer and account objects. Since a customer or account object will be "checked out" and used over a period of time, the object must be treated like a file is treated: the controllers for the database must remember which objects are "checked out". You use the techniques we learned in Lecture 9 to implement object management.

We will keep this simple and not implement database initialization, backup, and archiving. Instead we will use a simple trick to initialize the database when you start your system: In Program.cs, in Main, just before you start the threads for the ATMs and the Teller, insert commands that tell the database to construct these two objects:

one customer object, name "D. Trump", address "Atlantic City, NJ", customer number "001".
one account object, account number "100", owned by "D. Trump", that has a balance of 80 dollars.

This is just enough data so that you can test the ATMs and Tellers by looking up D.Trump's info. So that you (and I) can test the ATM, please show a MessageBox with the message, Account number 100 constructed for D.Trump, immediately after you have constructed the customer object and its one account object.

The commands will talk directly to the database's controllers to construct the new objects. Then the rest of the system starts, and you use the GUI forms to do additional work.

Implementing the Teller and ATMs

Each ATM assembly connects to the database. An ATM Form must look like a real one: it must have at least

a "keypad" of ten numeral buttons, 0,1,2,...,9
an OK button
a Label display area.

There might be more buttons, this is up to you. The GUI should look and behave like a real ATM, so that the software you write can be deployed (installed) on real ATM hardware.

The Teller assembly also connects to the database, and since it runs on a PC, its GUI Form(s) can be any format you choose, as long as it does the required behaviors and someone like me can figure out how to use it.

We are building the ATM and Teller with threads so that it is a bit realistic and so that a network expert can take our code and install it on real ATM hardware and real PCs.

Implementing "cash"

When a human uses the ATM to withdraw cash, the ATM is supposed to give actual cash. When you code your system, implement the ATM so that it shows a message box that displays the amount of money that would be fed to the human. (When the network expert installs the real system, the message-box code would be replaced by a hardware call to a physical cash dispenser.) Use message boxes in a similar way in the Teller assembly.

Unit tests

Write unit tests for the database assembly --- it is a waste of time to build Forms for ATMs and Tellers if the database is broken! The unit tests should be coded as a VS Project (Console App) and should at least test the creation of a new customer, creation of a new account for a customer, check account balance, deposit money to an account, and withdraw money from an account. You can have more tests, but test at least this much before you start building ATMs and the Teller.

No unit tests are required for the ATM and Teller assemblies --- just connect them to the database and test them that way. So, I am not asking for a lot of testing, just enough so that you won't waste your time testing a "front end" that uses a bad "back end".

Build the system in stages

Implement the database assembly first and unit-test it. Code and test that the database can do these actions

customer creation
account creation
account-balance check
account deposit
account withdrawal
account deletion (do this one last, if you have time)
customer deletion (do this one last, if you have time)
If you do the work in small steps --- code and test, code and test --- it will go smoothly and quickly.
Code the ATM assembly and connect it to the database, like this: In Program.cs, construct the two objects for D.Trump, and construct one ATM thread. Test the ATM by doing a balance check and then a withdrawal and then a balance check for D.Trump.
Implement the Teller assembly and connect it to the database. Test the Teller assembly with the operations lists in Step 1 above, one at a time.
Add threads and locks (if they aren't there yet!), and generate a complete system with two ATM threads and one Teller thread. Ensure that it is impossible for two threads to access the same account and withdraw money at the same time.

Now, double check that you have tested all the use cases that are stated in Assignment 4; this is the minimal correct behavior that is expected. Also try a test or two with bad user input (trying to access a non-existent account, trying to withdraw too much money from an account.)

Comment your code

You are required to insert at least a one-line comment for each class, important field, and method in your code. This isn't much, and it is a great habit to maintain.

About the database part

This system uses a database, albeit a simple one. When you pay big money for a database system like Oracle, you get

a package of classes for generating a network of linked objects and a controller object that can link to objects constructed from the classes
a GUI-based tool or a "Data Definition Language" ("DDL") that helps you use the controller and the classes to construct a database as a collection of linked objects
an interpreter that understands a query language ("DML" --- "data manipulation language"), like SQL's DML, for doing database searches and updates.

A database query language is a lookup language, e.g., "Select all the customers who own a bank account where balance > 10,000 dollars." The interpreter converts the query into a search algorithm that traverses the linked objects and collects the answers into a table that it gives back to you. If you take a database course, you will learn how the search algorithm is extracted from the query and how the answer table(s) are built.

For this assignment, we don't need a query language as expressive as SQL's DML since our queries are super-simple, e.g., "find account 101 and deposit 20 dollars in it." It is serious work to code an interpreter that understands an SQL-like language, but if this is something you want to learn, take CIS505 and also CIS560.

What you must submit

Make a folder with the name, MyLastName.MyFirstName.Assn5, and copy into it

your VS Solution (make certain that its Main method ininitializes the database with the two objects for D.Trump)
the class diagram that matches the implementation; it serves as documentation for future deployment and maintenance.
any other materials (e.g., README files) that might help Mr. Janovsky and I understand and use your system.

Zip the folder and upload on K-State Online.

This is individual work

You must do this exercise solo. This is because I must assess the skills you have acquired so far in your studies. If you have difficulties, we can discuss what can be done to improve your abilities. If I determine that you had unauthorized aid, I will award no points for your work.