A Design Project

Here is an in-class architecture and design exercise. You will probably realize what the purpose is after you get into it a bit.

Get into groups of four.

Design a Message Board, or Forum, "Service", more or less like the original Slashdot. (Anyone remember Slashdot?) Do it in 90 minutes instead of several weeks. This exercise really focuses on the analysis and design workflow of the development cycle. You may assume that the business rationale already exists and that an infrastructure and supporting workflows are taken care of. Your team is just going to figure out what the following requirements mean, and come up with an architecture supported by some UML diagrams.

Specifically you need to produce a Use Case Diagram, a Component Diagram showing the major subsystems, a Deployment Diagram showing the overall physical architecture, Sequence, Collaboration, or Activity Diagrams for some interesting use cases, and a Class Diagram suggesting a backend.

The "requirements" for this exercise are purposely vague. If you have used Slashdot or other forum you know what I want. I will point out some minimal things that you must have (or consider):

Users may but do not have to register.
Users can post messages, search for messages, read messages, and rate messages. Posts can be "followups" to existing messages.
The "line listings" can be viewed as either a long sequence of message "headers" in time order, or in a threaded format.
Users should be able to "filter" messages by rating, by poster, and by thread depth.
The service should work via the web, mobile device, plain console, or any other yet-unknown display mechanism.

You may add more features if you want, but only if the feature is necessary to fill in some missing requirement above that would prevent the tool from working at all. If you try to add some real new "cool" functionality now, this early in the design, before completing so much as one iteration, you should really fail the course.

As you work, you must:

Don't get chaotic. Always start at the beginning. The very beginning. Don't fuss with details too early.
Pay rabid attention to separating concerns. Anytime you can reasonably make some part of the system independent of some other part, do it.
Identify design patterns by name where they occur.

Work is to be done on whiteboards. When you finish, the class will tour each other's solutions and praise them or pan them. Groups will offer each other constructive criticism. So will I.