Your final project will consist of a BlueJ project folder containing your entire program, handed in via HSP as usual. Please name your project "final".
You may work alone or with one other person from the class.
The takehome exam will include a question asking you to provide a description of your final project and an "incremental development plan." Take that question seriously, because it will help you get off on the right foot with your project.
At its simplest level, a spell checker is a program that takes input from two files (a dictionary of correctly spelled words and a file whose spelling is to be checked), and produces a list of words from the second file that do not appear in the first file. If you choose this final project, your job will be to write a spell checker.
Your program should ask the person using it to specify a dictionary file and a file whose spelling you want checked. You may assume that the dictionary file consists of an alphabetized list of lowercase words, one word per line. (See /Accounts/courses/cs117/ondich/words.txt for a large example of such a file, but you might want to create your own small dictionary file for early testing of your code.) After the person has specified the files, your program should print out (to System.out) a list of incorrectly spelled words, along with their line numbers. For our purposes, "incorrectly spelled" is synonymous with "doesn't appear in our dictionary file."
That's the minimum spell checker, and if you choose this project, you must write a program that does the job described in the previous paragraph. However, there are many ways to enhance your program (see the Ambition item in the Grading Criteria section below). For example,
Try to think in object-oriented terms. For example, you should have a class that represents the dictionary, with suitable methods for loading the dictionary into memory and searching for words in it. By giving the dictionary class responsibility for the detailed manipulations of the dictionary, you will make the rest of your code easier to read, write, and debug.
You've spent a fair amount of time this term making graphical fish do things. Now that you know a lot more Java than you did before, you're ready to do a more detailed simulation of life in an aquarium. You could, for example, design your Fish class to include data and methods to represent and control the size, type (sharks?), or speed of the fish. You could include a notion of "hunger level," so that fish that get too hungry will die and float to the top of the aquarium (and that hungry fish who encounter smaller fish will eat the smaller fish). You could include a Plant class whose instances randomly generate instances of a Bubble class, which in turn float upwards. Go ahead and use your imagination.
Your simulation can include pretty much any features you can cook up, but it must include:
Does it compile? I can't test it, and thus I can't grade it, if it doesn't compile.
Does it work? Correctness is the most important thing, though by no means the only thing. Your program should work. If it doesn't do exactly what it was intended to do, you should provide a discussion of that fact in your documentation.
Is it well organized? We talked in class a few days ago about principles to use when designing a class. Think about those ideas as you develop your code.
Is it well documented? Your code is a piece of writing directed to two audiences--human readers and compilers. You need to make the code readable to both of them, and clear commenting is an essential part of what you do for your human readers.
Is it written with good style? Descriptive variable/function/parameter names, consistent indentation and placement of braces, and appropriate comments are the fundamentals of good coding style.
Ambition. If two projects are well documented, functional, and exhibit good style, the one that does a more interesting or ambitious thing is likely to get the better grade. A good version of Battleship will probably get a better grade than a good version of tic-tac-toe. An aquarium with fish, sharks, plants, bubbles, and barnacles will probably get a better grade than an aquarium with three fish. On the other hand, a really outstanding tic-tac-toe program can get an A.
Hand in the usual stuff--a BlueJ project folder--with one slight addition. As you know, whenever you create a project, BlueJ automatically generates a README.TXT file. For your final project, I would like you to summarize the status of your program in the README.TXT file. Tell me what your program does, what isn't working, how to use it, what bugs you know of, etc. Anything you want me to know about your program should go in README.TXT.
Start early, have fun, and keep in touch.