CS 257: Software Design

Final Project, Phase 1 of 2

If possible, please work with a partner. Groups of three are also fine. If you would prefer to work alone, that's OK. If you would like help finding a partner, contact me on Slack.

For the final project, you will develop a GUI application using Java and JavaFX. The key areas of attention for this project will be:

Choosing a program

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 November 19), I want your program to have a Model that is complex enough to warrant at least two different kinds of 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? The following examples illustrate that way of thinking.

Example: Simulations

John Conway's Game of Life describes a simple system of rules modeling birth and death of cells in a 2D grid. Conway's rules generate beautiful and fascinating evolution of populations. The Game of Life was one of the earliest examples in the general category of cellular automata.

You might create a program that runs Game of Life simulations, but also collects running statistics on the simulation. For example, one View could show the population of cells, while another could show a graph over time of the population density.

There are lots of other cool things to do with simulations, cellular or otherwise. This predator-prey simulation, for example, allows the user to specify birth rates and death rates of two interacting species, and has both a view of the full current population and a graphical view of population levels.

Similarly, a program that generates Julia sets based on user-entered parameters, or that allows the user to explore the Mandelbrot set, could give you simultaneous views at more than one level of resolution.

There are lots of simulation-style games. How about a garden-building program where the user plants various plants and they grow (or die) as time goes on depending on whether the user waters and feeds them appropriately, etc.? Or a tiny SimCity?

Do you like thinking about Newtonian mechanics? You could simulate the gravitational interactions in a 3-body problem with user-specified initial masses, positions, and velocities. Again, one View would show the bodies in motion, while another could graph each body's speed or kinetic energy or the current distances between bodies or something else interesting.

Example: Arcade-Style Games

Many arcade games have a non-trivial game state. Tetris, for example, has a Model consisting of a list of pieces, a current score, an upcoming piece, a historical list of high scores, etc. Views include the main board, the picture of the upcoming piece, and so on.

An Asteroids Model might have a list of rocks, a spaceship, and a list of bullets, plus high scores, etc.

Example (more complex): Desktop Utility With Server-Side Database

NOT RECOMMENDED unless you have a lot of free time and are fired up about a project like this.

Consider a program for reading and posting to a simple on-line forum. What things is such a program concerned with? Users, posts, discussion threads, and ratings. There might be other things, but those are probably the heart of the program's model. They all might be stored in a database on the server, but on the client side they will each deserve a class of their own (User, Post, etc.). Then the client-side Model might consist of, say, the current User and a List<DiscussionThread> (which in turn might include a List<Post>).

What Views would this project need to show Model content? A View for a list of discussion threads, a View for a list of posts in a given thread, and perhaps a View for the contents of an individual post.

That's plenty of variety to give you a thorough opportunity to grapple with MVC's ins and outs.

This sort of program has the additional complexity of having both a Java client and a server side to provide access to the database, so make sure you're ready to deal with that. If you are, then some other possibilities include calendars, to-do lists, and similar utility applications.

Getting started

Once you have decided on a project and written a brief and clear description of it, you'll need to determine classes that make up the Model and the main Views. For example, if you're doing an Asteroids game, you might have Asteroid, Spaceship, Bullet, and Scoreboard classes, and a Model class to aggregate these other classes into the game state. The functional interfaces for these classes will be pretty straight-forward to describe in most cases. For View classes, you might have a GameBoard or Starfield class as the main content view of the game, a StatusView panel for showing the current score and other statistics, and so on.

In addition, in most projects you'll want to include serialization: that is, the ability to save the state of your project in a file or database and load it later (including on next launch). Java has serialization support built in, and there's a nice serialization tutorial here.

Note that in some cases, given the structure of JavaFX programs, you may want the components of your Model to double as Nodes in the JavaFX Scene. For example, it's possible to be strict about separating Model and Views by having a Spaceship class to store facts about the spaceship (e.g. position, rotation, velocity, etc.) and also a SpaceshipNode class that inherits from Node and refers to Spaceship for its data. On the other hand, that level of strictness ends up with redundant data (e.g. both the Spaceship object and the SpaceshipNode would contain a "position") and redundant interfaces (e.g. getPosition). In such cases, it's typical to just let Spaceship inherit from Node even though this has the effect of merging a portion of the Model (i.e. info about spaceships) with its Views (i.e. the Nodes representing the spaceships visually).

Handing in Phase 1: description and architecture

For phase 1, update your github repository with the following, and tag it final_phase1.