CSc 221 Spring 2007 Final Project Page

ADDED 5.5.2007: I've started a page on the final presentations May 15 and 17.

ADDED 5.1.2007: Deliverable 1 is due at class time Thurs 5.3. 2 point bonus (added to the    Oops. Something got lost here. The bonus is 1 point, per the table on the Deliverables page.

ADDED 4.29.2007: Added requirements, growing out of class discussion April 26.

• Each customer will have a transaction history. This is a list, in decreasing date sequence, of all the transactions (deposits, and/or withdrawals) that have taken place in the previous month. Make that decreasing time sequence: a customer could have several transactions in a single day; so you need to keep date and time. Get these from the system calendar and clock. (Google for the API features.) When a customer clicks on a button asking for transaction history, he/she should be presented with the first ten or so--whatever will fit on the screen space. Provide date, amount, and an indication whether it was a deposit or a withdrawal. The time need not be given, since the transactions will be presented in the order they occurred. The display must be read-only; the customer cannot change history! In fact, of course, everything you present--other than the transaction amount--should be read-only.
• A question was raised about CSS, in the context of the requirement that you do something in your project with HTML. Check here for a tutorial overview of both HTML and style sheets.
• Hmmm. I've never said exactly what you should do with HTML. Please look into launching an HTML page when the user clicks on "Transaction History," or whatever you call it. This is commonly done. Too commonly, but that's another story. This is an ideal opportunity for a division of effort.
• I think that's it. You should expect that more requirements will be added. This is normal business practice.

ADDED 4.28.2007: Click here to go to a project deliverables page.

ADDED 4.26.2007: Here is some data, or rather some talk about how to get and/or generate data.

ADDED 4.27.2007: Class discussion today: we need some level of security. Each account will have a PIN. We have three weeks (!!!!!) so we'll keep it simple. Each account will start up with a PIN that is a four-character String; it will initially be the last four characters of the customer Social Security Number (SSN). All "characters" of the SSN are decimal digits; there are no letters. I think a few real SSNs are ten characters, with the last character being a letter; we do digits only.

Below is the project as first posted, around April 21. Nothing below has been deleted from the requirements.

Here are some of the key features of our simple ATM:

• A customer has one checking account only, and the only transactions are cash deposits and cash withdrawals.
• All amount are stored as BigDecimal Down with double for pennies! We'll look at this in class, of course.
• Make a nice display, with the general appearance of a real ATM screen. You will provide a substitute for a touch screen. No keyboard operations, of course, and no picture of a keyboard.
• You will be given a file of about a thousand customers that a student generated for this course two years ago. This will get some data to work with, minus the tedium of keyboarding a lot of made-up data. The project two years ago involved a database, which we are not doing this term, but the data will work, with some modifications.
• You will store the customers in a Java collection, perhaps a linked Hashtable. We'll talk about this too, obviously.
• Somewhere, you will use a Java program to generate an HTML file. This will be the barest hint of how Web-based apps "do it." But no Tomcat, MySQL, browser servers, EJBs, . . .    Sorry. That's 473, as it evolves (Website Design). Try to take that whenever it's offered. I've usually taught it; students did some great work when Prof. Grossberg taught it. A topic I wish we (the CS Dept) could cover much more thoroughly.
• For a selected few special customers, you will provide a hint of their favorite music: a few bars of a song and a picture of the composer or performer. This will give you a little experience with multimedia and file formats for graphics and sound. Not a complete treatment, naturally, but a good starter kit if you take a multimedia course or have to learn it on your own. You have already done some graphics (that was part of the plan) and some class members know a lot about graphics (and maybe sound) already. They are eager to share, I'm sure.
• And more, as we all think up things and decide there is time to do them.

Grading will be based on a number of factors, details tba. Sketch:

• A running program, properly formatted. (I won't read code that is left-aligned. It's very late in the semester to have to say that . . . again.)
• All features that are required. Turn that around: partial credit for incomplete projects.
• A PowerPoint presentation showing the results of your usability testing. Huh? Usability testing? Part of software development, friends.
• A running prototype on a date to be specified, before the final presentations of course.
• Your project presentation, which each team will do on the last day of the course. Each team member must participate, i.e., speak. As required for ABET accreditation.

There will be lots of additions to this page. This is NOT a complete set of requirements. That fact is, of course, partly a concession to necessity. But I also want to give you a living experience with the fact that in the real-world specifications are essentially never "complete" when you begin work. You get the job done anyway, which may include dragging the specifications out of the customer. (That's me, for you.) Stay tuned!

NOTE: There is a lot here, obviously. A superb opportunity for teams to split up responsibility. One member does the amounts-in-pennies class, one focuses on the collections, and one does sound. Or whatever.

Back to the top of the Spring 2007 CSc 221 page

Back to Dan McCracken's Home Page