CSE143 Winter 2003

Project 1

Shopping for Luck  

A Continued Experiment in Computational Theology

Due dates: Part A (electronically): 9:00 pm Friday, Jan. 17, paperwork in quiz section Tuesday Jan. 21; Part B (electronically): 9:00pm Wednesday, Jan. 22; paperwork in section Jan. 23.  ["Paperwork" as always means the printed electronic receipts, plus any written material (questions, diagrams, etc.) that might have been assigned.  Staple all such material together, please.]

Overview

Your previous experiment in Computational Theology proved that the gods of luck can be fickle indeed.  Fortunately, there are other oracles than can be consulted.   Take a comparison-shopping tactic. Try each of several oracles a couple of time, and go with the best result from each of them.  Your luck is bound to be good according to one of them.

An oracle takes your question and poses it to the deities, and interprets the answer.  The answer, or result, we shall call an omen.  In the case of the gods of Luck, the question consisted of your initials, and the omen was the number of tries it took to match your initials.

At the local Mall of the Gods, there are a variety of temples where you can consult an oracle. 

• Of course, the gods of Luck have a temple there, and you don't want to write them off.   Their service is exactly as before (two uppercase letters).
•  Next door is their cousin, the Lucky Occurrences Counter Oracle.  This oracle will inform you how many times your request is found in 1,000,000 attempts to match it.  The higher the number, the more favorable the oracle.  As with Luck Tester, the request must be a pair of uppercase letters.  The rules for checking and counting are the same as for the Luck Tester: characters are generated and tested in pairs.
• Upstairs, seemingly on a higher plane, is the Text Search Oracle.  There you can find out whether your request appears in a mystical text known only to the oracle.   It will deliver that line back to you so you can meditate on it.  This oracle will always give the same answer to the same question. Unlike the other oracles, it accepts a string of any length (non-empty), and performs its matching without respect to case.  (Sacred text courtesy of Project Gutenberg).

Task: Implement a program which takes a string (the request) from the command line.  The string is presented three times each to the three different oracles.  The result of each trial is briefly reported, and the trial which is most favorable is reported in possibly more detail.

The task is structured to give you practice with implementing interfaces, and using objects which implement the interfaces.  There will also be continued practice with arrays, strings, and packaging.

This specification is not complete by itself.  You will need to read all the supplied code carefully, especially the comments.  You should also refer back to the Project 0 description for general background.

Starting Code

All code, unless otherwise noted, belongs in a package named project1.  To avoid Bluej problems, you are encouraged to create the directory and place files in it before creating your Bluej project.   Don't let Bluej "fix" anything.

A P1Main class invokes the three oracles and reports the results.  You will not be able to turn in a modified version of this .java file.  Study it carefully, however, for clues about completing the assignment successfully. (Re-posted with correction 1/15).

An interface IOracle is defined, with methods that every oracle must implement.  Likewise, there is an interface IOmen for the omens returned.  You won't be able to turn these files in, but they are crammed with useful comments.  Each oracle type has its own unique omen type.  Because the oracles are invoked in main, their names are baked into the program, and unfortunately can't be changed.  The oracles, each of which you must implement as a class in a separate .java file, are LuckTester,  LuckyOccurrenceCounter, and TextSearcher. For each oracle, implement an omen class; names of the omen classes are up to you, because they do not occur in any of the supplied code.  There is a TextSearcherUtils class containing one method to read a file (you can't change or turn in this file); a brief starter class for TextSearcher is given to show how to use that method.  Text Searcher reads a sacred text which must be downloaded and copied into your project (try putting the file in the project1 package directory.  If this doesn't work, place a copy in the directory above.)

In additional, there is a partially implemented class called Utilities.  It contains an uncompleted method used by the main class.  For your program to work properly, implement that method and turn it in.

You can (and probably should) use any of the code you wish from the sample solution to Project 0 (see the main Homework page).

Written part

• I. Your finished project will involve a number of classes and interfaces (given to you or that you create).  Think far enough ahead to figure out whether you need an additional classes, and what all the class names will be (including classes you define.)  Draw a diagram to show the relationships between them all.  Do not include any standard Java classes in the diagram.  Use notation similar to that in the lecture slides, textbook, and in the Bluej classes window.  It's fine to draw it freehand (no extra points for doing it on the computer!)
• IIA. Here is a list of standard Java library classes you may have used.  Whether you are familiar with them (yet) or not, look up each one in the Java documentation, and find out what interfaces it implements, if any.  This is a bit trickier than it sounds, because class A might extend class C, and class C might implement some interfaces, and so forth -- all such indirect interfaces should be included, as far back as you can trace it.
  • Color
  • ArrayList
  • Integer
• IIB. For each interface that you locate and list in IIA, tell what package it is in.  Package names should be fully qualified in answering exercises like these.  For example, class Color is in java.awt -- don't just give your answer as "awt".
• III. Study the sample solution to CharGenerator.java.  The keywords static and final are used in that code. Are they used everywhere possible?  Without modifying anything else (at all!), add static and final everywhere possible, such that the file still compiles and such that Project 0 still compiles and runs with the modified version.  Turn-in: non-electronic!  Print a copy of your modified CharGenerater.java and highlight or circle completely every added static and final, so the the changes are easy to see.

Some rules (for this project):

• You may not change the package name [class names or qualifiers, or any method signature (method name, qualifiers, return types, parameters, etc.) are covered otherwise].
• You may not define additional .java files.  See clarification.
• You are free to add methods, constructors, instance variables, etc. or to overload existing methods, if they help you solve the problem.
• This project is to be done by each student individually, with no code sharing or code viewing.

Some advice:

• Keep it simple.  You won't get extra points for being complex or elaborate (although you might win your TA's admiration, or mine!). 
• Read the assignment through carefully, word for word, before beginning to work.
• Before writing any code of your own, study all of the given code, and the sample solution code for Project 0.
• Read the assignment through carefully, word for word, before turning in the program. 
• Continue to use the Message Board to ask questions -- or to answer them if you have something figured out.  Just don't post any actual code, please.
• This assignment will be more time-consuming that the previous one.  Start early.

At this point in the course, a number of style or programming practice issues have been mentioned in class.  You have also seen examples of our code.  Let these be reference points for the style you use.  It is overall clarity, consistency, and ability to communicate to the human reader that matters most, so don't agonize unnecessarily over details that don't contribute to those goals.  (We will at some point ask you to be a bit pickier about details, by the way).

Part A specifics: Turn in all required classes, such that they compile without error on the turn-in server, and such that the resulting program executes without blowing up when run from the command line with the argument "UW".  The program does not even have to produce any sensible output, or really do anything at all!  But it must run to normal completion.  Also turn in written part I with the paperwork for Part A.

Part B specifics: Turn in the classes again, such that the resulting program, executed on our servers, operates correctly in all cases.  The program should never abort, even if garbage input is supplied.