CIT 590 Assignment 9: Paired Associate Learning
Spring 2009, 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:

This is a version of a program I wrote long ago (and have rewritten several times). Because the main point of this assignment is learning to build GUIs, I have greatly simplified the program by not keeping track of the student's progress. There are two parts to the assignment, each with its own GUI:


The study GUI:

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

  1. The program displays a randomly chosen 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 stimulus.

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.

The program does not remember whether I get items right or wrong, nor does it make any intelligent choices of what stimulus to present next. (This is part of the simplification that I mentioned earlier.)

Behind the scenes (studying):

At the beginning of a study session, the data is read in from a file. Each item on the file consists of: the stimulus, a double bar (||), and the response. For example (English-Japanese):

I want || hoshii desu
I don't want || hoshiku arimasen
now || ima
yes (casual) || ee
at my place || watashi no tokoro de
at your place || anata no tokoro de
you are skilled || jozu desu
I am not skilled. || Jozu ja arimasen.

The program then randomly chooses a fairly small number of pairs to use (15 or 20; should be a single final variable) and ignores the rest. trim() all strings, so that the student does not have to "learn" which words have leading and/or trailing spaces.

The list creation GUI:

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

Program organization:

Division of labor:

The GUI classes, which handle interaction with the user, must do no, repeat no, manipulation of the data in any way. All they do is handle events and call methods in the StudyList class. As far as the GUIs are concerned, they have no idea what their buttons, text fields, and other widgets are being used for.

There are two GUI classes, StudyGui and ListEditorGui. Each has a main method. What the program does depends on which class the program is started from.

The model classes, Item and StudyList, do all the computational work (in this case, all the I/O and list manipulation). They do not access the GUIs in any way. In fact, if the GUIs were removed from the project, this would not result in any syntax errors in these classes.

The StudyList class also acts as an intermediary in any file I/O--if a GUI wants a file loaded or saved, it asks StudyList to do that. If Exceptions occur, the GUI class (not the StudyList class) should display an informative Message Dialog to the user, then continue as if nothing had happened.

The GUI classes:

class StudyGui

class ListEditorGui

The model classes:

class Item

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).

class StudyList

The StudyList class 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 (maybe 15 or 20) currently being studied.


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. Both of you should work together on the model classes. 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.

Structure of the assignment:

The above are requirements. You may have additional classes and methods as needed, and they should be documented and unit tested as appropriate.

Due date:

Thursday, April 2, before midnight, via Blackboard. Please submit one zip file containing all necessary files.