Dates of Interest

• Monday, May 6, 2006: Handed out
• Monday, May 12, 2006 (11:59PM): Due in

Procedural Information

• Your solution to the exam should be presented in a professional manner. This includes formatting, spelling, grammar, &c.
• A submission directory will be created within the course Andrew space. Your solution should be submitted in .pdf, .ps, .tex, or .doc format by copying it into this space before the deadline.
• If you are unable to submit your solution electronically, please report the problem to the course staff. We will work with you to correct any problems.
• Please remember that we are unable to process assigments submitted via e-mail.
• In accordance with University policy, once you begin work on this exam, you should submit it within 24 hours. Beginning work is hereby defined as doing more than reading this page, giving it a few minutes to one hour of thought, and assessing when you would like to begin.

Important Note

You may discuss course material and the exam question, itself, througout the exam period. But, please do not discuss your solution or appropaches to the problem, &c. In other words, feel free to study together and to discuss the question's scope and intent together -- but take the exam independently. Please continue to "remain silent" about about your solution to the exam and possible approaches until final grades have been assigned and recorded by the instructor.

These guidelines are not designed to be overly restrictive. In fact, they are designed to be rather liberal. They should be interpreted in a manner that is consistent with the following governing principles:

• Your solutions to the exam questions should be the product of your own though processes.
• You should provide proper attribution to those who contributed ideas that were not the product of your thought processes, but are present in your solution.
• Discussion of lecture material is a good thing.

Legal resources:

• Your textbook, your notes, and material residing within the 15-498 Web space
• Conversations with anyone to clarify any material present in the resources listed above: if you can point at it, you can discuss it. (Conversations should be read broadly, not necessarily face-to-face)
• Conversations with anyone to clarify the meaning or expectation associated with each of the exam questions.
• Anything approved by the course staff in writing, e-mail, or updates to this Web page.

Illegal resources:

• Anything not listed above.

Scope of This Exam

This exam is intended to take you about three hours and certainly ot more than five hours. The solution, flushed out in complete detail, could take weeks to design, and even longer to implement. We're certainly not asking you to do this.

Instead, please identify the major challenges, potential solutions, and trade-offs. Please also discuss challenges and pitfalls. And, of course, provide a general sketch of the architecture of your solution.

Overview

Your exam is to design two distributed applications for use by a team of traveling salespeople (including technical sales support people): a calender and a collaborative editor for developing proposals.

The System Model

• Each member of the team has a notebook/PDA, henceforth known as a "mobile host", which has normal network connectivity only periodically. When it has connectivity, it is usually, but not always "good", e.g. wireless at a coffee shop. But, in a pinch, it might be "bad", e.g. wireless over a cellphone modem. Each mobile client has "good" connectivity for at least a few hours each night.
  
  
• In addition to normal connectivity, mobile hosts can exchange messeges via SMS. But, thes emessages must be short (less than 180 characters), and are expensive (about 10 cents each), and are text-only.
• There are no central servers -- the entire system resides on the mobile hosts
  
  
• The system must be fail-safe for a small number of failures, measured as a percentage. Even for a small team, it should be able to handle at least one failure.
• There can be a centralized system for "back ups" that takes advantage of the night-time connectivity.

The Applications

• The Calender: the calender has a very simple role: organizing meetings of the team. It should allow the members to post/remove outside activities (black-out times). It should allow them to request a meeting by posting available times. It should allow members to accept a meeting, by selecting the subset of avaialble times that they can attend. It should confirm a meeting when a time has been found that is good for everyone. If more than one time is found, the initial requestor should be notified to select one. Either way, once a meeting is confirmed, all of the proposed times, accept the confirmed one, should be cleared. If it is determined that none of the originally requested times work (no overlapping availability, someone can't make any of the options), it should notify the original requestor. It should allow meetings to be cancelled.
  
  
• The collaborative editor: Sales proposals and support documents are highly structured. They include several different almost stnad-alone sections. Often times, several of these sections are "broiler plate" that doesn't change from proposal to proposal. Others are written exactly for one client.

  Please design a collaborative editor that allows the initiator of a document to provide its framework (sections) and moderate the development of the document (select which changes become live). It should allow all participants to see all proposed changes, either before or after acceptance by the moderator.

  We can imagine that the changes to this document are relected either in several versions (tab screens, perhaps), or with different colors per author. But, in either case, it should be clear (a) which version someone saw while editing and, (b) what the person changed, (c) who changed it.
  
  

• It is obviously useful for someone to find out quickly if a document has changed, especially if they are rpesently editing it, and how.
  
  
• It might make sense to manage the wholesale introduction of sections of the document, or complete rewrites, differently than edits within existing text.