CIT 590 Assignment 9: Paired Associate Learning
Spring 2009, David Matuszek

Purposes of this assignment:

• To get you started with with GUIs
• To give you more experience with JUnit testing
• To give you some experience with file I/O

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:

• What's Dr. Dave's phone number? (stimulus: Dr. Dave; response: 8-8122)
• What's the capital of Pennsylvania? (stimulus: Pennsylvania; response: Harrisburg)
• What's the German word for mountain? (stimulus: mountain; response: der Berg)
• What do you get when you multiply six by nine? (stimulus: 6 * 9; response: 54 (or 42 for HHG fans))

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:

• A program to create and edit lists of paired associates, and
• A program to help the student learn the paired associates.

Details:

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:

• Add a new item (stimulus/response pair). However, no two items can have the same stimulus (for example, you can't have [German] stimulus "klein" with response "small" and "klein" with response "little." If this happens, you have to ask the user what to do. (It is OK for two different stimuli to have the same response, though.)
  
  
• Find an item, given either the stimulus or the response.
  
  
• Edit an existing item (because errors do happen and need to be fixed).
  
  
• Delete an existing item.

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

• Has a Load command to read in a file.
• Controls the display of items to the user.
• Has a Quit command.

• Has controls to Load, Save, and Save As... files.
• Has controls to Add, Find, Edit, and Delete items.

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.

Grading:

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:

• Project name: PairedAssociateLearning
• Package name: package pairedAssociateLearning
• Class names and method signatures:
  • class StudyGui extends JFrame
    • public static void main(String[] args)
      
      
  • class ListEditorGui extends JFrame
    • public static void main(String[] args)


  • class Item
    • Item(String stimulus, String response) // constructor
    • public String getStimulus()
    • public void putStimulus(String stimulus)
    • public String getResponse()
    • public void putResponse(String response)
      
      
  • class StudyList
    • public void add(Item item)
    • public Item find(String stimulusOrResponse)
    • public void delete(Item item)
    • public void modify(Item item, String newStimulus, String newResponse)


    • public void load() throws IOException
      • Calls the load method in SimpleIO, and catches any Exceptions that are thrown.
    • public void save() throws IOException
      • Calls the save method in SimpleIO, and catches any Exceptions that are thrown.
    • public void load saveAs() throws IOException
      • Calls the saveAs method in SimpleIO, and catches any Exceptions that are thrown.
    • For any Exceptions you catch, put up an informative Message Dialog to tell the user what happened, then keep going (don't stop the program).
      
    
    
  • class SimpleIO (provided)
    • public static ArrayList<String> load() throws IOException
      • This method will read in lines from a file, and return an ArrayList of those lines. It is your job to break each line up int a stimulus and a response. The method line.split(" *\\|\\| *") will break line into an array of those two Strings.
    • public static void save(ArrayList<String> lines) throws IOException
    • public static void saveAs(ArrayList<String> lines) throws IOException
• Provide JUnit tests for all methods in Item and StudyList.
• Provide Javadoc documentation for all classes and methods, except JUnit tests
  • Document JUnit tests if they are complex or do something non-obvious
• Name to use for Blackboard: PairedAssociateLearning_yourName_partnersName

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.