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.
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).
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
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.
of your grade will be on the design of the application. A fancy UI will not
offset a poor design.
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.
the functionality in the project in order of importance
a minimal bare bones working program.
features, in priority order, to the program one at a time
this way you will always have a working system with the most important features
implemented in any given amount of time.