Sample Project
CISC 323, winter 2004
This is a sample project which parallels the tasks set for
Assignment 3, 4 and 5. This year is the first year we've done a project in
CISC 323, so we can't point you to projects from previous years as
examples. Instead, we've created a parallel project to serve a
similar function. We hope it will answer many of your questions
about exactly what we want.
This page now contains a complete sample project,
including implementation.
Initial Problem Description: You're working for a company
that has decided to create and market a tool to administer simple
quizzes using computers. The intended customers are students and
teachers at all levels. The intention is to use the quizzes
informally, as a tool for review, not for evaluation. Unlike WebCT
quizzes, there will be no provisions for security (passwords, etc.).
The teacher (or perhaps a student) would
use the program to create or edit a file of questions. The student
would load the file and take the quiz. The program would ask each
question and then report on the results at the end of the quiz. It
would also give the student the opportunity to repeat the questions
that he or she had answered incorrectly.
Preliminary Task: Questions and Answers:
Here
is a list of
questions that you might ask about this problem description to nail
down the specifics of what the program needs to do. The answers are
phrased as if they were written by the someone in the marketing
division of your company, who is responsible for deciding on the
functionality of this new program.
Analysis Task 1: Use Cases
diagram
explanations
Analysis Task 2: Activity diagrams
Design Tasks: In the instructions for Assignment 4, we said that when
you're doing your design you may find things you wish you could
change in your analysis, and that you should supply a list of
these. I made one such change and will explain it here.
As I designed my GUI dialogs for this sample project, I
realized that I'd like to re-organize my use case diagram. It has
editing a question divided into editing the question text, editing
the correct answer, and two more options relating only to
multiple-choice questions. I decided that it felt more natural
instead to have one dialog for each of the three question types,
in which the user could change all aspects of a question. So I wish
I'd divided my "modify question" use case into "modify true/false
question", "modify short answer question" and "modify multiple
choice question". My fourth activity diagram would need to be
changed accordingly.
My design is written as if I'd made these changes in my analysis
tasks. Without this note, a grader would be justified in making a
small deduction because my design is not splitting up editing tasks
in the same way as my analysis.
Design Task 1:
Overall Class Diagram
Design Tasks 2&3:
Individual Class Diagrams & GUI Pictures
Design Task 4:
Sequence Diagram
for editing a true/false question
Design Task 5: Activity Diagrams
I chose to draw an activity diagram for reading a quiz -- the
readQuiz method from the QuizIO class. I found it difficult to
fit a diagram onto one page, so I broke it up into two pieces.
The blue activity on the first diagram is expanded in a second
diagram.
main diagram
diagram for "read rest of multiple choice question"
I left out some details about what's involved in reading a line from
the quiz file, again to keep the size of the diagrams reasonable.
The method should have a line number variable that is initialized to
zero. Every time an activity says "read next line" it means
the method should do the following:
-
read a line from the file
-
if there was no line to read because we're at the end of the
file, throw an exception: unexpected end of file
-
if some kind of I/O error occured (a device failure or some
other reason) the I/O method will throw an I/O exception. This
method shouldn't catch the exception but let it be thrown back to
the caller.
-
increment the line number
Every exception message should include the line number, to help the
user find the error in the file.
Implementation: I have implemented this design, making a few
changes along the way. First of all, here is the program: QuizProgram.zip. You may download it and
look at the code and run it. That's all I would have been required
to hand in.
Comments About the GUI: This is a fairly "quick-and-dirty"
GUI. It's clear and functional, but it's not fancy. I used only
the default colours and fonts. Some of the frames and dialogs don't
look great when you stretch them. In the dialogs dealing with
multiple-choice questions I left spaces rather than adding and
deleting components from the layout. You may do the same in your
implementations. There are no points for prettiness.
Comment About Error-Handling: I tend to have a rather
paranoid style of programming, meaning that I check for errors that
really shouldn't happen. I know I have some redundant
error-checking in the program; for example, when you ask for one of
the choices for a multiple-choice question, the getChoice method
checks the index to make sure it's in range. The GUI always gets
that index from a list selection or from a carefully-written loop,
so this error should never happen. I like to check for things like
this because it helps me track down problems when debugging. It
turns out that when I was implementing the EditMCQuestionDialog I
got one of these exceptions and because my exception told me exactly
what had happened it was pretty easy to track down the bug
in the dialog class which had triggered it.
Without that check, my program would have crashed and given
me much less help in finding and fixing my bug.
This is the way I like to program. We encourage you to think
carefully about error checking, but you don't have to be as paranoid
as I am. What matters is that your program works correctly, even in
the face of user errors. For example, my design has restricted the
number of choices for a multiple-choice question to 10 or less.
If the user attempts to add an 11th choice, the program pops up an
error message and does nothing. Your program shouldn't crash no
matter what the user does.
Notes About the Implementation: As I implemented my design, I
had to make a few additions and changes. As requested for
Assignment 5, rather than going back and changing my design, I'm
listing here the changes I would make. Remember that you don't have
to list methods and attributes you added, but you must list
deletions and changes in parameters.
-
I made a bunch of changes to the dialogs used for editing and
adding questions:
- My design had EditQuestionDialog and three subclasses for
modifying questions, then AddQuestionDialog and three subclasses
for adding new questions. When looking at that with my
implementor's hat on, it sounded like a lot of duplicated
effort. So I eliminated AddQuestionDialog and its subclasses
and used the edit dialogs for both functions.
- I added an extra parameter to the constructors for these
classes: a reference to the quiz being edited.
- Each subclass now has two different versions of the
showDialog method: one gives a question to be
modified, and the other leaves out this parameter, meaning
that you're building a new question.
-
Several dialog classes: I changed the parent parameter to the
constructor to be a JDialog instead of a JFrame
-
ChooseQuestionDialog class: the comments in the details class
diagram for this should be corrected to say that
getQuestionIndex, not getQuestion, returns the index of the
question which was chosen. Also, the picture showed a label
saying "choose a question to delete". Since this dialog is
also used when modifying questions, I changed the label.
-
MCQuestion class: needed methods for adding, removing or
changing a choice, and for changing the correct choice for the
text.
-
Question class: This is an explanation rather than a change. My
activity diagram for giving a quiz implies that I need a way to
mark a question as "correct" or "incorrect". Instead of adding
an attribute to the Question class, I will be maintaining a
Vector of incorrect questions.
-
Question class and subclasses: equals and copy methods were not needed
-
EditDialog and QuestionDialog class: didn't need an actionPerformed, since
they are abstract
-
Quiz class: added clear and shuffle methods
-
QuizIO class: forgot to designate the reading and writing
methods as class methods (static).
-
SAQuestion class: added setAnswer and checkAnswer
-
TFQuestion class: added setAnswer
Order of Implementation: I used an evolutionary approach to
implement this program. To provide you with a concrete example of
this kind of approach, here is a description of the order in which
I implemented the program.
- I started with a minimal set of classes: Quiz, QuizException,
Question and MCQUestion.
I put a simple test driver into
the Quiz class, which I used to do a quick test of these classes.
It created a small quiz with only multiple-choice questions. I
included toString methods in all of my classes, so that my test
driver could print the contents of the quiz.
- Next, I added SAQuestion and modified test driver to add
some short-answer questions to the quiz
- Added TFQuestion and modified test driver to add
some true/false questions to the quiz
- Created QuizIO and wrote readQuiz to read just true/false
questions. Wrote a test driver for QuizIO which reads a
file and echoes it to the screen. Ran the test driver with
a quiz file containing only true/false questions.
- Added code to readQuiz to read short answer questions as
well. Added short answer questions to the test input file.
- Started GUI: created MainQuizFrame. All buttons pop up a "not
implemented" message
- Added logic for taking a quiz. In MainQuizFrame, "read"
button reads a quiz, and the "take" button calls a new
takeQuiz method in MainQuizFrame. Used a "stub" for
QuestionDialog: a concrete class which uses a JOptionPane to
display the text of a question and let the user specify whether they
were giving a correct or incorrect answer or quitting.
- Wrote real code for QuestionDialog and TFQuestionDialog.
MainQuizFrame always pops up a TFQuestionDialog for every question.
Tested with a quiz file containing only true/false questions.
- Added SAQuestionDialog plus logic in MainQuizFrame to open the
appropiate kind of dialog for each question. Tested with quiz
containing just true/false and short answer questions.
- Added MCQuestionDialog and tested with quiz containing all
three types of questions
- Added EditDialog with no actions except returning to main menu.
- Added ChooseQuestionDialog and logic in EditDialog to respond
to the "delete a question" button by choosing a question and just
reporting which question was chosen
- Added code to EditDialog to delete the chosen question
- Added EditQuestionDialog and EditSAQuestionDialog, along with
code in EditDialog to use them to add and modify short answer questions.
- Added EditTFQuestionDialog so you can add and modify
true/false questions.
- Added EditMCQuestionDialog so you can add and modify multiple
choice questions
- Added write method to QuizIO and code to call it from MainQuizFrame
This order isn't the only order I could have chosen, but it worked
well.
Last modified: