Informatics 122 Winter 2013
Project #2: Who's Gonna Ride Your Wild Horses? (Implementation)

Due dates and times
Wednesday, February 6, 11:59pm

This project is to be done individually


The previous project focused on learning about how to communicate the details of a software design to others, then gave you a chance to share your design with others and receive feedback on it. For some of you, this may have been the first time you've had peers review your work in a lower-risk way than when you've been graded by TAs and instructors. It may also have been the first time you've been confronted head-on by the experience of watching someone else respond to your work right in front of you. If you're accustomed to being insulated in your own world, working on projects in the safety of your own mind, it can be jarring to get this kind of feedback, especially in-person, but it can also be hugely instructive, because it's sometimes hard to see around your own biases.

A big focus in writing up and diagramming your design in the previous project was finding an understandable way to communicate its details, and your peer reviews should have given you an early indication of how well you did. Each of you has probably found ways you could improve the next time, and that's why you're here.

It's important to note that this isn't just a classroom technique. This kind of interpersonal feedback process is actually quite common in the software industry and in open source projects, where design reviews and code reviews are done at many different stages of the design and implementation of real software. It is critical that you develop your skills at communicating technical details with others, with offering feedback tactfully but technically, and with accepting well-intentioned feedback without taking it personally.

In the end, you were asked in the previous project to evaluate designs belonging to three other students, and to write up your findings. We also asked you to rank-order the three designs, ultimately forcing you to choose a favorite. This project asks you to own that decision, by requiring you to implement the design of the three that you thought was the best. It will also ask you to reflect on your decision after the fact, and consider whether you believe that you made the right one; once you have to live with your favorite design for a while, do you still think it will be your favorite?

Implementing a design in Java

One of the key takeaways from your peer design reviews was a decision about which of the three other students' designs you thought, given all the various factors you considered, was the most implementable. You ranked the design 1st, 2nd, and 3rd. Now we'd like you to put your "money where your mouth is," so to speak, by implementing the design that you ranked above the others. To be clear, we are specifically disallowing you from implementing your own design; instead, you'll be implementing the design that you ranked 1st.

Your goal here is to implement your favorite of the other students' designs in Java. You must implement it as faithfully as possible, even if you think another approach is better than the one the other student chose. The only changes you are permitted to make to the designs are when the design simply cannot be implemented as specified and still meet the requirements. In these cases, you will be required to justify that decision in writing, and we will exercise some scrutiny during the grading process over whether we think that your decisions were correct.

Of course, to make this part of the project interesting, your end result will be a complete program with a primitive console-mode user interface. Think of it as a test harness that will allow you to exercise your engine. To save you a significant amount of time, that user interface is being provided for you.

What you'll need to do is hook the design you've implemented into the user interface, so that the whole program runs; though I can't rely on the details of the design you'll be implementing (since everyone is potentially implementing a different one), I've left "seams" in the user interface that will allow you to integrate your chosen design with it.

Rather than provide an exhaustive list of details of what you'll need to do, I've left comments containing the word Inf122TBD in strategically-located places in the user interface where you'll have integration work to do. The provided code is on the order of fifty Java classes in six packages, but you'll find that it's not nearly as overwhelming as it sounds; most of the classes are short, and many of them you'll never have to look at in detail. (One of the skills you need to begin developing, if you haven't already, is the ability to take someone else's code and understand enough about its design and implementation that you can integrate it with code of yours. This project might be your foray into that.)

User interface commands

The complete program is to be a console-mode user interface that supports the following set of commands:

Command Information

TAKE - Sets the "take" for the racetrack at a particular whole-numbered percentage between 0 and 100

TAKE <takePct>


  • TAKE 15: sets the racetrack's "take" to 15% of all pools

RACE - Creates a race to be run, including a list of horse numbers for the horses that will run in the race

RACE <race#> <horse#> [<horse#> ...]


  • RACE 1 1 2 3 4 5: Creates race number 1 with horses numbered 1, 2, 3, 4, and 5
  • RACE 4 1 2 3 7 10: Creates race number 4, with horses numbers 1, 2, 3, 7, and 10

POST - Specifies that post time for a particular race has been reached. Subsequently, no bets will be accepted on that race

POST <race#>


  • POST 3: Post time has been reached for race 3; no more bets on this race will be accepted

RESULTS - Specifies the results of a race after it has been run. The only relevant results are the top three finishers, so those are the only ones to specify as parameters to this command.

RESULTS <race#> <firstHorse#> <secondHorse#> <thirdHorse#>


  • RESULTS 5 7 3 8: In race 5, horse 7 finished first, horse 3 finished second, and horse 8 finished third

WIN - Places a bet on one or more horses to win a particular race. Displays the ticket ID and the total amount of the bet.

WIN <race#> <amountPerHorse> <horse#> [<horse#> ...]


  • WIN 3 20 8: Bet $20 on horse 8 to win race 3
  • WIN 4 100 3 9 7: Bet $100 each on horses 3, 9, or 7 to win race 4

