CIT 591 Assignment 7: Memorization Helper
Fall 2003, David Matuszek

Purposes of this assignment:

General idea of the assignment:

People often have to learn pairs of things that go together (in psychological jargon, paired associates). Given one of them (the stimulus), the person has to come up with the other (the response). For example:

As your customer, I want a program to help me memorize lists of things--for example, German vocabulary words. In addition, I want the program to help me construct these lists in the first place.


The study GUI:

When I am "studying," here's what I want to see:

  1. The program displays the stimulus (for example, "mountain").
  2. I type in the response into a text field.
    1. If I get it right, the program goes on to the next pair; but
    2. If I get it wrong,
      1. The program leaves my response visible, and tells me the correct response.
      2. I have to type in the correct response.
      3. If I mistype the response, I have to keep trying until I type it correctly.
      4. When I type the correct response, the program goes on to the next pair.
The program should do something to get my attention when I make an error (for example, turn something red).

I can quit the program at any time, and the program saves my partial results to a file. If I start it again later, it remembers how well I've learned each pair.

If I run out of pairs (I've learned everything), the program tells me so and quits.

Behind the scenes (studying):

The program keeps track of how many times in a row that I have gotten each item right. It considers that I've learned a pair if I get it right three times [careful: magic number] in a row. Hence, every pair has an associated number 0 to 3, meaning (approximately) how well I've learned it: 0 is not learned at all, 3 is fully learned.

At the beginning of a study session, , the data is read in from a file. Each item on the file consists of three parts: the stimulus, the response, and the count of how many times in a row the user has gotten the item right (initially zero). At the end of the study session, the (updated) data is written out to the file again. No file I/O goes on during the study session.

Regardless of how many item pairs there are, I want to study a maximum of 20 items at a time [another magic number]. There is an array of twenty pairs, initially filled in from data on a file. The program just cycles through these pairs, presenting them to me one at a time. Each time I "learn" an item, it is removed from the array, and that item is replaced with another one from the file. If there are no more items in the file, the number in the array gradually shrinks to zero.

The list creation GUI:

In addition to helping the student study, the program should help the user build lists of paired items. There are two basic operations that should be implemented:

Suggested program organization:


Obviously, each stimulus/response/count item should be an object. Let's call this an Item. Each Item should have a way of editing its stimulus and response parts (getter and setter methods should be good enough for this), and updating its count. As I've sketched the program so far, a correct response adds one to the Item's count, and an incorrect response resets the count to zero--but I might change my mind on this. So, instead of getter and setter methods for the count, I would provide a method for updating the count when there is a correct response, and another method for updating the count when there is an incorrect response.


I would have a single class (probably called StudyList or something similar) that does no printing or GUI work--it just keeps track of data. Data consists of all the Items from the file, and an array of those items (max 20) currently being studied. This class would have (at least) the following methods:

For the StudyGui:

For the ListEditorGui:

By the way, you probably want to look at the java.util.Vector class. A Vector is like an array (without the nice array syntax), but you don't have to know ahead of time how many items it will hold; it just gets bigger the more items you put in it. Since you don't know ahead of time how many Items are on the input file, a Vector is the perfect place to keep them.


I would have a separate class to build the GUI for the user. The listeners for this class would interact with the StudyList to run the presentation.

The GUI also needs to provide a way to bring up the ListEditorGui. In fact, I would suggest being able to do this in two separate ways: one for general list editing, and the other that brings up the GUI in a state where it is displaying the current Item (because this is the one the user is likely to want to edit). For example, you might have Edit List and Edit Item buttons.


I would have a separate class to create and edit the StudyList. It should be able to add and edit items in the StudyList. In order to edit items, it must be able to find them, so some sort of a search capability seems like a good idea--but maybe the search method should be in the StudyList class. It would also be nice to just be able to step through all the items.


Each member of your team should do one of the GUIs, and to specify (with the @author tag in the class) who did each GUI. Your grade will be based 50% on your part and 50% on the whole thing.

This is a team programming assignment. It's not quite a pair programming project, because each of you is responsible for part of the code, and both of you are responsible for part of it. However, the program has to work. Programs that don't work are worth zero points. So in order to get credit for your GUI--not only the layout, but also the work it does--the program as a whole has to work.

Since the StudyList contains some methods that will mostly be used by the StudyGui and others that will mostly be used by the ListEditorGui, you might want to divide up the work along these lines.

I recommend that you spend the lab period deciding who does what parts, and making a very specific outline of class responsibilities (suggestions given above), constructors, method names, and parameters. Work together as much as you can, including helping each other with GUIs as necessary.

Due date:

Thursday, November 13, before midnight. Again, please submit one zip file containing all necessary files.