1. Grading and Deliverables

For this project, you may either work alone, or in a team of two. We recommend working in teams of two, since it helps to talk through many of the more challenging components of this project with a partner.

Project 2 is worth a total of 150 points, broken down as follows:

View how this project is weighted relative to other components of this class on the course website.

Checkpoint (due Thursday, July 21)

The checkpoint submission consists of:

1. A draft design document, and;
2. A draft test proposal, consisting of six proposed test cases you’d like to implement

Draft Design Document

An outline of what we expect in your design document is here.

The draft design document will be graded on correctness, which is defined by the ability for your design to satisfy the design requirements. It should be a maximum of two pages, with an additional maximum of two pages containing a diagram. There is no minimum length, as long as you cover all of the required portions. The diagram can be created in any format of your choosing, using any tool of your choosing (hand-drawn, Miro, Draw.io, Docs, Publisher, etc.), and/or you could use the provided template (LaTex, PDF), as long as it clearly communicates the relationships between your structs in the Datastore.

Draft Test Proposal

The draft test proposal should contain six proposed test cases. Each test case should contain (a) one or more design requirements that the test is assessing, and (b) pseudocode to indicate what the test will do.

Here’s an example of a test:

Design Requirement: The number of public keys should not depend on the number of files stored [3.3.2]

1. Define CountKeystore(), a method that counts the number of keys in Keystore.
2. Create one user.
3. X = CountKeystore()
4. Store 100 files.
5. Expect that the number of public keys didn’t change (expect CountKeystore() == X)

For inspiration of other test possible test cases, take a look at the Design Requirements and the provided tests in the starter code. Your test cases cannot include the test cases provided in the starter code, or the specific test case described above.

The draft test proposal will be graded on completion. It should be a maximum of two pages.

Design Reviews (Monday, July 25 - Wednesday, July 27)

After the checkpoint, we’ll offer optional design reviews for you to chat with a TA about your proposed design.

If you do not recieve full credit on your checkpoint submission, you’ll have a chance to receive points back if you sufficiently address the feedback on your design doc during your design review.

If you do recieve full credit on your checkpoint submission, this does not indicate that your design is foolproof! The autograder is the true measure of design correctness, as outlined by the specification. The checkpoint is just an indicator of whether or not you’re on the right track. Note that even if you do recieve full credit for your design, you can still sign up for a design review to chat with a TA.

Note that we will aim to grade and return your design documents with feedback over the weekend after they are due. Due to the tight turnaround, it’s in your best interest to turn in your design documents on time!

Final Submission (due Tuesday, August 2)

Your final submission consists of:

1. A final design document, and;
2. A final code submission, consisting of…
   1. A client implementation
   2. A comprehensive test suite

Just for fun - no project-relevant content in this box.

REGULUS guarantees availability when line of sight can be established between you and the moon. Requests to REGULUS may be processed when line of sight is unavailable depending on the availability of uplink proxies around the globe and conditions of the ionosphere.

We guarantee 0-60% uptime depending on the time of month, cloud cover and occurance of solar flares.

Table of contents

• 1.1 Design Document
• 1.2 Autograded Code
• 1.3 Test Coverage