CS 231 Intro to Programming, Spring 2003
Lab 9 (Last Lab!)
Writing a Simple Database

Purpose

In this lab you will implement a simple database. To do so, you will use most of what you have learned throughout this course. You will begin by creating a list of objects by reading the information for each object from a disk file. (Alternatively, you can have the user enter all of the information through the GUI, but the user must be able to save this information to disk so that it can be loaded the next time the program is run.) Then your program will manipulate those objects in response to user inputs from a GUI you have built.

This program will be large enough that you may become very confused if you do not design your program well, or if you attempt to implement too much at once. Therefore, start small, and practice stepwise implementation; this requires discipline on your part, there is a great temptation to jump right in before thinking a problem through.

In doing this program you will also be fulfilling the English based Writing Centered portion of the class. There are two parts of this. First you must complete and hand in a design for your program; A first draft is due in class on Thursday April 17. The finished design is due the following Tuesday, April 22. Second, you must complete a retrospective essay discussing the process of designing, writing, and debugging your program. Both the design and the essay are described in more detail in links below.

Summary of Due dates and Extra Credit

You are to turn in the following items:

Thursday April 17 in class: Design draft.
Tuesday, April 22 in class: Final design draft.
Tuesday, May 6 (last day of class): LATE PROGRAMS WILL NOT BE ACCEPTED.
1. You must demonstrate your completed program by 5pm May 6.
2. You must turn in all deliverables (see section below) by 5pm May 6.
3. You must electronically submit your completed program by 11:59p.m. May 6
4. EXTRA CREDIT: Early programs will receive a bonus of 3% per day -- unlimited. For example, if you finish the lab by Tuesday, April 22 (i.e. 2 weeks early), you can gain 14*3%=42%! NB: Extra credit points are limited to the percentage of the code that is operational when you demo; thus, if you demo a program that does nothing at all, it would receive 0 points, and 42% of 0 is, well, 0.

Deliverables

Credit on this lab will be divided into three parts:

Choices

You may choose either of two different database labs, or, if you wish, you may propose your own.

Common requirements
Whichever choice you make, the following are required.
1. Store your database in memory in either an array or a Vector. Do not read or write data to the disk except as detailed below.
2. Organize your program so that the Applet file (or Application file) contains only user interface code. That is, put all the database handling code in your own classes.
3. File I/O
  1. Present an easy to use, easy to understand user interface.
  2. When the program starts, read the contents of the database from a file into memory.
  3. *When the program quits, write the contents of the database from memory to that file.
  4. **Allow the user to save, load, or append the database (to any file they want). The idea is that they might want to work with several databases; this feature allows them to merge two.
4. Database manipulation
  Allow the user to:
  1. display the current database in a TextArea.
  2. add or delete a record
  3. *view and change individual records. This would be a reasonable place to open another frame for them to do the editing in.
  4. **sort the database, either alphabetically or otherwise.
A bank simulation
Every major bank supports ATM machines. These are basically small database clients equipped with a card reader, money dispenser, deposit slot, keyboard and screen. In an early lab, you simulated an ATM; for this lab you will simulate a bank which can be accessed through such an ATM.
A bank has a number of customers. Each customer may have a checking account, or a savings account, or both. There are two types of accounts, checking and saving. Each account has a name, a personal identification number (PIN), an account number, and a balance. Both may be accessed from ATM machines.
1. Each ATM must support the following functions:
  1. Login -- type a name (to simulate the card reader), then a PIN. If they correctly login, then they can use the other features.
  2. Withdraw -- any amount less than the current balance.
  3. Deposit -- any amount.
  4. Transfer funds between checking and saving accounts.
  5. Display balance.
  6. Quit.
2. Additionally, you may wish to add some or all of the following functions:
  1. Eat their card if they try unsuccessfully to login too many times.
  2. Pay them interest every day at the end of the day; perhaps 4% on savings and 2% on checking.
  3. Make the PIN invisible when they type it.
A tennis (or other competition) tournament simulation
Simulate a seeded, single elimination tennis tournament (or basketball, or soccer, or Doom, or whatever). Banks always need programmers, but the work is, in my opinion, a trifle dull (although, surely some people enjoy it). Tournaments also sometimes employ programmers, though they typically don’t have as much money. You have more latitude in a tournament simulation than in the bank simulation; and it may be more fun and creative, but it may require more thinking. This will be written as if the subject is a tennis tournament; if you choose some other contest, adapt this to the area you choose.
Each player has a name, a ranking (i.e. their rank among all players), and two integer ability ratings: service and skill (these will be explained below). A tournament starts with all the players in a bracket by their seeds (as described in class). Each pair of players plays a match, and the winner advances to the next round. When a player loses a match they are out.
The winner of a match is the first player to win 3 sets. The winner of a set is the first to win 6 games and be at least 2 games ahead. The winner of a game (as you likely know) is the first to win 4 points and be ahead by at least 2.
1. Simulating a match. To simulate a match, simulate sets until one player has won 3.
2. To simulate a set, simulate games until a player has won at least 6 and is at least 2 games ahead. One player serves for the entire game; the serve alternates.
3. To simulate a game, simulate points until a player has at least 4 and is at least 2 points ahead.
4. To simulate a point (finally!), use the following algorithm (or another that you find more suitable):
  1. The value of service should be a number between 1 and 100. Interpret a server’s service score as the percentage of aces they will serve -- for our purposes, an ace is a serve which is not returned. Therefore, if their service value is 100 they will win every serve they make; if their service value is 50, then they have a 50-50 chance of winning each serve immediately.
  2. The value of skill should be a number between 50 and 100. If the receiver does return the serve, then the probability of the server winning the point is (S/R)*(1/2), where S is the server’s skill and R is the receiver’s skill. Therefore, if their skills are both 75, the odds of the server winning the point after a return are (75/75)*(1/2)=0.5, or 50%. If their skills are 100 and 50, the server will always win. If their skills are 80 and 60, then the odds of the server winning the point is (80/60)*(1/2)=2/3.
  3. Use Math.random() to get a random number. To choose to do one thing instead of another 70% of the time you would say:
```
int random = (int) (Math.random() * 100);	// get a number >=0, <100
boolean itHappens = random < 70;		// 70 times out of 100
if (itHappens) 
	    doOneThing();
else doAnother();
```
  By this method, or some other like it, you can arrange for the games to be as close or an one-sided as you like.
Design your own
Perhaps you would prefer to write a database program for some other area. For instance, perhaps you are interested in molecular biology and wish to build a catalog of human (or drosophila) genes and their interactions. Or perhaps you’d like to build a computer dating service. Or maybe you’d like to build an order taking and inventory system for an e-business. The possibilities are many.
If you’d like to design your own database program, then write up a proposal and I’d be happy to consider it. But, do it soon, it’s not long until May 6!

Problem solving advice

There are many different problem solving strategies that people employ when programming. Here, problem solving is the behavior that one engages in when one does not know how to proceed.

Some of the most common debugging strategies are:

Ask an expert
This method can be very effective, but as your programming expertise grows, it is less and less effective. As programmers become proficient, fewer and fewer things actually stop them, and even when they are frankly confused, they do not give up. Clearly there are times when the right thing to do is ask for help, but learning self-reliance and confidence is preferable to remaining dependant and helpless without the expert.
Try to find the problem yourself.
1. Attempt to analyze the code -- by staring at it and thinking.
2. Insert output statements -- to discover the values of variables.
3. Use the debugger -- as above but an order of magnitude faster.
4. Do an experiment -- to figure out what’s happening.

[top]