Due Date: Wednesday, April 3.
Please put your assignments in one of the CISC 323 assignment boxes in the hall near Goodwin 235.
Please do not hand in assignments at lectures.
Please put your lecture section number next to your name on the assignment.  If you forget to do this, we can't guarantee it will be handed back at the correct lecture.
We will be emptying the boxes no earlier than 9 a.m. on Thursday, April 4.  Consider that an automatic extension until early Thursday morning.
Any assignments not handed in by 9 a.m. on Thursday are late and will not be accepted.

Part 1: Inspection.  Pretend you are working for a software company that uses formal Fagan-style inspections as part of its software process.  You are in an inspection team that has been assembled to inspect a large program and you are given two classes to inspect individually.  Consider these instructions your "kickoff" meeting.  Instead of reporting your findings at a logging meeting, you will need to write them down and hand them in as part of this assignment.

The code you are to inspect comes from a "freeware" program called JMK.  This tool is a Java re-implementation of the Unix "make" tool.  (If you're interested in learning about this program, the full source plus documentation may be downloaded from http://sourceforge.net/projects/jmk, but you need no knowledge of JMK to do this assignment.)  As part of its task, JMK needs to be able to handle lists of file names, sometimes containing wildcard characters.  You will be inspecting three classes:
        Matcher.java: A Matcher object represents a pattern to be matched, possibly containing the wildcard '%', which stands for zero or more characters.  For example, the strings "abd", "abcd" and "abwxyzd" all match the pattern "ab%d".
        StringList.java: abstract data type for lists of strings
        StringUtils.java: contains several static string processing methods.  Uses the other two classes.

In the real world, you might or might not be given more of a specification than this to help you in your inspection.  In this assignment, the comments in the code will serve as specifications of the purpose of each of the methods.  If the purpose of a method is not clear from these comments, that's an issue you should note in your inspection report.

Files You Will Need:
    code listings:
        Matcher
        StringList
        StringUtils
    Inspection Report Template
    Inspection Checklist

While we like to save trees when possible, we highly recommend printing off a copy of the code listing.  It is much easier to inspect code on paper than on a screen.  The code is formatted with line numbers for you to use when logging issues.  The inspection report template is a sample form you may use to report your findings.  You may print it or create a similar form by hand.  Please use a separate page for each of the three classes.  You won't necessarily need all the lines on the page for each class.

The purpose of the checklist is to suggest categories of  issues to consider.  You don't need to limit yourself to these issues; feel free to bring up any other problems or suggestions relating to the code.  For a general suggestion about the whole class, you may leave the line number blank.  Do try, however, to be specific whenever possible.  For example, the general remark "needs more comments" is quite vague and difficult for the author to respond to.  If you write "comments needed to explain processing at lines 10, 42 and 57", this tells the author exactly what sort of additional comments you think are needed.  Remember that issues may be actual defects, but they may also be questions.  Think of inspection as a brainstorming activity in which you try to find as many issues as possible.  If you were part of a real-world inspection team, there would be further steps in the process for deciding which of your issues are actually require action.

One further piece of information: the inspection entry criteria your company uses include the requirement that the code must compile cleanly, and this code as listed does compile.  So you don't have to waste time looking for errors that a compiler would catch (mismatched parenthesis, undeclared variables, etc.)

Part 2: Testing.  Come up with a detailed test plan for testing these three classes.  You do not have to actually test them; in fact, we encourage you not to do so.  This is an exercise in planning test activities, not in carrying them out.  Please incorporate the following elements in your plan:

1. In what order would you test these three classes and why?
2. What kind of supporting software would you write (test drivers, stubs, additional class methods, etc.)?
3. What test data would you use for each class?  Please give specific test cases and your rationale for choosing them.  You should choose your test cases using both the black box and the white box perspectives.  Black box means you must include a sampling of legal, illegal and boundary values, including any special cases mentioned or implied by the specifications.  For white box, you must achieve branch and loop coverage -- for each if statement, there is a test that exercises each alternative, and for each loop there are tests that make the loop execute zero times (if that is possible), one time, and more than one time.

Strings and StringBuffers: The code uses methods from the String and StringBuffer classes.  If StringBuffer is not familiar to you, or if you need a reminder about some of the String methods, you may consult the Java API documentation or the relevant section of the Java Tutorial.

Marking Scheme:
    Inspection: 10
    Test Plan: 10