CSCI 180 Project Grading   Your project is graded based on four categories: correctness, assignment requirements, documentation, and style. Below are the point breakdowns for each of these areas, detailing the range of points you will receive for achievement levels within each of these categories.   Functionality Note that you cannot receive the minimum functionality points for a level unless your code fulfills the requirements for that level. So, for example, if you do not fulfill the C-level requirements completely (with minor errors), the highest grade you can receive is a 39 no matter what other features you have put into your code.   60-70       50-59         40-49         30-39         0-30   Code compiles and runs without crashing. Fulfills the A-level requirements. Variant points based on quality of minor flaws in correctness.   Code compiles and runs without crashing. Fulfills the B-level requirements. Variant points based on discussion of issues arising in reaching the next stage of the project and in how easy it is to determine the correctness of the code by running it.   Code compiles and runs without crashing. Fulfills the C-level requirements. Variant points based on discussion of issues arising in reaching the next stage of the project and in how easy it is to determine the correctness of the code by running it.   Code compiles and runs without crashing. Fulfills D-level requirements. Variant points based on discussion of issues arising in reaching the next stage of the project and in how easy it is to determine the correctness of the code by running it.   Code does not compile or code crashes when run. Variant points awarded based on quality of analysis of the problem with the code.   Assignment Requirements   5 Handed in on time, code has some documentation, and you included a journal (as described in assignment). The journal includes comments about tasks and issues you encountered and describes how you tested the project. 3 Assignment is on time, code has some documentation, the journal is completed, but a bit sparse but seems like you wrote it as you went. 2 Assignment is on time. The journal may be a bit sparse or it may be obvious that you wrote it after the fact. 1 The code might be undocumented, or you may not have turned in a journal. 0 There was an assignment? Oh yeah, here it is. Oh, a journal -- can I still do that? It is obvious you need to spend more time reading about deadlines and what is included when you hand in your work. Documentation of Code   During this course, I will frequently award points for documentation as follows (up to 2 points for each item):   • documentation at top of file including name of file, your name, and date • description of class (top of file) • documentation on each public method including parameter and return tags. • interior docu.

1. CSCI 180 Project Grading
Your project is graded based on four categories: correctness,
assignment requirements,
documentation, and style. Below are the point breakdowns for
each of these areas, detailing the
range of points you will receive for achievement levels within
each of these categories.
Functionality
Note that you cannot receive the minimum functionality points
for a level unless your code fulfills
the requirements for that level. So, for example, if you do not
fulfill the C-level requirements
completely (with minor errors), the highest grade you can
receive is a 39 no matter what other
features you have put into your code.
60-70
50-59

2. 40-49
30-39
0-30
Code compiles and runs without crashing. Fulfills the A-level
requirements. Variant
points based on quality of minor flaws in correctness.

3. Code compiles and runs without crashing. Fulfills the B-level
requirements. Variant
points based on discussion of issues arising in reaching the next
stage of the project and
in how easy it is to determine the correctness of the code by
running it.
Code compiles and runs without crashing. Fulfills the C-level
requirements. Variant
points based on discussion of issues arising in reaching the next
stage of the project and
in how easy it is to determine the correctness of the code by
running it.
Code compiles and runs without crashing. Fulfills D-level
requirements. Variant points
based on discussion of issues arising in reaching the next stage
of the project and in how
easy it is to determine the correctness of the code by running it.
Code does not compile or code crashes when run. Variant points
awarded based on
quality of analysis of the problem with the code.
Assignment Requirements
5 Handed in on time, code has some documentation, and you
included a journal (as described

4. in assignment). The journal includes comments about tasks and
issues you encountered and
describes how you tested the project.
3 Assignment is on time, code has some documentation, the
journal is completed, but a bit
sparse but seems like you wrote it as you went.
2 Assignment is on time. The journal may be a bit sparse or it
may be obvious that you wrote
it after the fact.
1 The code might be undocumented, or you may not have turned
in a journal.
0 There was an assignment? Oh yeah, here it is. Oh, a journal --
can I still do that? It is
obvious you need to spend more time reading about deadlines
and what is included when
you hand in your work.
Documentation of Code
During this course, I will frequently award points for
documentation as follows (up to 2 points
for each item):

5. • documentation at top of file including name of file, your
name, and date
• description of class (top of file)
• documentation on each public method including parameter and
return tags.
• interior documentation for code that may be hard to
understand
• documentation gives the big picture relating the code to the
task, not micro "this line sets
a value"
Naming
Up to 10 points awarded, as follows (up to 2 points for each
item):
• lowercase starting letter on methods and variables
• uppercase starting letter on classes
• names suggest use of variable
• names suggest action of void method
• names suggest result of value- returning methods
You could lose all 10 points for not using names of methods,
classes, and files specified in the
project assignment.
Code Structure / Style

6. Please note that efficiency is of little concern to me initially,
but gains importance as you learn
more programming. Each of the items is awarded 1 point in the
rubric:
• line lengths reasonable (80 or less)
• methods are not too long
• if possible, blocks of code are not repeated
• whitespace/indenting used to increase readability of code
• local variables used where appropriate (rather than only
fields)
CSCI
180
Spring
2014,
Project
1:
Chatter
Due: Friday, March 14 at 11:59 pm
In this project, you’ll extend the SupportSystem project from
chapter 5 to create Chatter,
a program that converses with the user. This is in the spirit of
ELIZA, described by
Joseph Weizenbaum in 1966. ELIZA was designed to mimic a
psychiatrist conversing

