fallwoing is the textbook
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
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
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 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 Respondershould 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
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 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
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.
Click Here To Get More on This Topic......
No comments:
Post a Comment