1. The LAST Recitation
Godfrey Tan

2. Only a few things left to do in this class!
Quiz 2 Review – Sunday
Quiz 2 Wednesday April 10
Project
TA assignments and scheduled weekly meetings (coming up soon)
Spec coming out by Friday night

3. Go home and get some sleep
See ya!

4. PS 6 Review LoadButton(JFrame f)
// Creates a new instance of Load Button
void actions(JFrame f)
// requires: f instanceof JFrame
// effects: Adds an action to create // a LoadFrame when this
// button is clicked.
Sloppy spec I found from one of my students!
Is LoadButton(Jframe f) a class? What does it extend?
The requires clause doesn’t tell you anything!

5. PS 6 Review public void actionPerformed(ActionEvent e)
// modifies: this, tracker representation
// effects: traps toolbar button clicks
// traps clicks on the toolbar button
// and dispatches methods accordingly.
// updates the UI where necessary.
// Signals the FolioRunner class to
// spawn/destroy folio windows as
// necessary.
// sets the modified flag if the tracker
// is modified.

6. Questions Changes made to PS5? Turned in PS5 code?
Gizmoball or Anitchess?
Does meet your expectations?

7. Decentralized Organization
Jointly make key decisions
e.g. spec and Java interfaces
Checkpoint meetings with a leader and an agenda
e.g. resolve problems, track progress, code review

8. Preliminary Design Specify requirements, design document
Schedule work, sleep
Say “NO” to caffeine
Divide up the work into well-defined parts
Use Java interfaces!!!
Plan to redistribute work when something bad happens
Backup often!
Use CVS (~6.170/www/info/tools.html)

9. What you should have
Turn vague requirements in project handout into a concrete requirement list
Design overview and rationale
Flexibility is important: plan for your project amendments!
Explain your ADTs and the algorithms you plan to use
MDD of main modules
Partial specifications of all public methods in each module. Complete spec for final report.

10. What you should have Validation strategy: e.g.
chkRepInv() at beginning and end of public methods
Costly checks should be done in unit tests
checked vs unchecked Exceptions
Messages should explain why exception was thrown
Use abstraction function when a class is implemented by more than one person
Use stubs/state machines

11. Incremental Model Design and redesign Implement
Validate (Unit Test and Integration)
Go back to 1
Start with depth-first implementation of basic functionalities, then add more complex ones.

12. Development Stage Choose common platform and environment
Athena, Forte, etc.
Stick to the API specified in the design stage
Document your amendments (what and why)
Inform your partner of any major changes immediately
Unit testing
Code review
Integration testing

13. When program crashes
Find the bug; keep in mind that there could be more than one bug
Do NOT point fingers especially when bugs are found during integration testing
It’s teamwork; help fix the bugs
Help each other LEARN

14. Debugging Reproduce the bug
Form hypotheses and try to isolate the code that has the bug
Use binary search to pin-point the bug
Be optimistic that you will eventually find the bug
Ask help from your partner and eventually your TA
Remember to take frequent “snapshots” of your project so you can roll back when all else fails!

15. When schedule slips Isolate the problem
Find ways to adjust the rest of the schedule by
cutting features or sleep
Tell your TAs about un-cooperative partners
But keep in mind, your partners are all you’ve got

16. Final words Remember- your goal is to build the software that works
Everything you have learned in is to help you achieve that
Best way to learn programming is by programming
When you are getting better at it, you receive more satisfaction and might actually enjoy being a programmer/engineer

17. Good luck!
May the force be with you!