Informatics 43 Spring 2009
Course Project
Phase 3: Implementation
Due date and time: Wednesday, May 27, 9:00pm
Background
Now that your design of the Triple P Enrollment System (TPES) is completed, it's now time to try to implement it. Of course, as we've talked about in lecture, up-front designs are rarely implementable without at least some changes; as you work on your implementation, it is not uncommon to discover that there are aspects of your design that are incomplete or incorrect, that things don't fit together the way you expected, that information you need in some class is missing, and that constraints arise that you hadn't planned for. With experience, these kinds of mistakes become less common, especially if you reflect on how your implementations diverge from your designs and why. This phase will encourage you to do that.
As with your design, your implementation should ultimately be guided by the Official Requirements Specification, which lists all of the known requirements for TPES. Only some of those requirements will be required, though you can take your implementation farther, if you'd like, with a modest amount of extra credit offered as a reward for your time.
Additionally, as you do your work, you'll be encouraged to do at least some unit testing, by writing unit tests in Java using JUnit. You will not be required to unit test all of your code, but I do want you to have the experience of at least doing some of it.
To be fair, I should warn you that this phase will be quite a bit of work. However, if you pace yourself and work on it steadily until the due date, I expect that you'll be able to finish it. If you put it off until a few days before it's due, you may find it difficult to complete it.
The program
Your program is required to implement all of the requirements that comprise Implementation Phase 1 in the Official Requirements Specification. A modest amount of extra credit will be offered for covering requirements in Implementation Phases 2 and 3, with more extra credit offered for covering more of the requirements. We'd prefer that you avoid Implementation Phase 4, since it involves additional software (e.g., a database engine) that is well beyond the scope of the work we're requiring.
In general, you should use your design as a starting point for your work in this phase. However, you are permitted to make changes as you discover that they're necessary; it is unlikely that you will be able to implement your design as-is. Don't make these changes willy-nilly; as is discussed below, you'll need to let us know what changes you've made and why.
A note about working incrementally
Incomplete programs that don't run will be viewed much more harshly than incomplete programs that run and address at least some requirements, since your customer will not be able to verify that any part of a non-running program is working. Not finishing the implementation because you ran out of time is one thing; writing a program that can't run at all is quite another.
Because of the importance of having a program that runs, I strongly suggest working on the program one or a few requirements at a time, getting those requirements implemented, tested, and working before moving on to subsequent requirements. Each time you reach a stable point, where some subset of the requirements are working, save a backup copy of the entire program, along with a list of which requirements are working. This way, if your subsequent work leads you to a problem that seems insurmountable, you can always go back to the way things were. If you run out of time before you can finish your implementation, you can submit your last stable copy.
The unit tests
During an implementation, unit tests are often written. Unit tests focus on testing individual components (e.g., single classes, single methods, single algorithms) of a program out of context, verifying that they work on their own. Note that the ability to test components out of context — without having to worry about the effect of other, related components — has an effect on the design of your classes; some designs are more testable than others. We'll talk about this issue at some length in lecture.
Requiring you to write unit tests for your entire implementation would place an enormous amount of work on your shoulders; instead, you are required to write unit tests for only the following two algorithms:
Be sure that you're covering all of the interesting cases involved. Neither of these algorithms requires a huge number of tests, but neither can be sufficiently tested with only one or two test cases either.
You are welcome to write unit tests for any other part of your implementation, if you'd like; they can be especially effective for the trickier parts, where you would otherwise have to do a lot of manual testing. (Unit tests can seem like a lot of work, but when compared to the work of testing the program in its entirely, their difficulty is often overrated.) However, no additional unit tests are required.
Your unit tests must be written to be compatible with JUnit 4, as it is supported in Eclipse Classic 3.4.2, which is available at this link. All of your unit test classes (i.e., classes containing JUnit unit tests) should have a name ending in the word Test (e.g., StudentEnrollmentTest), so that they can be easily distinguished from the other classes that comprise your program.
Reflecting on your implementation
As you work on your implementation, maintain a list of the places where your implementation differed from your design (e.g., a method you included in your design ended up in a different class, a method needed an additional parameter than your design specified, a class in your design was split into more than one class in your implementation, etc.).
When you've completed your implementation, write a short document that will apprise your customer of your progress. Your document should address the following questions:
Be sure to save some time to write this document before you submit this phase. Note that the document does not need to be long in order to adequately address the questions asked, so don't worry that this will become an overwhelming part of the assignment. The more notes you keep as you work — especially regarding design elements changed, requirements addressed, and bugs found — the easier this part will be. (You may opt to write this document piecemeal as you implement your program; that's fine, too.)
Development environment
You are permitted to use any development environment you'd like — from a text editor and a command-line compiler at one extreme to a full-featured development environment like Eclipse or NetBeans at the other. Whatever environment you use, you should write only standard Java, which can be compiled and run on Java SE 6; your program should not require an environment like Eclipse or non-standard libraries or extensions (other than JUnit, which you'll need for your unit tests).
I suggest Eclipse Classic 3.4.2, which is available at this link. If you choose to use Eclipse, you might find the following preconfigured workspace of use:
When we grade your work, we will be using Eclipse Classic 3.4.2 and the Informatics 43 Eclipse workspace.
Deliverables
You are required to submit the following deliverables:
Follow this link for a discussion of how to submit files via Checkmate, an ICS-built online assignment submission system. Be aware that I'll be holding you to all of the rules specified in that document, including the one that says that you're responsible for submitting the version of the specification that you want graded. We won't regrade your work simply because you submitted the wrong version accidentally.