This assignment is due at the beginning of class on 29 September, though you are of course welcome to turn it in earlier. Please turn this assignment in by bringing a paper copy to class o the 26th or by emailing either a plain text file or a url to 6.096-staff@mit.edu.
Because there are no classes on Monday, 22 September, there is neither a laboratory meeting for nor a programming component to this project. In fact, this assignment only asks you to design specifications, not to write working code. We specifically want you to think about how things are put together rather than about how they work.
This assignment involves two design problems. On the first part of the assigment, you can (and should) discuss your design with other students. You may work closely to spec out the design. You should each write up your design independently, though you may exchange and comment on one another's designs before turning them in. For the second design, you should try to design the system independently. You may refine your design by having others comment on what you've written (this is generally good practice, and even has a name: code review), but you should turn in both your original, independent design and any modified design you may come up with as a result of feedback from your classmates or others.
The purpose of this project is to give you experience in designing a system of computational objects. We will describe in some detail the system that you should design. Your job is to refine the description that we give, below, and to translate the ideas expressed here in English into a template Java program. We expect you to fully specify the classes, fields, and method signatures which comprise your system. The bodies of methods -- the actual working code -- may be omitted. However, all of the classes, fields, and method signatures that you write should be fully documented, so that it is possible for us to tell how your code is intended to work and how the pieces of your code would interact. These comments should include English descriptions of the logic that you would expect the code to follow. You should also give an excerpt from code that creates and interacts with the specification you design.
Your first job is to design a system of computational objects which together constitute an alarm clock. Your code specification should support:
You may assume a 12-hour digital clock. You are not responsible for defining a graphical user interface, simply for providing the "smarts" behind such an interface. You may make any assumptions you wish about the available interface or objects, but you must thoroughly document these assumptions. In general, your assignment will be judged on the thoroughness of your specification and your documentation, rather than on any method implementations you actually devise.
You should ask yourself the following questions, and your write-up should include answers to each of these:
You may wish to consider, but are not required to handle, any of the following extensions to the basic alarm-clock behavior. You may also come up with any extensions of your own.
For the second design, you should return to the description that you wrote in the first assignment (written exercise) and design a system of interacting objects to implement the thing that you described to your martian pen pal. If you feel that you cannot -- or do not want to -- design the system that you wrote up, you may select another artifact or process of your choosing to model. Some additional descriptions are available online, or you may invent a new one of your own. In any case, you should turn in a copy of your (possibly modified) description along with your system specification.
There should be two parts to your design for each of the design projects: the alarm clock and the free design problem. The first is for the user of your class(es). This documentation should specify what your object types are and how they are to be used. This should read something like a user's manual for your object(s). You may also wish to include in this section any hooks that may be available for extending your object(s).
The second, and more extensive, piece of documentation describes the details of your design, e.g., for a future implementor. For this section, you should turn in a complete listing of the object types (classes) that you define, including for each a complete list of fields and methods.
For each class, you should provide documetation indicating what role instances of the class are supposed to play and how they are intended to be used. You should describe the state of instances at the time that they are created as well as how they are expected to evolve over time.
For each field, you should describe its purpose, its visibility (e.g., public or private), and any relevant information about its initial state or evolution. If it is not clear, you should mention which methods change its value.
For each method, you should specify the argument and return types as well as the relationship between them. You should also list what the method does and, if it interacts with the object's fields or other methods, detail these interactions. You do not need to write code for the method bodies, though your documentation should make it clear what this code would do.
When one class relies on another, you should specify these interdependencies.
For objects that are self-animating, you should describe their autonomous activity.
For the individual design project, you should also turn in the English description of the system you've designed. If you revise your design based on feedback from other people (an excellent idea), you should turn in both the original and the improved design.
Finally, you should include information on your collaborators and their roles.
This course is a part of Lynn Andrea Stein's Rethinking CS101 project at the MIT AI Lab and the Department of Electrical Engineering and Computer Science at the Massachusetts Institute of Technology.
