Project 3.1: Design Document for a GUI Program

For Project 3, you and your team will develop a GUI application using Java and JavaFX. The key areas of attention for this project will be:

• Designing a user interface carefully, with attention to the needs and welfare of your intended audience.
• Planning and implementing a thorough suite of unit tests.
• Organizing your code around the Model-View-Controller (MVC) design pattern (or one of its close pals such as Model-View-Presenter).
• Applying what we have learned about high quality routines, good coding style, appropriate use of comments, etc.

The schedule for this project is pretty compressed; you really only have two weeks to complete it. You should spend the first half of 9th week designing, the second half writing your tests and preliminary implementation, the first half of tenth week getting feedback, and then the last days of the term finalizing your project. There are only three phases:

• Phase 1 (Wed 5/27 @ 10:45am): this project proposal.
• Phase 2 (Tues 6/2 @ 3pm): first complete implementation of your application, so we can do code reviews in class on Wed 6/3. As part of this phase, you will also do a couple Krug-style user tests on your own time, and hand in evidence of your user tests in class that Wednesday.
• Phase 3 (Mon 6/8 @ 5pm): final submission of the project.

Let me reiterate: you've only got two weeks! So aim for a project that you can complete in the time that you have. It's way better to write a finished and polished version of a small thing to have a half-broken version of something big and ambitious. The grading will reflect this perspective.

Almost any GUI program can be organized successfully around MVC. However, one of my main goals for this project is to give you a non-trivial experience with MVC. With that in mind (but also remembering the deadline of June 8th), I want your program to have a Model that is at least complex enough to warrant at least two distinct major features in the View.

One way to start thinking about your idea's Model is to ask a couple questions: “What are the main things in my program that could be made into Java classes or interfaces, and then aggregated in my Model?” Or alternatively, “Of what information does the current state of my program consist while it's running?”

You're free to build whatever kind of desktop GUI application you'd like, so long as it meets the expectations of sophistication and organization laid out here. On a separate page, I have some examples of programs that might fit the bill, along with descriptions of how to think about their Models and Views.

Create a PDF similar to the one that your created for Project 2 in Phase 2 and Phase 4. Your design document should include the following:

• Brief description. Write a short paragraph of prose telling me what you're building.
• Feature list. Write an ordered list of features, from most fundamental / easiest / basic features to least important / hardest / stretch goals.
• Mockups/storyboards of your GUI. These don't need to be very involved (nor visually detailed), but I need to see how users will interact with your program to accomplish tasks.

• Software architecture diagram. This doesn't have to be as detailed as the one for Project 2; just show the large software components (classes and major methods) and how they interact.

  Clearly designate which components are part of the Model, which are part of the View, and which are part of the Controller. Remember that an MVC application doesn't need to have a class called “Model” and another called “View”; instead, these are just conceptual categories that may or may not be appropriate to concretely represent with corresponding classes.

  Take cues from the diagrams in the “Head-First Design Patterns” book for how to depict inheritance and composition. If you need to split your diagram into several pieces, or to show one diagram for composition/inheritance and another for data interactions, that's all fine.

• Signatures of major software components. Tell me inputs, outputs, behavior, exceptions, preconditions, side-effects, super-classes, etc. As in the architecture diagram, this doesn't have to delve into the nitty-gritty; just cover the major pieces of your software system.
• Tests. Make a bulleted list of the components that you will write unit tests for. For at least one of these, make a list of specific test cases.

Make a repository for your group to share, and share it with me and the graders.

Push your PDF (and the source document for it, particularly if you write it using LaTeX) to your repository, tagging your commit with phase_3_1.