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

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

Fernandez, Geiger, Lynch, Ramaiah Simplified Use Case Model

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

Fernandez, Geiger, Lynch, Ramaiah Initial Design Decomposition

Fernandez, Geiger, Lynch, Ramaiah Initial Class Design

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

Fernandez, Geiger, Lynch, Ramaiah Intermediate Class Model

Fernandez, Geiger, Lynch, Ramaiah Game Activities

Fernandez, Geiger, Lynch, Ramaiah Master Sequence Diagram

Fernandez, Geiger, Lynch, Ramaiah Play Mode Sequence Diagram

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

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

Fernandez, Geiger, Lynch, Ramaiah Demonstration

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

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

Fernandez, Geiger, Lynch, Ramaiah Lessons Learned: Development Tools Eclipse Lifesaver for Java development Lifesaver for Java development Eclipse extensions forced design changes 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 Permits multiple users to view and change code Simple collaborative environment Simple collaborative environment Still requires management Still requires management

Fernandez, Geiger, Lynch, Ramaiah Lessons Learned: Modeling Tools Initial Tools JUDE, ArgoUML JUDE, ArgoUML Used Tool – Sparx Enterprise Architect Code Export and Import 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 Build a Model instead of a Series of Cartoons Model is structured like the software Export builds directories for software

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

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

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

Fernandez, Geiger, Lynch, Ramaiah Lessons Learned: Testing and Defect Resolution Never Debug During Black Box or UA Testing Test “released” code (the current build) Test “released” code (the current build) white-box or unit test during development Perform the entire test suite as a unit Perform the entire test suite as a unit this is in essence a forced regression test 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 Indicate pass / failure and reasons for failure Move on to next test Move on to next test Discuss test results after test suite run-through Discuss test results after test suite run-through Fix the problems, and then retest Fix the problems, and then retest

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

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

Fernandez, Geiger, Lynch, Ramaiah Source Materials SourceForge Site Project Web SourceForge CVS Repository (Read-Only) cvs -d:pserver: cvsroot/bbgaming login cvs -d:pserver: cvsroot/bbgaming login