A major assignment in the class is a term project. Each student may choose
one of three types of projects: a programming project, a writing project, or an architecture project. In addition, each
student will be assigned as a "reviewer" for the
project of another student in the class. Each project produces an intermediate report , final report , and a final oral presentation. All project materials must be submitted
in electronic form that clearly identifies the creator(s) and can be handled
in a mangeable way. Grading is done both for creating
a project and for serving as a reviewer of a project. There are several important
dates that are used as milestones in the projects.
Click here for an archive of previous year's projects in this course.
A programming project produces a well-designed executing system that solves a specified distributed programming problem. Programming projects may be implemented using one of a wide variety of available libraries, frameworks, or systems among which are:
Each programming project will involve a team of two students. The two students on a team will each receive the same grade for the project. The students may select their own partners and may divide the work in any appropriate way. It is expected that both students will contribute equally to the work and benefit equally from the learning associated with the project. It is considered a violation of the Honor Code for one student to allow another student not to contribute to the project as an equal partner. Problems with equal participation should be brought to the attention of the instructor at the earliest possible time. Members of a team may collaborate with other students on the installation of the software needed for the project and they may collaborate on achieving a basic understanding of the mechanisms of each system. However, each team's design and code must represent that team's creative work.
Example Projects
To give some examples of possible programming projects, three default projects are briefly described. Students are encouraged to exercise their own creativity in defining a project that meets their technolgy and application interests. These descriptions are not sufficiently detailed to serve as as a project description.
Electronic Commerce
The system consists of four different machines for
the client, two "stores", and a "bank." The system allows the client to view
and purchase items from either store. As part of the purchase order, the
client provides an "account number" which the store will verify by contacting
the "bank". Before authorizing the expenditure, the bank will seek confirmation
from the client that the amount and the store are acceptable. The interaction
between the client and the store should be asynchronous. That is,
the client should not block waiting for the store to reply to it requests
to view or purchase items. This allows the client to conduct business with
several stores simultaneously. This system could be implemented using remote
invocation, mobile agents, messaging systems, or distributed objects systems.
P2P File System
The system consists of an arbitrary (at least three)
number of peers that interact to form a virtual shared file system. Each
file is stored on one or more of the client machines. A peer-to-peer (P2P)
protocol is used to create the impression of an integrated file system in
which any client can access any file. Files may be replicated for reliability
and performance purposes. Mechanisms must be implemented to guarantee some
form of access control for protection and some form of concurrency control
to deal with concurrent updates to the same file by different clients. This
system could be implemented using a P2P framework such as JXTA, or a combination
of tuple spaces and remote invocation.
CSP Communication API
This project develops an API that allow processes to
interact in a CSP-style messaging semantics. The API should present
to application developer an expressive and convenient set of abstractions
and operations that conform to the semantics of message-based communication
defined by Hoare's Communicating Sequential Processes (CSP). The specific
semantics include named processes, non-deterministic message selection, rendezvous
blocking, and termination. This project can be implemented using messaging
systems such as JMS or other messaging systems.
Proposal
Before beginning a programming project, the two students forming the team must submit a project proposal for approval by the instructor. The proposal must give the names of the two students, the underlying distributed technology or system that will be used, a short (one page) description of the system to be implemented, and a brief explanation of the relevance of this system to important topics in opeating systems.
A writing project produces a 10 page technical paper based on the contents of two papers published in the technical literature on a subject related to the course. Page limits are strictly enforced on writing projects. Papers will be downgraded for using overly small font or other formatting devices to avoid the effect of the page limit. Figures, tables, and graphs must be used as appropriate.The paper should be written in a style and format as if it were being submitted to a technical journal for review. This means that it must contain a title, abstract, standard sections, and reference list. Writing projects will be graded both on the technical content of the written paper as well as on the quality of the writing and presentation.
Proposal
Before beginning this form of project, students must submit a project proposal
for approval by the instructor. The proposal must give a complete bibliographic
entry for each of the two papers and describe the relevance of
these papers to a topic in the course.
An architecture project studies and documents in a 10 page paper the detailed structure and operation of a working system. The overall goal of this project is to promote learning about concepts in operating systems by studying first-hand an artifact developed by professionals in the field. The source code of the system must be available via an open source form or a publicly available download. The intention of the project is not to read documents or tutorials about the system's design and implementation. Rather, the intention is to study directly the source code of the system and its immediate documentation (e.g., the Javadoc level of documentation for a Java-based system). From this study, the design of the system is understood and documented using written text and common diagramatic forms (e.g., UML diagrams).
Proposal
The proposal should identify the system to be studied, the site from which the source code is available, the overall nature of the system, and the specific aspect of the system to be examined.
Credit for having completed the intermediate review will be given to the student doing the review. The reviewer returns one copy of the review to the individual or team whose project is being reviewed and a second copy to the instructor or GTA as indicated at the time. Failure to turn in the intermediate reports on the specified dates to the instructor or GTA will result in loss of credit to the reviewer.
Programming Projects: Each programming team must prepare a brief written description of their system and conduct a live demonstration for the student reviewing their project. The written description must contain a design diagram showing the essential components in the system and a 2 page overview. The overview must state the objective of the system, identify the underlying technologies used in the project, explain the design diagram, and give other information helpful to the reviewer. After reading the materials prepared by the programming team and observing the live demonstration, the reviewer writes a 1-2 page report describing the demonstration and giving critical and helpful comments for consideration by the programming team. The written materials prepared by the programming team and the reviewers report must be submitted together on the review due date. The submitted materials must give the names of the programming team members on the reviewer on the first page.
Writing Projects: Student doing a writing project should give to their reviewer a draft of the paper being written at least one week prior to the review due date. Sections not yet written must be indicated by appropriate section titles. The reviewer should carefully read the paper, marking up the draft paper with critical and helpful comments. The reviewer must write a 1-2 page commentary that gives other critical and helpful comments on the paper as a whole. A copy of the marked-up manuscript and the reviewers report must be submitted together on the review due date. The submitted materials must give the names of the student doing the writing project and the name of the reviewer on the first page.
Architecture Projects: Student doing an architecture project should
give to their reviewer a draft of the documentation being written at least
one week prior to the review due date. Sections not yet written must
be indicated by appropriate section titles. Design diagrams and other figures
should be included in the documentation. The reviewer should carefully read
the documentation, marking up the draft version with critical and helpful
comments. The reviewer must write a 1-2 page commentary that gives other
critical and helpful comments on the paper as a whole. A copy of the marked-up
documentation and the reviewers report must be submitted together on the
review due date. The submitted materials must give the names of the student
doing the architecture project and the name of the reviewer on the
first page.
Programming Projects: Students doing programming projects must arrange a time to conduct a live demonstration for the instructor or GTA to exhibit the required functionality of the system. Also submitted at the demonstration is a final system's design in a graphical diagram using a standard design notation (e.g., the Unified Modelling Language) and a report highlighting the significant aspects of the project.
The final report should follow this outline:
Architecture Projects: The final version of the documentation
serves as the final report for architecture projects.
|
|
|
| Technical Content of Final Report |
|
| Final Presentation |
|
| Intermediate Report |
|
Extra credit may be given for exceptional work that represents the highest
level of creative activity.
|
|
|
| September 19 | term project proposals due |
| September 26 | term project proposal approved |
| October 24 | intermediate reviewers assigned |
| October 29 | intermediate reviews begin |
| November 7 | intermediate review reports due |
| December 10 | projects due |
| December 11-16 | project presentations |