[SOLVED] COMP2160 Assignment 3

Description

In assignment 3 we’re going to apply what we’ve learned about interfaces, testing, and multi-file compilation.

Notes

• Read the entire assignment document before starting.
• Your programs must run correctly both with assertions enabled and disabled (when compiled with and without the -DNDEBUG option).
• Please be sure to follow the programming standards; not doing so will result in a loss of marks.
• Remember to complete the Honesty Declaration Checklist (you will not receive scores for your assignments until the checklist is completed).
• All submitted assignments will be scanned with automated software to monitor for academic integrity violations.
• Your assignment code must be handed in electronically. See the Submitting your assignment section below for more information.
• Late assignments are not accepted. The due date is enforced electronically.

Objectives

• Designing interfaces and building implementations.
• Multi-file compilation.
• Testing.

Question 1: Container

For question 1, you’re going to write an interface for an abstract data type (a “Container”), and you’re going to provide an implementation of that ADT with a linked list.

The interface

First, you should build an interface for the container ADT. Your container will store strings (as char*).

We’ll give you the names of the functions below, but you must write complete prototypes for your interface. Choosing the return types and parameter types is your responsibility.

Your interface should contain the minimal amount of information required for someone to use your implementation in their code.

Functions

Your interface should be implemented as container.h with the following function names:

Creating and destroying:

• createContainer (Create a new instance of the container)
• destroyContainer (Destroy the container and its contents)

Manipulation:

• insert (Insert an item into the container)
• delete (Remove the specified item from the container, only one if there are multiple)
• clear (Remove all items from the container)

Iterating and searching:

• firstItem (Start iterating over items in the container)
• nextItem (Continue iterating over items in the container)
• contains (Does the container contain this item?)
• size (how many items are in the container?)

The implementation

Once you’ve got an interface, create an implementation for the container by implementing a linked list of strings. Your implementation should define the data structure, and implement all of the functions declared as prototypes in the interface.

Your linked list implementation must apply the principles of design by contract. In particular, you should be implementing a function invariant on the linked list.

Your implementation should be implemented as container.c.

The tests

Finally, you should build an automated test suite for your container implementation.

Your test suite should be implemented in a file called main.c, and you should be sure to test all functions in the file with both general case and edge case test data.

Tests should be organized appropriately into their own functions.

Your test suite should report:

1. Progress: a statement about what the test is testing (i.e., “searching for X”)
2. Success: a statement about whether or not the test succeeded (i.e., “FAILED: expected to find X, but could not find it.” or “SUCCESS: expected to find X and found it.”)
3. Summary: a summary of the number of tests run, the number of tests passed, and the number of tests failed.

You should refer back to the Levenshtein implementation in Assignment 1 to get an idea of what a testing suite that matches this description looks like.

Building

Your solution for question 1 must include a Makefile. The grader should only have to type the command make in your directory to build your assignment.

Question 2: Black-box testing

You have been provided with an implementation of a set ADT developed by a third-party. The implementation consists of a header file set.h that defines the interface and a compiled object file with the implementation.

Your job is to verify that the third-party developer is not a terrible programmer (hint: they aren’t terrible, they’re really terrible).

You should implement a complete test suite for the set ADT and provide a report (in a Markdown-formatted README file) explaining what is broken with the implementation of the set that this really, really terrible programmer has given to you.

You should use the testing suite you built in question 1 as a basis for the testing suite you build here.

The first set

You have been provided with one implementation of the set by a competent programmer. The implementation is in a file called set.o that has been compiled on aviary (Linux). The first implementation that you’re being provided with is 100% correct – none of the functions in this file are implemented incorrectly, there are no bugs in this implementation.

The tests

Your job is to write a complete test suite for the implementation of a set.

Your test suite should be implemented in a file called main.c, and you should be sure to test all functions in the file with both general case and edge case test data. Also note that there’s a function called validateMemUse() that can be used to verify that all instances of Set that were created have been destroyed – your test suite should use this function to check for memory leaks.

Tests should be organized appropriately into their own functions.

Your test suite should report:

1. Progress: a statement about what the test is testing (i.e., “searching for X”)
2. Success: a statement about whether or not the test succeeded (i.e., “FAILED: expected to find X, but could not find it.” or “SUCCESS: expected to find X and found it.”)
3. Summary: a summary of the number of tests run, the number of tests passed, and the number of tests failed.

For the set implementation that’s provided above, all of the tests you write will pass.

The other sets

Closer to the due date, we will provide you with 5 more implementations of a set that implement the same interface. You will use the test suite that you wrote for the correct implementation of a set to determine what (if anything) is wrong with each of the set implementations that you’re provided with.

You must write a brief analysis for each file in a file called README.md. README.md should be a Markdown-formatted file (use headings!).

While the code we will provide to you is buggy, it will not crash. If you receive any error messages (segmentation fault, abort, bus error), the crash is happening in your code. When this happens, your strategy should be to re-read the comments in the set interface to better understand what each function does/requires. If you still can’t figure out why your tests are crashing, you should pull out your debugger and debug your code.

Submitting your assignment

Create a directory called comp2160-a3-<yourlastname>-<yourstudentid>. Within that directory, create a directory for each of Q1 and Q2, where you will put your respective files for each problem.

Then run the command:

handin 2160 A3 comp2160-a3-<yourlastname>-<yourstudentid>

• You may optionally include a README file in the root of your directory that explains anything unusual about compiling or running your programs.
• You may resubmit your assignment as many times as you want, but only the latest submission will be kept.
• We only accept homework submissions via handin. Please do not e-mail your homework to the instructor or TAs – it will be ignored.
• You must submit an Honesty Declaration (digitally on UM Learn). Assignments submitted without a corresponding Honesty Declaration will not be graded.
• We reserve the right to refuse to grade the homework, or to deduct marks if these instructions are not followed.

Evaluation

Your assignment is worth 30 points, 15 points × 2.

Note that your code must compile – no part marks will be given for code that does not compile.

Note further that your code must compile with make. Graders will not manually compile any code by running clang for this assignment, even if you write instructions in the README.

Warnings

The code you write should compile with clang -Wall without any warnings. A 1 point penalty will be applied to your score (before multiplication) for each warning that is emitted by the compiler.

Question 1

make

Question 2

Test suite

Report

A total of 5 points is available, one for each set implementation. Correctly reporting the buggy function(s) and what is buggy about the function for each set implementation is worth 1 point.

The report must be written as a Markdown-formatted file. You must minimally use headers to separate the report into sections, for example:

Set 1
=====

* The function you think is buggy in set 1
* What is buggy about that function?

Set 2
=====

* The function you think is buggy in set 2
* What is buggy about that function?