Mr Ashim

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 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 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 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.