SHOW - Places a bet on one or more horses to show in a particular race. The format and behavior of this command is in the same spirit as the WIN command above.

PLACE - Places a bet on one or more horses to place in a particular race. The format and behavior of this command is in the same spirit as the WIN command above.

CLAIM - Registers a claim on a ticket and displays the payout for the ticket, if any. This is only allowed after a race has been run and results have been registered with the RESULTS command.

CLAIM <ticketID>


  • CLAIM 1234567: Registers a claim on ticket ID 1234567

CANCEL - Cancels a ticket, removing any bets from the pool. This is only allowed before post time for a race.

CANCEL <ticketID>


  • CANCEL 1234567: Cancels ticket ID 1234567

POOL - Displays the amounts of money on each horse/combination in a particular pool for a given race.

POOL <betType> <race>

The betType parameter is one of the following: WIN, PLACE, SHOW.


  • POOL WIN 3: Displays how much money has been bet on each horse to win race 3
  • POOL SHOW 8: Displays how much money has been bet on each horse to show in race 8

STOP - Stops the program

Using Git as your version control system

One of the requirements in this part is that you use Git — or EGit, if you're using Eclipse, which is a plug-in that provides the same functionality that Git does, but in a graphical form that integrates nicely with Eclipse's user interface — while you work through your implementation. For all of the reasons we talked about in lecture, version control is a hugely important part of the development process, with Git being a great example of a modern tool for development of all shapes and sizes (small, individual projects like this, all the way up to large, geographically-distributed team-based development). Especially if you haven't used version control before, this is a great chance to become accustomed to it in a relatively forgiving environment.

Rather than submitting your code to us, you'll be submitting a Git repository (i.e., a .git directory) to us, along with your entire commit history from the time you started your implementation — warts and all! While we aren't planning to look through your commit histories with a fine tooth comb, we do expect to see that you were using Git throughout your implementation process. We'd expect to see many commits that are relatively granular and have (at least) brief comments on them; comments should focus not just on what is being committed, but the more important issue of why. We imagine that there will be things you tried that worked out and things that didn't, and that's fine; nobody writes code exactly the way they want it the first time. You may feel that you're having your creative process exposed this way, and perhaps that makes you feel uncomfortable, but this is exactly what happens in most professional and open source projects: there's a source code repository and everything is in it, for better or worse, as even mistakes and regrettable decisions are things that everyone can learn from.

Part of your score on this project is the completeness of the repository. The best way to address this is to embrace Git and use it along the way; almost any attempt to "fake it" after you're already done, or by committing code haphazardly once in a while to make it "look good" is going to be quite obvious when we look at your repository, and you can expect to lose some credit on this project in such a case.

Post-mortem documentation

Along with a Git repository, we'll also be asking you to submit a post-mortem document that details some things about your experience. Focus on these issues:

Using EGit with Eclipse

Installing EGit in Eclipse

You can feel free to use the command-line Git tool if you prefer, but for those of you who will be most comfortable using Eclipse, it will make a lot more sense for you to use EGit instead. The following instructions will explain how to get the EGit plug-in installed into your Eclipse installation. (This turns out to be a little bit tricky — it took me a handful of tries to get it right, mainly because different versions of EGit are sensitive about which versions of Eclipse they're compatible with — so I wanted to be sure that you didn't have to waste too much time on it.)

First of all, I'll assume that you're using Eclipse Classic 4.2.1. Feel free to use another installation, if you prefer, but you'll be on your own as far as getting EGit working.

Follow these steps to get EGit installed into Eclipse Classic 4.2.1.

Getting started with EGit

One of the things I noticed about EGit is that its documentation — at least the documentation I was easily able to find — is not quite up to date. For example, there is an "EGit User Guide," but its screenshots and advice do not appear to match the current version. For that reason, I'm providing a quick primer here on getting started with EGit. I'll leave some details for you to figure out — because that's one of the things you face whenever you use new tools, and I don't want to take that experience from you — but I'd at least like to be sure you get off on the right foot.

First of all, it's important to understand that, underneath the covers, EGit is doing all the same things that the command-line version of Git does. There are still commits with hashes associated with them, changes can still be staged (and unstaged), branches and merges are supported, you can place tags on individual commits, and so on. The only difference is that the commands you might normally type from a command prompt are inside being executed via the user interface. So the things you may have read already in Pro Git still apply here. And when you occasionally find that you want to do something more esoteric that isn't supported in EGit, you can always drop back to using the command-line tool instead.

Follow these steps to create a new Git repository using EGit, set up an Eclipse project to use that repository, and commit the empty Eclipse project into it.

If you've gotten this far, you're good to go! From here, feel free to check out the EGit User Guide, which, while somewhat out of date, will give you a reasonably good overview of what kinds of things you can do with it.


You will submit three deliverables to satisfy this part of the assignment, both of which are due on Wednesday, February 6, at 11:59pm.