CISC220, Summer 2006, Project 4

Introduction

In Projects 4 and 5, we will address the problem of HTML tag matching

As we discussed in lecture, you can use a stack to solve the problem of checking open and close tags in HTML for "proper nesting". Open tags are pushed onto the stack. Close tags cause us to pop the top of the stack, and check for a match. If the close tag and the top of the stack doesn't match, or if the stack has nothing to be popped we return a failure. We also return a failure if the stack is not empty when we hit end of file.

In Project 4, you will do test-driven development of two classes:

HTMLTag_C, a class to represent HTML tags such as <html> <head> <title> <body> <h1> <p>, etc., along with the line number and character number where they appear in an input stream.
HTMLTagStack_C, a class that allows HTMLTag_C objects to be pushed and popped from a stack.

In Project 5, you use these classes to solve the problem

Project 5 will use the classes you developed to write a program that accepts HTML input, and either prints "ok", or gives a report of one of three kinds of errors that may be encountered:

A mismatch between a close tag and the open tag at the top of the stack
A close tag, encountered when the stack is empty (i.e. there is no open tag to match this close tag with)
An open tag with no close tag (encountered when we reach end of file with a non-empty stack)

More about what you will do in Project 4

I am providing you with two files, HTMLTagTest.cc and HTMLTagStackTest.cc, that contain test cases for these two classes. Those files can be found at:

The following directory on strauss: /www/htdocs/CIS/220/pconrad/06J/work/proj/proj4
The proj4 directory on the web site

From these two files, you should be able to "back engineer" what the interface to these classes should be (i.e. what the member functions are), and what the behavior of those member functions is supposed to be. You will write:

the .h files for these two classes
the .cc files for these two classes
a Makefile to compile it all

You will also need the following files, which you can copy directly from one of my lecture code directories. They may need to be adjusted to fit the problem, i.e. if they don't have the correct versions of assertEquals() for mixes of C strings and C++ strings.

runTests.h
runTests.cc.

What to do

Work with HTMLTagTest.cc first. Write the .h and .cc files for the HTMLTag_C class first. It is suggested that the first time out, you just write "stubs" for the member functions, so that all the tests fail, then write correct versions so that all the tests pass. As part of this step, you'll need to:

create a Makefile
copy the code for the runTests.h and runTests.cc .

Repeat this process for HTMLTagStackTest.cc, and the .h and .cc files for HTMLTagStack_C.
Produce a script and a tar file documenting your work. For this project, include listings (cat the files) of all your .cc and .h files, as well as your Makefile (even the ones that I provided you with, or that you copied from the web site.) This is in case different folks use different versions of the RunTests_C files, and also to have a handy documentation for the grader of the test files.

Special Notes

What you can change, and what you should not change

You might need to make some adjustments to the RunTests_C classes so that you can check certain datatypes for equality.
However, you should NOT need to make any adjustment to the HTMLTagTest.cc or HTMLTagStackTest.cc files.
- Those files should be left AS IS, since in a sense they "define" the interface and the behavior of the classes they test.
- In the real world, sometimes a test file like this is provided as a kind of "contract" between the person specifying the requirements (the "customer"), and the person doing the implementation (the "developer").
- If you think that you do need to make some adjustment, check with your instructor first (in the real world, you'd check with your "customer".)

Grading:

10% Makefile
20% HTMLTag.h
20% HTMLTag.cc
20% HTMLTagStack.h
20% HTMLTagStack.cc
10% general style, correctness, etc.