SDSU CS 535 Object-Oriented Programming & Design
Fall Semester, 2000
Project Description
Assignment Index
© 2000, All Rights Reserved, SDSU & Roger Whitney
San Diego State University -- This page last updated 15-Nov-00
An International Electronic Checkbook

The checkbook allows the standard type of entries: checks, deposits, automatic deductions from utility (electric, phone, water) companies for payment of bills, automatic deductions for paying credit card bills and automatic deposits. One can also schedule regular or individual payments to individuals or companies. Check book items can be in currencies of a number of different countries: Belguim, Germany, England and United States. A user of the electronic checkbook can denote a primary currency. The balance of the checkbook is always kept in the users primary currency. Each entry keeps track of the original currency of the transaction. Currency rates can change. When a transaction is entered into the checkbook, the currency rate at that time is used to convert the transaction to the native currency amount.

The checkbook keeps a history of all transactions. A user does not lose data in the history when they exit the program. When they restart the program the entire history of transactions still exists. The user can sort the history of transactions by date, amount or by tax status (tax deductible or not).

Files for input
Banks have infrastructure in place for automatic payments and deductions from an account. Banks also have infrastructure to process checks. To simulate this we will use files. Create a file that will hold a day's worth of transactions. The format of the file is up to you. Your program will read the file and process the transactions.

UI issues

You can use either a graphical based interface (GUI) or a text base interface (TUI) to your program. There are pros and cons for each type of interface. A GUI looks nicer and is the standard for applications. Implementing a GUI gives you practice in this important area. However, a GUI can take more time, particularly if you have not built a GUI in your implementation language. A TUI is easier to implement and will take less time. However, TUIs can have a negative impact on your design. TUIs tend to be procedural. This can drive the rest of your program to be procedural. With a TUI it seems harder to keep the UI code and the application code separate.

Most of your grade will be on the design of the application. A fancy UI will not offset a poor design.

Time and Scope

Given the time remaining in the semester, the project may seem a bit too large. This is of course a common situation. Customers, managers and/or marketing departments often want more than can be delivered in given timeframe. When working on a project there are four related variables: cost, scope, time and quality. In our case the time for the project is fixed: the end of the semester. The cost (or size of our teams) is also fixed. You can work in teams of one or two. This leaves quality and scope. The customer for the project (the instructor) values quality over scope. A well designed and working implementation of a reasonable size part of the project will get a higher grade than a poorly designed full implementation.

You need to:



In this way you will always have a working system with the most important features implemented in any given amount of time.


Copyright ©, All rights reserved.
2000 SDSU & Roger Whitney, 5500 Campanile Drive, San Diego, CA 92182-7700 USA.
OpenContent license defines the copyright on this document.
    visitors since 15-Nov-00