Design a user interface for the following problem. You are encouraged to use state-transition diagrams, screen sketches, entity-relationship diagrams (of the user's view of the program, not necessarily the actual class structure of the code), etc. Try to be as clear, detailed, and unambiguous as you can without writing any actual code.
You are to turn in four things: your UI design, as described above; a user's manual, teaching a user how to use all the major features of the program; a prioritized list of features, suggesting to the implementer which features are most important; and a development log, showing each major design decision you make, when and why. If you change your mind about some earlier decision, this should go into the log too. Please provide each of these by e-mail, so I can easily give them to your implementer as well as grade them myself.
A music player, analogous to iTunes. The human user should be able to keep track of a bunch of audio recordings, organized in one or more ways that make sense to the user, add new recordings to the list, and play them on demand.
In reality, the most important feature of a music player would be the ability to play back recordings. How to do that in Java isn't a central goal of this course, so if audio playback is too much hassle, implementers can de-prioritize it in favor of other goals. OTOH, if you want to give it a try, here'a a simple example of code to play a ".wav" file (which needs to be in the same directory as the ".class" files). For more information, you can look up the Java Sound Tutorial, the Java Sound Programmer's Guide, and a variety of Java-callable multimedia packages; see this Wikipedia page for one such package and a list of alternatives to it.
Write a Java program that implements your classmate's UI design.
Probably the first thing you should do, after reading the design, is to plan a sequence of versions, each adding one feature, based on both the prioritized list of features and implementation dependencies (e.g. if Feature X can't be done without Feature Y, then Feature Y should be in an earlier version than Feature X, even if it's "lower priority"). Each version should be testable in its own right. The actual sequence of versions will probably be somewhat different from the original plan, but it's good to have an original plan.
Design, write, and test each version in turn. Wherever
possible, write automated test cases (e.g. using
JUnit) before writing the code to be tested. For purely
user-interface issues, you can't write test cases in code, but you should still write
a "script" describing exactly what you'll do to test the code, and how the
program should respond, before writing the code itself.
In the course of implementation, you may need to ask your designer for clarification, or propose changes to the design or user's manual. All such changes must be explicitly approved by the designer.
You are to turn in three things: the source code; the user's manual as modified (and annotated to indicate features that you didn't have time to implement); and the development log, to which you have added entries for your own design decisions and milestones.
Write two reviews (say, 1-3 pages each) of your classmate's program. The first review is as a user: run the program, with the user's manual in front of you, and see how well it does what it claims to do. The second review is as a programmer: look at the source code and the development log, and try to understand how the code works. Comment on good and bad software practices you see.