BB Gaming Project 2501 Codename “Ball Breaker”

1. BB Gaming Project 2501Codename “Ball Breaker” J. Fernandez, K. Geiger, D. Lynch, B. Ramaiah CS 535 OOAD Summer 2006 Prof. Craig Reinhart

2. Project Methodology:Loosely Coupled XP • Coordinate through shared workspace • Meet and Communicate as Needed • Before / after class • Weekend Work Sessions (Sat/Sun at CLU) • Email mostly • No pair programming • Reasonable Success • Tool set-up cost 1 week • CVS made source code mgmt transparent • Modeling tools not set up with CVS Fernandez, Geiger, Lynch, Ramaiah

3. Simplified Use Case Model Fernandez, Geiger, Lynch, Ramaiah

4. Master Game States from Use Cases Fernandez, Geiger, Lynch, Ramaiah

5. Initial Design Decomposition Fernandez, Geiger, Lynch, Ramaiah

6. Initial Class Design Fernandez, Geiger, Lynch, Ramaiah

7. Refine Design • Communications Manager – Java RMI • Client/Viewer – Simple Graphics Frame • Accepts input, paints game state on screen • Does no other work • Uses Eclipse Standard Widget Toolkit • Server – Manages game state for clients • HighScore – persistence object Fernandez, Geiger, Lynch, Ramaiah

8. Intermediate Class Model Fernandez, Geiger, Lynch, Ramaiah

9. Game Activities Fernandez, Geiger, Lynch, Ramaiah

10. Master Sequence Diagram Fernandez, Geiger, Lynch, Ramaiah

11. Play Mode Sequence Diagram Fernandez, Geiger, Lynch, Ramaiah

12. As-built Class Model - Server Fernandez, Geiger, Lynch, Ramaiah

13. As-built Class Model - Client Fernandez, Geiger, Lynch, Ramaiah

14. Demonstration Fernandez, Geiger, Lynch, Ramaiah

15. Outstanding Bugs • Network Client Server Bug • RMI distributed client still busted • Tested ten clients run connected to server on same machine – okay • Minor Behavior Bugs • Score count behaviors • When, where balls bounce • Black-Box Test Report (UAT) • http://bbgaming.sourceforge.net/BBGaming_P2501_TestRun_1.xls Fernandez, Geiger, Lynch, Ramaiah

16. Lessons Learned:Programming Language • Selection of Language - Java • Had to learn Java • Tons of help on-line, in books, elsewhere • Worked well with Eclipse and Sparx EA • Java Remote Method Invocation (RMI) • Forced 1 week detour to understand and get working • Probably would have spent same time on protocol • Required Apache Server (late req’t) Fernandez, Geiger, Lynch, Ramaiah

17. Lessons Learned:Development Tools • Eclipse • Lifesaver for Java development • Eclipse extensions forced design changes • Use of Standard Widget Toolkit (org.eclipse.swt) library drove re-design of Client • Single Frame object contains all interface code • SourceForge • Permits multiple users to view and change code • Simple collaborative environment • Still requires management Fernandez, Geiger, Lynch, Ramaiah

18. Lessons Learned:Modeling Tools • Initial Tools • JUDE, ArgoUML • Used Tool – Sparx Enterprise Architect • Code Export and Import • Can sync model with developed code • Permitted “round trip” engineering • Can auto-generate documentation • Build a Model instead of a Series of Cartoons • Model is structured like the software • Export builds directories for software Fernandez, Geiger, Lynch, Ramaiah

19. Lessons Learned:Requirements Management • Never invent requirements • Deciding requirements without the Client complicates development • Just record the Client’s requests and get agreement and clear understanding of them • You Will Find New Requirements From • Prototypes shown to Client • Implications of developing code – e.g. “hidden” test modes Fernandez, Geiger, Lynch, Ramaiah

20. Lessons Learned:Requirements Management • Coordinate Requirements between • Software and Architecture teams • Customer and Software Team • We were less than diligent here • Missed requirements re-found in testing • That’s why you test • Test earlier, oftener • Testing ties Software to Customer Req’s!! Fernandez, Geiger, Lynch, Ramaiah

21. Lessons Learned:Test Plan and Defects • Write the Tests to Match Requirements • Itemize tests by requirement name & id (trace matrix). • One requirement may generate several tests • One test may address many requirements • Test Using the Test • Like requirements, don’t make stuff up. • Write down expected results and apparent reason for test failure Fernandez, Geiger, Lynch, Ramaiah

22. Lessons Learned:Testing and Defect Resolution • Never Debug During Black Box or UA Testing • Test “released” code (the current build) • white-box or unit test during development • Perform the entire test suite as a unit • this is in essence a forced regression test • Larger systems will require automation • Avoid Tense Emotions During Testing • Indicate pass / failure and reasons for failure • Move on to next test • Discuss test results after test suite run-through • Fix the problems, and then retest Fernandez, Geiger, Lynch, Ramaiah

23. Conclusion • Software Project State as of 3 Aug • We have a prototype with bugs • We’d be at UP Cycle Elaboration 1 or 2 • We have a major defect in core design due to RMI • Next Steps Are • Clear up RMI bug: fix it or re-factor to another method • Fix any game play bugs – arrow controls, ball bounces • Tighten white-box unit tests • Re-deploy and re-run UATs Fernandez, Geiger, Lynch, Ramaiah

24. Nice-to-Have or Nice-to-Do Next • More Practice at Round-Trip Modeling • Model to Java • Java back to Model • Move the Model into CVS • Shareable modeling environment to match shareable software environment • Better use of SourceForge for • Requirements Management, Feature Requests • Bug tracking and Defect Resolution • Deployment Package • Software auto-deployment • Help/user documentation Fernandez, Geiger, Lynch, Ramaiah

25. Source Materials • SourceForge Site • https://sourceforge.net/projects/bbgaming • Project Web Site @ SourceForge • http://bbgaming.sourceforge.net/ • CVS Repository (Read-Only) • cvs -d:pserver: anonymous@bbgaming.cvs.sourceforge.net:/cvsroot/bbgaming login Fernandez, Geiger, Lynch, Ramaiah