Project: Flingball (Phase 1)

Your team will be assigned a TA mentor who will help you with your design and help you stay on track as you implement it. You are required to check in with your TA during every team work time class. At this check-in, each team member should describe:

• what they have accomplished since the last check-in
• what they plan to accomplish by the next check-in
• what, if anything, is blocking their progress

Use the check-in to review how each person’s plans fit together and decide how to resolve blocking problems.

Other than reflections at the end of the project, all parts of the project should be committed to the repository you share. Each commit to the repository should have a useful commit message that describes what you changed.

Use the code review skills you’ve practiced on Caesar to review one another’s code during the project. Caesar won’t have your project code loaded into it, however, so you can use in-person discussion or email for these reviews.

You are also strongly encouraged to try pair programming, where two people collaborate on a single computer. Pair programming is a skill that requires practice. Be patient: expect that pairing will mean you write code more slowly, because it’s like code review in real time, but the results are more correct, more clear, and more changeable. You can find plenty of advice on the Internet for how to structure your pairing.

When multiple people contribute to a commit, mention them in the commit message. Your TA will be reviewing the Git log to see individual contributions.

Pull before you start working, commit and push frequently, and don’t break the build!

• Team contract. Before you begin, write and agree to a team contract.

• Understand the problem. Read the project specification carefully.

• Warmup. There is a warmup exercise that your group needs to do, explained below. It will help you learn how to use the physics engine we provide. You don’t have to use our provided physics engine, but you do have to do this warmup exercise with it before deciding to go your own way.

• Design. You will need to create abstract datatypes for various parts of your system: gadgets, balls, boards, and simulator. You will also need to write a grammar for parsing board files, and use it to construct boards with gadgets.

  Your software design is perhaps the most important part of the project: a good design will make it simpler to implement and debug your system. Remember to write clear specifications for classes and methods; write data type definitions for your expression data types; define abstraction functions and rep invariants, and write toString and checkRep; and document safety from rep exposure.

• Test. You should write JUnit tests for the individual components of your system. Your test cases should be developed in a principled way, partitioning the spaces of inputs and outputs, and your testing strategy should be documented as we’ve been doing all along.

• Implement. Write implementation code so that your tests pass. Iterate on the design and tests as needed to make the system work.

• Reflection. Individually, you will write a brief commentary saying what you learned from this project experience, answering the reflection questions. Your reflection may not exceed 300 words, and should be submitted to the reflection form.

Every team member must not only make a substantial contribution to the project, but every team member must make a concrete contribution to every major component of the project.

For example, you may not assign one team member who is solely responsible for the parser.

Contributions include writing specifications, writing testing strategy, writing tests, prototyping, writing internal docs, writing implementation code, fixing bugs, and giving code review feedback. Contributions you work on as a pair or a whole team are great, as long as everyone is involved. Tasks like running meetings, taking notes, and tracking bugs are important, but don’t count as contributions under this requirement.

You must also divide the work such that every team member makes several different kinds of contributions.

For example, you may not assign one team member who is solely responsible for writing tests.

Here is one suggestion for how to break down the work for a 3-person group. Fill in the cells of this grid so that it is a Latin square, i.e. no person is mentioned more than once in each row or column:

Didit will compile your project and run your tests every time you push.

The automated testing page describes how Didit finds your tests, what tests can and cannot do, and how to exclude tests from execution.

You are not required to run any of your tests on Didit, but your project must compile and have a green build on Didit in order to be graded. If it doesn’t build on Didit, your TA won’t be able to build it either.

Flingball specification

Automated testing

Team contract

Reflection

Running Java Programs with Command-Line Arguments