Database Management System - demo by the last lab
In this lab you will implement a simple database. To do so, you will
use most of what you have learned throughout this course. Your program will
read information from files to create lists of records (or, as we say in the object
paradigm, Objects); then it will manipulate
those lists and records (Objects) in response to user actions from a GUI you have built.
This program is large enough that you may become 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 date and Extra Credit
- By Friday week 13 (i.e 11/21, Friday before T'day break): Design.
- Friday, December 5 (last day of classes):
LATE PROGRAMS WILL NOT BE ACCEPTED.
- EXTRA CREDIT: Early programs
will receive a bonus of 4% per day -- unlimited. For example, if
you demo the lab by Fri, 11/21 (i.e. 14 days early),
you can gain 14*4%=56%! 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 zero points, and 56% of zero is, well, zero.
You may choose either the database lab detailed below, or, if you wish, propose your own.
- Store your database in memory in an ArrayList. Do not read or write data to the disk except as detailed below.
- Organize your program so that the GUI Frame contains only user interface code. That is,
put all the database handling code in classes you write yourself.
- File I/O
- Present an easy to use, easy to understand user interface - use Menus for Save and Load.
- When the program starts, read the contents of the database from a file into memory.
- *When the program quits, write the contents of the database
from memory to that file.
- **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.
- Database manipulation
Allow the user to:
- display the current database in a TextArea.
- add or delete a record
- *view and change individual records. This would be a reasonable place to open another frame for them to do the editing in.
- **sort the databases, both alphabetically and some other way that makes sense
Standard assignment: WU registration
- Manage a list of courses -- each course has:
- Capacity: how many seats there are in the class and how many are remaining
- Title: e.g. THTR 491-01 (.50)
- Day: when it meets
- Time: what time it meets
- Provide some way for the Registrar to:
- Add courses to the list of courses
- Remove courses from the list of courses
- edit items. I.e.
to change an courses's name, title, capacity, etc (to correct errors).
- Display lists of courses (alphabetically (by title) and some other way that makes sense)
Extra credit features
- Add the capability for a user to request of list of courses the meet at a particular day/time (like: MWF 01:50p-02:50p), or day.
- Display courses in a particular major
- Display 1/2 credit courses (1/4 credit courses)
- Display courses by a particular instructor
- Allow a student to select courses; tell them if any overlap - allow them to register (i.e. reduce the number of seats in those courses)
A tennis (or other competition) tournament simulation
Simulate a seeded, single elimination tennis tournament (or basketball, or
soccer, or whatever). You have more latitude in a tournament simulation than in the fridge 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.
- Simulating a match. To simulate a match, simulate sets until one player has won 3.
- 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.
- To simulate a game, simulate points until a player has at least 4 and is at least 2 points ahead.
- To simulate a point (finally!), use the following algorithm (or another that you find more suitable):
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.
- 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.
- 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.
- 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
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!
- Data files -- Sample data file is here
- Use menus for Save, Load, Edit, etc as needed.
- use Combo boxes, for the courses to be added, deleted, or edited
- Use additional Frames or Dialogs for editing (or JOptionPanes! google "java tutorial JOptionPane)
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.
- Attempt to analyze the code -- by staring at it and thinking.
- Insert output statements -- to discover the values of variables.
- Use the debugger -- as above but an order of magnitude faster.
- Do an experiment -- to figure out what's happening.