7. with a patient.
It is important to start early and ask questions often. And
remember that, unlike the
homework, this is individual work at the code level. From the
syllabus: You are
permitted to discuss general concepts with other students but
cannot share code or
algorithmic solutions. Violation of this could result in a 0 on
the project for you and your
collaborator. You are encouraged to ask questions of the
instructor in class or out of class
about the project.
You should complete the code in order from D-level to A-level.
You cannot get credit
for A-level work unless the earlier levels are working. See
projectRubric.pdf for a guide
as to how I will grade projects. You will need to create a log
for this project (see
Deliverables at end).
D-level functionality
Implement a basic program that always just repeats what the
user typed in. So it should
prompt the user for a string and respond with the same string.
Use the TechSupport
system design from chapter 5 but call your project project1. It
is best to start from
TechSupport2 instead of TechSupport-Complete. Your
equivalent to the
SupportSystem class should be called Chatter. All manipulation
of the input string
should take place within the Responder class. Chatter should
function basically the

8. same as the SupportSystem class with the following exceptions:
• The input loop should end when the user enters a string that is
specified by the
Responder class (so you would get that string by calling a
method called
getEndingString() on the Responder object).
• The printWelcome and printGoodbye methods within Chatter
should
call methods from the Responder class to produce the desired
messages.
C-level functionality – (note that you must have received most
of the D-level points
to be eligible for C-level points)
D-level with the following modifications:
Chatter should prompt the user for an input string and output an
appropriate response
based on a word in the input. Choose a theme or persona for the
conversation. For
example, you might assume that the conversation is about
meals, so some example word
and response pairs might be: [“dinner”, “Tell me more about
what you ate.”], [“like”,
“What is your favorite food?”]. You should include at least 10
pairs.
• You should not need to modify the Chatter class from D-level
functionality.
• Instead, the method in the Responder class which provided the

9. echo of the input
string should now produce a response string. Use a HashMap
within the
Responder class to store the words and their responses so that
more words can be
added later.
• When searching for a word in the input, make the search case-
insensitive. Thus, a
search for "excuse" would match whether it was “Excuse” or
“excuse”, for
example.
• When searching for a word in the input, ignore commas,
periods, semicolons, and
parentheses. Thus, a search for "excuse" would match whether
it was “excuse,”
“excuse.” or “(excuse)” for example.
• If no matching word is found, the Responder should respond
with a random
default response (see Tech-support-complete for how to do this
but do not use
those responses).
B-level functionality – (note that you must have received most
of the C-level points
to be eligible for B-level points)
C-level plus the following:
• Prompt the user for his/her name and randomly insert that
name into the responses
at the beginning or end of the response (alternating each time)
in approximately

10. 50% of the responses.
• Have the system allow the matching of multiple words in one
input string. If
multiple words are found, the responder should randomly
choose one of the
matching responses.
• Modify the system so that it can handle multi-word phrases.
The modification
should be general enough to allow it to handle any length
phrase. (Hint: loop
through the map keys.)
A-level functionality – (note that you must have received most
of the B-level points
to be eligible for A-level points)
To the B-level functionality, add at least one additional feature.
The feature should be
non-trivial and should indicate some effort. If you have an idea
and are not sure, clear it
with me first. Examples include:
• Modify your system so that patterns are recognized in input
strings and used in
the responses. So, for example, if the input string is “I like
green eggs and ham”,
the Responder would recognize the “I like something” pattern
and say something
like “Is green eggs and ham your favorite meal?” Include at
least 5 patterns.
• Keep track of how many times someone has used each key

11. word and make an
appropriate comment when count reaches a certain number.
Notes on Style
See the style guide posted on our book site. Approximately 25
percent of your project
grade will be based on coding style, including documentation.
Generally I will divide this
into an assessment of
• documentation -- the comments and specifications for your
code.
• naming -- quality names that make your code more self-
documenting. If any of
the names are specified in the project description, you must use
those names!
• code structure -- the structuring of the code itself: line and
method lengths,
indentation, whitespace, clarity of code, efficiency of code.
(Efficiency is not a
big concern early on.)
Deliverables -- what should you hand in?
• Each time you work, please make a note in a programming
log. The log is
intended to help you and I analyze your behavior over time --
noticing where you
spend time or have problems, and to help me give you advice on
your process as
well. You will not lose points for what may seem to be
questionable practices, but
you will lose points for not providing the log. Your entry each
time should

12. include date, how long you worked, what you worked on, what
problems you
encountered, how you got around the problem, why you stopped
working. You
don’t need to be too wordy but include enough detail so I can
understand your
process. Also talk about how you have tested your code. Turn
in this
programming log with your code. A Word doc is fine for this.
• Your documented code. Include all .java files from the
project.
Everything should be submitted in Canvas by March 14, 2014 at
11:59 pm unless you are
using one of your late days.