Assignment 5: Data Base Pairs
Out on:
February 25, 2008
Due by:
March 3, 2008, 3:00 pm (before lecture)
Collaboration:
Pairs
Grading:
Packaging 10%, Design 10%, Style 20%, Functionality 60%
Overview
The fifth assignment asks you to collectively improve the simple database system each one of you implemented for the last assignment. Since you are working as a pair now, it's important that you coordinate your schedules and stay in touch during the week! Working together in lab or at a laptop in a cafe somewhere is highly encouraged! After the assignment is over, each of you will be asked to evaluate the contribution your partner and yourself made to the assignment.
Interface & Implementation
This is where you can get the latest version of the interface you need. Please watch the mailing list carefully for changes to this!
-
Latest version:
sdbm.h
with
md5sum 69801a25ec93880f8cef3107e014d777
Also, you should grab Peter's Implementation for Problem 1. The version you get here is quite a mess, but we include it for your enjoyment anyway. :-) You cannot pick Peter's implementation as the one you want to work on for Problem 2! You must pick one of your own implementations!
Problem 1: Code Review (30%)
Your task for the first problem is to perform a code review to see what you can learn from each other's code. Note that you can learn from good as well as bad code, the important thing is to see what others do and compare it with what you did.
You should follow the procedure described in class: Exchange the code; read it by yourself first, making notes as you go; then meet and discuss your findings and questions; then decide whose code to start from for Problem 2; then write up your findings, including why you chose one implementation over the other.
If both of you have an implementation, focus on those two and read Peter's code just for fun. If one of you doesn't have an implementation, review Peter's implementation as well. If neither one of you has an implementation, review Peter's code only; you have it easier for this problem, but you're in trouble for Problem 2. :-/
In your README file, collect both good and
bad aspects about each implementation you reviewed. The
criteria are obviously vague, but you will no doubt have
to say things about the code, right? Check functionality,
check style, check commenting, see what splint
says, etc.
Once your findings are complete, explain which version
you are going to work on for Problem 2 and why.
And again: You cannot pick Peter's code as a starting
point for Problem 2! You can use it for "inspiration"
if you think there's anything useful in there (I doubt it).
I strongly recommend being done with the code review by Thursday at the latest! You'll need time to actually work on Problem 2!
Problem 2: Database Implementation (70%)
The simple database you are implementing needs to conform to the well-defined provided above. Do not change the interface for any reason! If an error needs to be corrected, we will post a new version of the interface with a new checksum!
It's (still) easy to describe your task: Implement the interface! :-) You are now working as a pair and from existing code, but your goal is still the same as before. If you think that you already have perfect code, fine. If you think that you only need to clean up a little, fine. If you think you should do major surgery because the old approach is not very good, fine. It's up to you what you focus on for your improvements. What's important is that you try to make this version really good. We'll grade it with much higher expectations than the last one.
Please put your implementation into a file sdbm.c
and make sure that sdbm.o builds by itself so it
can be linked to the separately compiled test programs.
Hints
- Feel free to bring up changes to the interface just like last week. We can discuss them on the mailing list and see what everybody thinks.
- For those who took data structures already: Do not worry too much about efficiency at this point! Correctness and clean code are still more important than speed or memory efficiency. In the next assignment, however, performance is going to matter.
- Technically you have to worry about what happens when two programs access the database concurrently. However, this turns out to be quite involved to get right, so you can simply assume that it won't happen for now.
Deliverables
Please turn in a
gzip
compressed
tarball
of your assignment;
the filename should be
cs120-assign-5-login1-login2.tar.gz
with login1 and login2
replaced by your Unix login name on ugradx.cs.jhu.edu.
The tarball should contain no derived files whatsoever
(i.e. no executable files),
but allow building all derived files.
Include a README file that briefly explains what your
programs do and contains any other notes you want us to check out
before grading.
Include a Makefile to build your project.
Grading
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to C programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, suitable documentation, etc.
Simple, clean, readable code is what you should be aiming for.
Performance refers to how fast your program can
produce the required results compared to other submissions.
Design refers to proper modularization and the
proper choice of algorithms and data structures.
Functionality refers to your programs being
able to do what they should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file.
If your programs cannot be built you will get no points whatsoever.
If your programs cannot be built without warnings using
gcc -ansi -pedantic -Wall -Wextra -std=c99 -O
we will take off 10% (except if you document a very good reason).
If your programs cannot be built using make we will
take off 10%.
If your programs fail miserably even once,
i.e. terminate with an exception of any kind or dump core,
we will take off 10%.
Finally, make sure to include your name and email address in
every file you turn in!
