Programming Project 2

Due at the beginning of Lab 3

This programming project may be done individually or in groups of two. Keep in mind that you may not work with the same person on more than two of the programming projects. If you work with a teammate, hand in one copy of your code with both names on it. It is okay to get help from the TAs and/or the instructor if you get stuck, but you should try to do it on your own first.

For this project you will implementing a variation of the Robot class in the Talking Robot Lab. Read the Problem Description, Program Specification, and Design and Implementation Suggestions thoroughly before starting your implementation.

Problem Description:

The current robot is operated by a remote control. Two buttons on the remote control represent asking the robot a question and getting the answer. If you press the first button, the robot asks, "What is your question?" The robot, as currently implemented, does not know how to recognize questions. Instead, if you press the second button, the robot gives a randomly-chosen "answer" such as "Definitely!", "OK", or "No way!", without knowing what the question was.

You have been hired by the makers of the robot to help create a new and improved version. Your focus will be to improve its conversational skills by making its choice of answers depend on the actual question asked. The robot will not be able to answer all possible questions (which would be very tough to do!), but it will be able to recognize a small number of predefined questions, like "What's for lunch?", and be able to give a variety of randomly-chosen answers for each question.

Program Specification:

You should come up with at least five questions that your robot will be able to "recognize." You should also come up with at least three possible answers for each question, although you may reuse some answers for multiple questions if they seem appropriate. Since true voice and sentence recognition is very difficult, you will create a "stub" class as a substitute for the voice and sentence recognition part of your robot. This class should have a getQuestion method, just as the real recognition class would, with the following specification:

public String getQuestion()
This method, however, will merely return a randomly-chosen question from your list of five questions, not actually recognize and return a question that a user asked. After your robot asks the "stub" class for a question, it should randomly choose one of the three answers you came up with for that question. You should print out the randomly-generated "recognized" question and also the robot's answer using System.out.println. Finally, to simulate having a conversation with the robot, modify your code so that it will go through the get-a-question, give-an-answer sequence a number of times (at least 4 or 5).

When you are done and your program works correctly, be sure that you have updated the class documentation at the top of each source file and at the beginning of each method. Also update your external user documentation, which should describe the purpose and behavior of your program from a user's perspective. (In BlueJ this is the small document icon in the upper-left corner of your project diagram.) Focus on what the program does, rather than how it does it. In the external documentation and the documentation in each class, remember to include your name and the date as well as the names of anyone from whom you received help.

Print and turn in the external user documentation and the source code for each class you created. You do not need to print the class documentation (or "Interface") for each class, since that information is in the source code and we want to be environmentally responsible.

Design and Implementation Suggestions:

You may wish to use a design similar to the one for the Talking Robot lab, replacing the clock class with your stub for the sentence recognition class.

Identify your five questions, and the three possible answers to each question, before you go further with your design and implementation. Remember that you may reuse some answers, but others should clearly be specific to a particular question.

You may create your program by copying the Talking Robot Lab program and making changes to it, or by starting from scratch. In either case, I recommend that you use the same incremental methods described in the lab, testing your changes at every step. If you start by copying the program from the lab, then make small modifications, one at a time, to "morph" the lab program into this one. If you start from scratch, I recommend that you first implement a class with a trivial main and test it, then make a second class with a constructor and a method and call those from the main, etc. At each step, add a little functionality that gets you closer to your end goal, and test it.

What is a "Stub" Class?

    A "stub" class is a limited-functionality substitute for a real class, developed for testing purposes. Its purpose is to provide just enough functionality so that it can be used to test other classes that would interact with the real class.

Defining and Using Constants

    You should define your list of known or recognizable questions in the stub for the sentence recognition class as a set of constants at the beginning of the class. For example, the following constants could be 2 of the 5 questions that a given sentence recognition class recognizes.

    public class StubClass       // (give your class a better name!)
    {
        public static final String LUNCH = "What's for lunch?";
        public static final String SCHEDULE = "What classes do I have today?";     ...
    These constants should be defined at the beginning of the class, above any instance variables, the constructor(s), or any method(s). The public keyword indicates that objects of other classes (such as the robot) may use the constants. The static keyword indicates that the constants are class variables rather than instance variables; in other words, they are not tied to any particular instance of the voice/sentence recognition class, all objects of the class share them. The final keyword indicates that these identifiers are constants rather than variables; the values assigned to them when they are declared are their final values.

    Within the stub class, these constants can be referred to using just their name, as in

    System.out.println(LUNCH);      // from within the stub class
    Objects in other classes should give their "full name," specifying both the class name and the constant, as in
    System.out.println(StubClass.LUNCH);      // from objects of other classes
    Other examples of constants defined in classes include Color.RED and System.out. RED is a constant Color object defined in the Color class; out is an object representing console output defined in the System class.

    (Note: "StubClass" is not a good name for the stub sentence recognition class because it doesn't indicate what the real purpose of the class is meant to be.)