Project 1 Feedback

Here are some of the problems I found in Project 1:

1. Some people had problems with basic Java2 issues like creating an executable jar file or reading in a file using Java2 constructs. If the compiler is telling you that a class is deprecated, you should pay attention to this message and check your Java2 book for an alternative. If your Java2 book is silent on the issue, you may need to investigate other sources. I have provided links several times this semester to online Java resources, and you can also do a net search on your own.

2. More effort needs to be focused on basic design practice. Several students did not even design a class to represent a question. Every design for this application that is created in proper object oriented style should contain a Question class. Several programs appeared to be written without a thought as to future expansion. Write your program as if you will have to give it to another student to expand during the next assignment. (Who knows, this might happen!)

3. Some people do not think carefully about whether classes and methods should be public, private, or protected. If you are not familiar with this important concept of access control, you should review it in your Java2 book.

4. Much more effort also needs to be focussed on testing. This appears to be a new skill for most of you, so you should just keep practicing and you'll get better at it. In this project, I am requiring you to turn in your test cases with your project package. I expect you to create at least a dozen or so test case files to cover the requirements for Project 1, plus at least another dozen or so to cover the requirements for Project 2.

5. Several people did not fill out time data correctly. Every time entry should have the doc type field filled in, and you should proceed from design to planning to implementation to testing to postmortem without ever "backing up" to a prior phase. Any redesign you do during implementation is still implementation as far as the phase goes. You start the "testing" phase once the system is completely implemented and you begin running your full test case suite. One person typed in the phases rather than using the mouse, and did not capitalize them correctly so they did not show up in the condensation. The moral is to use the Mouse, Luke :-).

6. Several people seemed surprised when I opened Naia or Hee and did not find all of the required data. You should check to make sure you have saved out all of your data. We have changed the design of Hee in direct response to Project 1 to eliminate the "Update" button, which appeared to be responsible for some of this problem. In the new version of Leap, when you close Hee, the data is automatically written back into Leap. You will still need to "save" your data into the 613-data.leap file, of course.

7. Some people violated the coding standards. Don't. This will reduce your grade.

8. Some people included extra files in their package. Don't. Include only the requested material, please.

9. It is good to include debugging code. You should wrap your debugging code in a conditional, and use a static boolean variable called "DEBUG" to turn debugging on and off. It is lame to use comments to turn debugging on and off. A more advanced approach is to use a development environment that includes a stepping facility such as JDB. For example, Emacs includes a "jde" mode with integrated support for debugging Java under JDB.

10. Many people begged me to tell them what test cases would be run on Project 1. One person even accused me of being mean for not providing the test cases to the class. What you need to understand is that if I provided my test cases to you, then you would design software that might run correctly on just my test cases, but that would be it, and many other problems that I didn't test would slip through. Thus, the fact that the software successfully runs on the test cases doesn't really say anything about the quality of the software. On the other hand, if you design and implement a system that successfully passes a set of test cases that you don't know about in advance, then this indicates much more strongly that your program is of high quality, and would work correctly on a much broader set of test cases.

    However, I also want to help you learn about writing test cases, and so I have decided to publish the specifications for the test cases I ran on your Project 1. You definitely should implement these cases yourselves and make sure your software passes them, because I will run your future projects over these cases (as well as new ones).

    Each of the following test cases are prefaced by a number. In the feedback sheet I will give you on Project 1 during your module 05 interview, I will list which tests your program failed on by this number. In the following list, I have made a few of the cases links to the actual test file I used. First, the cases containing some sort of error:

    • 01: Nonexistant file passed on command line.
    • 02: Empty file passed on command line.
    • 03: File containing misc text.
    • 04: File containing no :TYPE declaration.
    • 05: No command line args
    • 06: Bad command line args
    • 07: Bad declaration argument (missing :TYPE) (same as 04)
    • 08: Bad declaration argument (:TYPE:A)
    • 09: Missing required declaration (:CAT)
    • 10: Missing required declaration (:TITLE)
    • 11: Missing required declaration (:QUESTION)
    • 12: Missing required argument (:CAT no arg)
    • 13: Missing required argument (:TITLE no arg)
    • 14: Undefined argument (:QUESTION with arg)
    • 15: :QUESTION without text field.

    And here were the valid cases:

    • 50: 1 question, OK.
    • 51: 1 question, minimal attributes (no optional declarations)
    • 52: 1 question, maximal attributes (all optional declarations)
    • 53: 1000 questions, maximal attributes
    • 55: 1 question, replicated, all orderings of attributes.
    This was by no means an exhaustive test suite, but it seemed to be "good enough" in the sense that only 1 student's program passed all of them successfully.

    Note: I found it extremely convenient to create a batch file that ran each of the cases sequentially, pausing after each one so I could check the output. I highly recommend you build your own batch file for this "regression testing" purpose that you maintain and enhance during the semester. Here's what mine looks like (for the Windows platform):

    rem Test file for Program p1
    set P1=lixinz-P1
    rem Test nonexistant file
    java -jar %P1%\%P1%.jar -qa tests/t00.qa
    pause
    rem Test empty file
    java -jar %P1%\%P1%.jar -qa tests/t02.qa
    pause
    rem Test file containing misc (illegal) text
    java -jar %P1%\%P1%.jar -qa tests/t03.qa
    pause
    rem Test file containing no :TYPE
    java -jar %P1%\%P1%.jar -qa tests/t04.qa
    pause
    rem Test missing command line args
    java -jar %P1%\%P1%.jar 
    pause
    rem Test bad command line args
    java -jar %P1%\%P1%.jar -qb tests/t50.qa
    pause
    rem 1 question, missing :TYPE
    java -jar %P1%\%P1%.jar -qa tests/t07.qa
    pause
    rem 1 question, :TYPE:A (bad param)
    java -jar %P1%\%P1%.jar -qa tests/t08.qa
    pause
    rem 1 question, missing :CAT
    java -jar %P1%\%P1%.jar -qa tests/t09.qa
    pause
    rem 1 question, missing :TITLE
    java -jar %P1%\%P1%.jar -qa tests/t10.qa
    pause
    rem 1 question, missing :QUESTION
    java -jar %P1%\%P1%.jar -qa tests/t11.qa
    pause
    rem 1 question, :CAT no arg
    java -jar %P1%\%P1%.jar -qa tests/t12.qa
    pause
    rem 1 question, :TITLE no arg
    java -jar %P1%\%P1%.jar -qa tests/t13.qa
    pause
    rem 1 question, :QUESTION with arg
    java -jar %P1%\%P1%.jar -qa tests/t14.qa
    pause
    rem 1 question, :QUESTION no text field
    java -jar %P1%\%P1%.jar -qa tests/t15.qa
    pause
    rem 1 question, OK, -list
    java -jar %P1%\%P1%.jar -qa tests/t50.qa -list
    pause
    rem 1 question, maximal attributes, -list 
    java -jar %P1%\%P1%.jar -list -qa tests/t52.qa