CIT 590/591 Assignment 10: Flashcards
Fall 2012, David Matuszek

Purposes of this assignment

General idea of the assignment

You have probably used flash cards to help you memorize something. They have a "question" of some sort on one side, and an "answer" on the other. You use them by looking at the question, trying to remember the answer, then turning the card over to check your memory. If you were trying to learn the multiplication table, a card might have 6 x 9 on the front, and 54 on the back. Or, if you were trying to learn the U.S. state capitals, a card might have Pennsylvania on the front, and Harrisburg on the back.

Your assignment is to write a program to let you work with a set of "digital" flash cards. There will be two separate classes with a main method: A class named Study, used for learning the cards, and a class named Build, for creating the cards. Each main class will have its own GUI, and you can run the program starting in either class, depending on what you want to do.

Detailed specification

Studying

Basic functionality

When the program starts, it needs to read in all the cards, along with information about how well the card has been learned, and when it is next scheduled to be displayed.

When you are studying flashcards, the following sequence of events occurs repeatedly:

  1. The program presents a question.
  2. You try to think of an answer, then hit a button labeled  Show Answer .
  3. The program displays the correct answer.
  4. You click on one of the following three buttons:

There should be some way to quit the program. For example, the user might decide ahead of time how many cards to study, or study until some goal is reached. If the user closes the window, this should also quit the program, but it shouldn't be the usual way to quit.

The program needs to keep track of how well each card has been learned, and schedule it appropriately. If the user said a card was "difficult," it should be presented again fairly soon; if "easy," it should be a longer time before the user sees it again. Use the following scheme:

When the program ends, save all the card data to a file, so that the next time the user runs the program, they will continue their studies just as if they had never quit. This file will be read in the next time the user runs the program.

Extra functionality

Debugging is a lot less fun than adding features to a program. However, responsible programmers make sure their programs work correctly before they add frills. After all, which would you rather drive--a car with a great stereo system, or one with reliable brakes?

That said, there are some things that you can do to improve the program. Some people don't like taking their hands off the keyboard, so you could provide keyboard equivalents (such as Enter, e, m, and d) for clicking buttons. The program can be made more interesting by providing some measure of progress (cards studied, cards learned, etc.)

Your program will be graded on basic functionality first. If everything seems to work correctly, and if whoever grades your program thinks you did an especially good job, you may get a small amount of extra credit. This will be wholly subjective--if the grader likes your program, he or she may award some extra points; but only if the program is otherwise error-free.

Creating and editing flashcards

Basic functionality

Just as important as studying the cards is creating them in the first place. Here's the absolute minimum that the Build class has to do:

Your program should do basic consistency checking. Two things in particular to watch out for: Don't allow any cards to have a blank question or a blank answer; and don't allow two cards to have the same question (duplicate answers are okay, though).

Extra functionality

I've listed this as an "extra" because it isn't necessary if only one person will ever use the program, but treat it as a requirement. It should be easy enough to do.

The comments about extra functionality for the Study class also apply here. Debug your program thoroughly before adding frills.

If you get this far, though, one really nice feature to add is an Undo capability. This can involve a surprising amount of extra code, so don't tackle it lightly.

General advice

You and your partner will both need to read in and write out a file of cards, so this should be shared code, in a separate class.

A fundamental decision to be made is whether to keep the file of cards as a text file, or as a binary file. A binary file is somewhat easier to write out and read in, but a text file is humanly readable. In most cases I prefer the flexibility of a plain text file, but the decision is yours.

When deciding how to format the card file, remember that the "scheduled time" doesn't mean anything unless you know what time it is "now."

This program divides fairly neatly into two parts, with some shared functions (such as I/O). Nevertheless, as usual, you and your partner will receive the same grade on the program, so work with your partner to make sure everything is correct.

Follow the MVC pattern! The GUI is your Controller, manipulating the cards, but also acts as a View. The Model accepts commands from the Controller, acts on them, and makes the results available to the View. The Model does no I/O, either to the GUI or anywhere else; it just quietly does what it is told to do.

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.

Grading

It would be a good idea to read How Assignments Are Graded, but here's a summary: Do exactly what the assignment says to do, use good programming style, test your program carefully, zip up your program (if it's more than a single file), and turn it in via Blackboard. Late programs will lose points.

Due date

Your program is due before