IMPORTANT ADDITION (8/3/2002) -- DOING YOUR PRELIMINARY AND FINAL PROJECTS -- DUE DATES AUGUST 12TH (5% of course credit) and AUGUST 22nd (5% of course credit). Follow this link to the details.
The work on your project that is due at your second meeting consists of the following:
Remember that each student is to furnish their own independent written project report, but the software is a single collection of code, a team effort. But each student must have a copy of the code in a unix directory of their own.
Factory Patterns you are to implement in code for your second meeting: You are to implement an example of the Singleton Pattern and either the Abstract Factory or Builder Pattern for your specific project. Though it may not be apparent or even suitable for inclusion in your project, you are to make up example code for the two patterns, using classes that might appear in your project. The classes needn't do anything substantial, but they should have more substance than my Dogs examples. You will not be required to include these or any other Factory patterns in your final project, if you can argue that they really aren't appropriate anywhere in your project. The new Pattern Resources I have posted might help you.
Of course, we'd be delighted to see any design or code for your project beyond the two Creational Patterns you develop.
Javadoc: You should begin to write your comments using Javadoc conventions, but I'm not asking you at this time to generate the Javadoc documentation from your code yet.
The class will divide into teams of two students each. Each pair will work on a single project for the entire quarter. Each pair will meet with Professor Futrelle for fifteen minutes every week at which time they'll present a hardcopy (distinct for each team member) explaining what they've done, raising questions, issues, etc. The source and compiled code needs to be deposited on the CCS Solaris system by midnight the night before your meeting. There will be one set of code for each pair team, not distinct implementations. The entire project approach for this course is highly organized and regimented, which is necessary given the large class size and the amount of one-on-one individual attention planned. So you must know the rules and stick to them, else your education and your grade will suffer, guaranteed!
This is a course in Object-Oriented Design. For that reason, there will be an emphasis on design. Just hacking away until something works will not be an acceptable approach. The documents you produce should address design, before all else. Once a design is done, writing the code is more of a simple task. The functional aspects of a design, what your program does, can be well-defined by a series of tests that your program must pass. It is not unreasonable to design and even code your tests before you write your project programs themselves. Then, the moment you've written something, you can see if it passes the tests. Even if you system involves some sort of dialogue, the underlying programming units must take input and produce the correct output, so that it can be tested. You can also write out tests that describe what interaction sequence should lead to what response, if you're using a dialogue box or command line.
The preferred order of work: Design your system first, design and write some tests, then code your system and test it.
Total credit for the projects will be 50% of your entire grade, with 40% distributed over the meetings (about seven) and 10% for the final project report. Each student will be allowed one missed meeting and its corresponding missed assignment. Other than that, no exceptions. The Midterm Exam will be 20% of your grade and the Final Exam, 30%.
Here is the complete list of projects. A lottery will be held Wednesday, June 26th. It is designed to try to assure that you get a project to work on that you're interested in. Each of you will rank your top five choices and write them down. In class, a drawing will be held. If you don't get your top choice, you go to the second round, and another set of drawings is held, until every student gets a project and one other student gets the same project. Sorry, but no arrangements are made to let you choose your partner. In this respect, the lottery is similar to the real world of work.
FIRST MEETINGS THURSDAY JUNE 27, NONE THURSDAY JULY 4th Each project on the project list page has a day of the week and time associated with it. Each meeting with a pair team lasts 15 minutes. The meetings will be held between 4pm and 6pm, Monday through Thursday, with a few extra sessions to add up to the 38 required. The meetings will be held in my office, 115 CN (Cullinane). YOU BOTH MUST BE ON TIME. (Wait in the lounge across the hall.)
By midnight of the night before your meeting each week, whatever code you have completed must be in a directory you choose on the CCS Unix system, the same directory every week. You can use other directories for your own past work or work in progress. When your first assignment is prepared in this way, you must send email with a cd command as the first line in the body, something like
cd ~bingo/com1204/project/current/You can use a deeper path for security; I'll explain. Send the mail to both of us, futrelle@ccs.neu.edu and xin@ccs.neu.edu. The directory should always include a README text file that tells us anything we need to know to execute your code. Your code must compile and execute on the CCS Solaris system, no matter where you develop it. Your README file should typically include an indication of what the main program is, to be run with the java command. If you decide to develop your system as an applet, we will still need access to the source, plus a URL (always the same). Remember, if your code writes to files, permissions need to be set so we're allowed to create files in the appropriate directory.
Each student is to bring a hardcopy to each meeting describing what they have done up to that point. In addition, each student should bring the graded copy of their previous week's report with them for comparison. It is critical that each report state its main points clearly and directly in the first few sentences, essentially an "executive summary". Spellcheck every report you write. Clarity of writing will be important and muddled writing will be downgraded (literally). Your written reports should not be more than two pages long. You are encouraged to add a third page of UML or other diagrams. Screen prints are also encouraged. All further details should be developed in documents kept with your code, optimally, in HTML documents linked to javadoc documentation.
In developing your projects, start with the most simple, even trivial designs, and keep them that way! As Einstein said, "Everything should be made as simple as possible, but not simpler." This often means throwing away code and writing new code. Just imagine you're drawing pictures in the sand. Draw one, rub it out, draw another, and keep that up. (More great quotes from Einstein here.)
For your very first meeting, you must prepare a brief report that focuses on your questions and concerns about your project -- aspects of your project for which you want some clarification and guidance.
Each project has a "Breadth" section specified. Often, it involves the history of the topic of the project. History material is not always accessible on the web and may require some library research, interviewing professors, etc. All Breadth topics should be integrated into your system, e.g., a user should be able to click a button and get your breadth discussion in a window or access it via a URL you give.
Your project must be altered a number of times during the quarter, as you learn new design patterns and deepen your understanding of object-oriented design. This new knowledge should be integrated into your system and your new approach and the changes noted in your reports. Sometimes this may mean modest changes to your code. In other cases it will be preferable to throw out your old code and start afresh. This is encouraged.
I strongly encourage all pairs to work together, sitting at the same machine at least a few hours each week developing your design and tests, and developing code, testing, critiquing, documenting, etc. Please do not do all your work at a distance, with the two of you working miles apart. Some indication about who did what should appear in your reports. It is also important that you don't settle into an arrangement in which one person does all the coding and the other does the rest. You must take turns.
As long as you do substantial design and project building yourself, you are welcome to use any of the many built-in capabilities of the Java platform. For example, to parse some programming language, you can use Java's built-in tokenization and spend the bulk of your time on the parsing task. To do client-server work, you can use Java's built-in support for RMI or sockets. Scrolling windows are another example.