In-Memory Database with Persistence

Due May 7

We will create an in-memory database for grades. A grade event contains a grade, a red id and a name. The grade is a number between 0 and 100. A red id is a 9 digit number that identifies a student. A name of a grade event is a string like "assignment1" or "test2". Create a class "CourseGrades" that allows you to:

Add new grade events.

Modify an existing grade event.

Compute grade average for a given student.

When modifying a grade event the score may change, but the grade event and red id does not. One computes an average grade assuming that all grade events have the same weight. Given a red id the CourseGrades object should return the average for that student.

The problem with CourseGrades as a database is that it does not persist. Once your program stops running all data is lost.

Use the memento pattern to copy the data in a CourseGrades object. Make the memento serializable so it can be saved in a file. Given a CourseGrades object and a memento you can restore the CourseGrades object to a previous state. Given that a program may have many references to the CourseGrades object you can't just replace the CourseGrades object with the memento.

So now we can periodically create and save a memento of the CourseGrades object. But the memento can become rather large. (CourseGrades is just an example. If we were doing this for real our data could be 100's of megabytes.) So we would not want to save it after each operation.

For each operation that changes the state of the CourseGrades object create a command. Make the commands serializable. Keep in mind that we don't want to serialize the CourseGrades object each time we serialize a command. Also when we deserialize a command object we will have it operation on the CourseGrades object that is in-memory, which is likely not to be the same CourseGrades object that the command first operated on.

Now every time we perform an operation on a CourseGrades object, we can create a command, perform the command and save the command to disk. This way we will have a history of all the operations. If our program were to crash we can recover the last state by replaying all the commands. Since the commands will always be small, which is not the case with the CourseGrades object, saving it to disk each time will not be very expensive. However having to create those commands each time we want to perform an operation can be annoying.

Create a proxy(s) for CourseGrades objects. For every operation that changes the CourseGrades object's state the proxy will create the command, perform the command and save the command to a file.

Instead of creating proxy(s) you might be tempted to make the CourseGrades class create the commands, execute the commands and save them. Why is the proxy a better idea.

Grading

Item	Percent of Grade
Working Code	20%
Unit Tests	10%
Proper implementation of Patterns	60%
Quality of Code	10%