Last Lab 8, A Simple Database -- Due 12/11/8

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. Then your program will manipulate those objects in response to user inputs from your GUI.

This program is 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.

Due dates and Extra Credit

  1. Thurs, December 11 (last day of class): LATE PROGRAMS WILL NOT BE ACCEPTED.
  2. EXTRA CREDIT: Early programs will receive a bonus of 4% per day -- unlimited. For example, if you demo the lab by Thurs, 12/4 (i.e. 7 days early), you can gain 7*4%=28%! 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 28% of 0 is, well, 0.

Choices

You may choose either of the database labs detailed below, or, if you wish, you may propose your own.

  1. Common requirements

    Whichever choice you make, the following are required (do not attempt * or ** until the unstarred portions work!).

    1. Store your database in memory in an ArrayList. Do not read or write data to the disk except as detailed below.
    2. Organize your program so that the GUI Frame 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 (to any file they want), load (from any file they want), or append the database. The idea is that they might want to work with several databases; the append 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, both alphabetically and some other way that makes sense (like by balance, or score, or compatibility).

  2. 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. A simple Bank program was presented in class. 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(positive) 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. Make the PIN invisible when they type it.

  3. A tennis (or other competition) tournament simulation

    Simulate a seeded, single elimination tennis tournament (or basketball, or soccer, 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.

  4. 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 immediately!

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:

Demo your lab for credit