Object-Oriented Design and Programming 2020 – Coursework

(Version 2)

The objective of this coursework is to practice the development of moderately complex class graphs and the appropriate use of ownership concepts to avoid memory leaks and memory corrup- tion.

Coffee Roasting

Your task is to build the data backend for a web application supporting a coffee roastery. Coffee roasting is an intricate process that merits a brief discussion. The two key steps are blending and roasting.

Blending

When performing a roast, the roaster (the person operating the machine) first selects beans of different types and mixes them. A roast is, thus, comprised of several "Ingredients", i.e., a specific amount of beans of a specific type (we simply record the name).

Roasting

The roasting process turns a mix of green beans with little taste into the brown beans we like to brew. The roaster starts the process at a specific time (we use the starting time to identify a roast), preheats the roasting machine, adds the ingredients and empirically tracks the process. During the roasting process, a number of events can occur:

• The roaster sets the temperature to a specific value
• The roaster reads a specific value from the builtin thermometer
• The roaster fills the machine with beans
• The beans turn from green to brown (an event called browning)
• The beans crack (much like the popping of popcorn though without popping open the bean)
• The roaster drops the beans (removes them from the machine)

Roasty

Roasty is a web application to track the roasting process. It has a builtin web server and a javascript- based GUI. For this coursework, we have built Roasty and stripped out the data model component. The model is built around the concept of a roast (which has an id and a timestamp). A roast contains ingredients which, in turn contain a bean and have a set amount. A bean merely has a name. The roast further contains events which have a type (simply a string), a timestamp and an optional event value (which merely contains a numeric value).

Your task

Your task is to provide that data model. On the one hand, you need to analyze the problem and decompose it into a class structure. On the other, you need to implement the required behavior for the classes you designed. To guide you in the right direction, Roasty comes with a suite of tests. The tests (little functions that are run to verify individual pieces of behavior) define the required API – separation of concerns at its best. Once you pass all the tests, you can run the Roasty server, open your web browser and starting tracking your coffee roasts :-). Because Roasty is a comparatively simple application, it will live in two files (we do not separate code into one file per class). Those files are pre-created in your project repository: Source/Model/RoastyModel.hppandSource/Model/RoastyModel.cpp. Do not modify any other files (unless advised by me, i.e., Holger).

Getting started

To get started log in to a lab machine of your choice and run the following sequence of commands:

git clone ${your repository URL from LabTS} cd ${your repository name}

You should set up a separate directory underneath the project binary for the compiled binaries. Here is how you do that:

mkdir Build cd Build cmake -DCMAKE_BUILD_TYPE=Debug ..

If you prefer the clang compiler instead of gcc you can (on the lab machines) replace the last line with the following (clang tends to produce better error messages):

CXX=clang++-10 CC=clang-10 cmake.

You can compile the project by typing

cmake --build.

Note that the first build of the project will take a long time (and produce a lot of output) since it also builds dependencies.

Testing

To run the tests, simply run

./Tests

a successful run output should look like this (pass -? for more options)

=============================================================================== All tests passed (52 assertions in 6 test cases)

Running the server

To run the roasty server, run the following sequence (note that it is important that you run the server from the build directory which must be directly underneath the source directory

• otherwise it will not find the html/javascript code for the front-end)

./Roasty

the output should look like this:

Listening on http://localhost: ctrl+c to quit

At that point, you can openhttp://localhost:1234in your browser and enjoy the result of your labor.

Submission

The coursework will be submitted using LabTS. Important are two files mentioned files:

• Source/Model/RoastyModel.hppand
• Source/Model/RoastyModel.cpp.

Make sure all your implementation is in those files and no other files are modified. The markers will not take anything else into account. Use what you have learned in class so far. Do not use templates or inheritance.

Marking

The marks are distributed as follows:

• Correct implementation of the Roasty API (note that passing tests are required but not necessarily sufficient for a correct implementation): 30%
• Leak-freeness of the tests: 30%
• Reasonable performance (no silly performance bugs, appropriate use of references to avoid copies, etc.): 20%
• Clean code with appropriate documentation (Goldilocks: not too little, not too much): 20%