CIT 590 Assignment 10: Flash Cards II
Spring 2009, David Matuszek

Purposes of this assignment

General idea of the assignment

In Assignment 2 you wrote a Flash Cards program in Python. This will be similar (not identical), but done in Java with Swing GUIs.

In this assignment there will be two classes with a main method, and each of those classes will implement a separate GUI. The user wishing to study will start from one of the "main" classes; the user wishing to create or edit a study list will start from the other.

Terminology: The stimulus is what is presented to the user; the response is what the user is expected to provide. These are more general terms than "question" and "answer." I am using item to refer to the contents of a single flash card, that is, the stimulus together with the desired response.

Details

The study GUI

When the user is trying to study, here's what should happen:

  1. The program reads in the requested study list.
  2. For each item in the study list,
    1. The program displays the item's stimulus.
    2. The user enters a response into a text field.
      1. If the user's response is correct, the program goes on to the next item; but
      2. If the user's response is wrong,
        1. The program does something to get the user's attention (for example, play a sound, or flash something, or turn something red).
        2. The program displays both the user's (incorrect) response and the correct response.
        3. The user has to type in the correct response.
          • If the user mistypes the response, s\he has to try again until s\he has entered it correctly.
  3. When the user has responded to all the items in the list, the list is shuffled "slightly"--that is, items in the list should end up close to where they were originally, possibly a bit earlier or possibly a bit later in the list.
  4. Return to step 2.

The user can quit the program at any time. There should be a button or menu item provided for this purpose; in addition, simply closing the GUI window should quit the program.

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, from the input data file, a fairly small number of items to use (15 or 20; make this number a single final variable) and ignores the rest. This is so you can have a study list of a thousand items, and the user does not have to learn all 1000 at once. However, if there are fewer items than desired on the input file, use as many as there are.

Each stimulus and each response should be trimmed, using string.trim(), 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. The GUI should display the items and provide four basic operations on the list:

Plus, of course, you will need to be able to read in the study list, and write out the modified study list.

Program organization

Separation of GUI classes and model classes

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 file 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. StudyList does not interact with the user; if, while writing the StudyList class, you feel the need to interact with the user, one way is to throw an Exception, and let the GUI class catch it and do the interaction.

Exceptions should not cause program termination.

The GUI classes

class StudyGui

class ListEditorGui

The model classes

class Item

Each Item represents one stimulus/response pair. Each Item should have a way of viewing and changing 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 the model 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: constructors, method names, and parameters. Work together as much as you can, including helping each other with GUIs as necessary.

If for some reason you do not have a partner for this assignment, omit the ListEditorGui. You can construct test files in your favorite text editor.

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, December 3, before midnight, via Blackboard. Please submit one zip file containing all necessary files.