1 / 25

Development Insights from the Ball Breaker Gaming Project: A Case Study in Java

The Ball Breaker project, led by J. Fernandez, K. Geiger, D. Lynch, and B. Ramaiah during the Summer of 2006, serves as a compelling case study in software development methodologies, particularly through the lens of loosely-coupled Extreme Programming (XP). The team adopted a collaborative workspace, engaged in weekend work sessions, and utilized Java RMI for server-client architecture. This report highlights the lessons learned, including the importance of clear requirements management, the utility of Eclipse for development, and the need for rigorous testing practices. This project reflects both the achievements and challenges faced in game development.

darryl
Télécharger la présentation

Development Insights from the Ball Breaker Gaming Project: A Case Study in Java

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related