This page is archived. It is kept only for reference purposes, so it is no longer being updated and may not meet accessibility standards. If you need this content in a different format, please email inst@eecs.berkeley.edu.
All groups must submit a Final Design Document, System Test Docment, README, Public/Private Key File, and Source Code. The deadline for Project 1 is Monday, October 31, at 11:59PM.
This document can be reused from your original design document, or reflect changes you have made in your initial design. This document should be more formal than your original document, containing the following sections:
Provide a high-level description of the system's structure with a small collection of top-level modules. This description should identify each major module by name, state its purpose, and discuss how it interacts with other modules.
Present the system's architectural model; an architectural model of a system is a description of the top-level modules, and the data and control flow between them. Graphical notations are preferred for this task, but concise, well-written text may suffice. Note: A class diagram is an architectural model for an object oriented project.
A module is any part or subsystem of a larger system. A module may itself be decomposable into other modules that each provide part of the parent module's functionality and hide some of the parent module's secrets. A module decomposable into other modules is called an internal module; a module that is not decomposable into other modules is called a leaf module. Internal modules tend not to have internal computational structure, serving instead as grouping mechanisms for their component modules. Leaf modules, conversely, have a rich internal computational structure. Certain information must be supplied for every module in a module description, but some information is only needed to document the richer internal structure of leaf modules. Information that should be provided for every modules includes the following:
Module behavior. Explanation of a module's behavior includes (1) a catalog of the operations it provides, with descriptions of their input and output and their externally visible effects, and (2) a catalog of the data types and objects that the module provides.
Assumptions. A module's assumptions are the conditions that must be satisfied for an implementation of the module to work. For example, a file processing module might assume that a file passed to it is open and readable.
Secrets. The implementation details hidden from other modules inside the module under discussion must be listed.
Error handling. Errors and exceptional conditions that may be encountered by the module must be listed, along with their causes, and the strategy used to handle them.
A module uses another module if some function provided by the latter is called somewhere in the implementation of the former. Uses relationships are important because they show the modules on which each module depends for its correctness.
This section explanation design decisions, listing the alternatives explored, and justifying the design decisions that were made.
As in other development documents, a glossary should be provided to minimize confusion about technical terms.
The System Test Document contains a test by test description of the cases your group tested against your system. There is no set number of test cases, or specific requirements that the test cases must cover. However, it must be evident that the test cases verified both system functionality and that the security requirements were met.
Summarize the software items and features to be tested.
A description of the items under test.
One per test case.
One per test.
A description of what this procedure tests.
How the test was run and what happened.
Please submit the final design and test documents in .pdf, .ps, or .txt formats only.
Use the following naming convention for the final documents:
CS161-GN_FinalDesignDoc.{pdf, ps, txt}
CS161-GN_SystemTestDoc.{pdf, ps, txt}
where N is your group number.
Include working source code. Please Include a file containing all of the public/private key pairs your group generated for use in the project.
Include a README file containing the names and logins of all group members. Include the location and name of your public/private key pair file. Also, detail how to install and run the code, especially if there are any unusual steps.
From one group member's named account, tar and compress files for submission
tar -czvf project1.tar.gz project1
where project1 is the directory containing all of your files.
In the same directory where project1.tar.gz is located, run
submit Project1
Note: You can submit as many times as you want up until the deadline. Only the last submission will be graded. Please submit your project from only one account.
Each group is permitted 3 slip days for the entire semester (2 projects). Once a group misses the deadline for a project (12:00AM after deadline day), one entire slip day will be used. Slip days cannot be partitioned.
The following is the grade breakdown for Project 1: