Department of Computer Science and Engineering CSE 134A
University of California at San Diego Fall 2002

Project 2

DUE FRIDAY OCTOBER 25, 2002, AT 5 PM.





We have an important new policy for the second project: For each day early that your team hands in its project, 5% will be added to your score, for up to a maximum of  five days.  For example, if you hand in the project on October 22, your score will be multiplied by 1.053= 1.16.  The purpose of this policy is to encourage you to start work immediately.

Reminder: For this project you must work in a team of three students, and you must write a careful team report.  You have more than two weeks, but do start work immediately.

The purpose of this project is to develop your high-level user interface and software design skills, using PHP and MySQL.  The assignment is to build a discussion board similar to the existing systems QuickTopic and Discus, but better.  You should explore Discus and Quicktopic thoroughly, and think carefully about what is good and bad about these systems.  Then you should design a system that is superior to both, but not more complicated.

USABILITY.  QuickTopic would be more useful if it had a couple of additional features, in particular nested threads.  On the other hand, Discus is excessively complicated and the user must click through too many screens.  You should use your creativity and your good sense to design a discussion board system that has the best possible user interface.  For ideas about design features, look at published opinions about QuickTopic.

Your discussion board should be compatible with most versions of Netscape Navigator 4 and Internet Explorer 6, at least.  You may use a small quantity of images and client-side Javascript if doing so is really useful, but remember to prefer genuine usability to flashiness.  Simple HTML tables, with appropriate use of color, are a good way to implement a clean graphic design.  Use Yahoo, Google, and QuickTopic as examples of good graphic design.

SCALABILITY.  Your software architecture should be as scalable as possible.  Imagine that thousands of people use your software simultaneously, to discuss hundreds of topics.  Choose your database schema, which indexes you create, and the SQL queries in your PHP code carefully.

Modularity and portability are important software design properties that are always important, and related to scalability.  You should separate as much as possible your database access code, the code that implement system features, and the rendering code that generates the HTML that users see.

SECURITY.  We want to prevent users from posting under false identities.  In particular, a person should not be able to create multiple meaningless userids to hide his or her true identity.  On the other hand, a new user should be able to register immediately and easily.  It is up to you to invent a security scheme that achieves these objectives.  Since perfect security cannot be achieved, you will need to make trade-offs in your design decisions.  We want to see creativity, robustness, and simplicity here!

The discussion board administrator is a special user.  He/she can create new topics, and remove users, topics, threads, and messages.  The user name for the administrator should be set to admin with an initial password of admin also.

SPELL-CHECKING.  Your software should have a non-interactive spell checker.  This means that the text of a message should be checked all at once, as opposed to while the user is typing.  For spell-checking, your PHP code should communicate with a separate Unix process through a socket.  You should not use any PHP built in spell-checking functions like pspell.  Instead, you should use the ispell UNIX software program, which is available on the computer  ai.ucsd.edu  through port 8518.  We have implemented a server that your PHP code can access through a socket.  You send a line text to the server through the socket, and the server gives the text to the ispell program.  This program outputs a list of mis-spelled words, if any exist.  The server then writes the incorrect words as output to the socket.

One issue you must think about carefully and discuss in your report: What if many message authors are trying to use a single spell-checking server simultaneously?

Your spell-checking feature should have a convenient non-interactive user interface for message authors.  For example: After s/he writes a message, the user clicks a "preview" button, and then all incorrectly spelled words in the message are highlighted.  The user should then be able to make changes before the message is actually published.
 
 

WHAT TO SUBMIT

We will provide detailed instructions for where to install your PHP script and how we will be testing it.  Remember to check the class web page and discussion board regularly for possible updates to this project description.

You should describe all your work in a well-written report of length at most six pages, printed single-spaced and stapled.  The report should explain all the important design decisions that you make for the project, and also provide documentation for your software.  As outlined above, three of the most important design issues that you must address during this project are usability, scalability, and security.  Your report should explain all the important decisions you make concerning each of these issues.

This project, and later projects, will be graded as follows:

Your software must have commenting and organization of professional quality.  In total, your report and commenting should be sufficient for another software engineer to maintain the software easily.  Remember that good documentation is necessary but not sufficient. Comments and user instructions cannot alleviate bad engineering.

Don't forget to staple a copy of the team self-evaluation form to your report.  The form will be required for all team projects in 134A.  Be sure to follow all the rules and guidelines explained in the general course description.  Complete academic honesty is always required.