Network Programming using JavaFX UI Worksheet

Project Deliverable 5 Personal Software Process & Quality (PSP2, Network Programming) Points: 50 —————————————————————————————————Instructions: This assignment has to be completed by each student individually. NO COLLABORATION IS ALLOWED. Submit the following: YourASURiteID-ProjectDeliverable5.zip This compressed folder should contain the following files: 1. Source Code files: a. RPSClient.java (with JavaFX UI) b. RPSServer.java c. Any other additional java files you may have 2. Documentation folder containing a. JavaDoc documentation files (index.html and all other supporting files such as .css and .js files generated by the tool). 3. Completed Time Log, Design form, Estimation worksheet, Defect Log, and Project Summary provided at the end of this assignment description 4. A few screen shots showing test results of your working game and answers to reflection questions written inline in this document 5. Readme file (optional: submit if you have any special instructions for testing) —————————————————————————————————Rock Paper Scissors Game: Reference: https://en.wikipedia.org/wiki/Rock_paper_scissors —————————————————————————————————Program Requirements: Create a simple Rock-Paper-Scissors game (between 2 players) with a JavaFX UI. Create this game as a networked game. Create a RPSServer.java that is the server program that handles the Game logic and controls all game sessions. It waits for connections from players and pairs them up to play a game. It should create a separate thread for each game session. Also create a RPSClient.java that is the client program-handling player moves (with JavaFX UI). It should initiate a connection with the server and then play the game once assigned to a game session. Each game session includes playing 5 turns and then declare the winner. Then ask the players with they want to play again or quit. The client program receives the game configuration from the server and updates its UI with the points. No game logic checking should happen on client side. It should all be done on the server side. Use the tic-tac-toe example provided in course shell as a starting point and example. • • • • Continue to make use of good Object-Oriented design Provide documentation using Javadoc and appropriate comments in your code. Generate HTML documentation using Javadoc tool Make sure you provide Exception Handling where appropriate —————————————————————————————————Personal Process: Follow a good personal process for implementing this game. You will be using PSP2 in this assignment. So, in addition to tracking your effort and defects you will have to estimate the effort and defects for the GUI module, provide exception handling routines, and conduct a personal code review. • • • Please use the time log (provided at the end of this document) to keep track of time spent in each phase of development. Please use the defect log (provided at the end of this document) to keep track of defects found and fixed in each phase of development. When you are done implementing and testing your program, complete the Project Summary form to summarize your effort and defects. Also answer the reflection questions listed below in Post-mortem phase. Follow these steps in developing this game: 1. Plan: • understand the program specification and get any clarifications needed. • estimate the time you are expecting to spend on the GUI development task. • estimate the defects you are expecting to inject in each phase for GUI development task. • estimate the size of the program (only for new code that you will be adding) • enter this information in the Estimation columns of the Project Summary form. Use your best guess based on your previous programming experience. • use the provided estimating worksheet to show how you are breaking up code into smaller modules and estimating 2. Design – create a design (for the new modules being added) in the form of a flow chart, break up of classes and methods, class diagram, pseudocode. Provide this design in the PSP design form provided later in the document. Keep track of time spent in this phase and log. Also keep track of any defects found and log them. 3. Code – implement the program. Keep track of time spent in this phase and log. Also keep track of any defects found and log them. 4. Code Review – use the code review guidelines/checklist provided later in the document to conduct a personal review of your code and fix any issues found. Provide comments in the checklist about your findings. 5. Test – Test your program thoroughly and fix bugs found. Keep track of time spent in this phase and log. Also keep track of any defects found and log them. 6. Post Mortem – Complete the actual columns of the project summary form and answer the following questions. i. How good was your time and defect estimate for various phases of software development? ii. How good was your program size estimate, i.e., was it close to actual? iii. How many issues did you find in your code during code review? ————————————————————————————————-Grading Rubric: Working client server game – 20 points Javadoc and Exception Handling – 5 points Code review report – 5 points Test Results and Postmortem reflection question responses – 5 points PSP process – 15 points (Time log (4), Defect log (3), Estimation Worksheet (2), Design form (2), Project Summary (4) ) ————————————————————————————————– PSP Time Recording Log Date Start • • • • Stop Interruption Time Delta Time Phase Comments Interruption time: Record any interruption time that was not spent on the task. Write the reason for the interruption in the “Comment” column. If you have several interruptions, record them with plus signs (to remind you to total them). Delta Time: Enter the clock time you spent on the task, less the interrupt time. Phase: Enter the name or other designation of the programming phase being worked on. Example: Design or Code. Comments: Enter any other pertinent comments that might later remind you of any details or specifics regarding this activity. PSP1 Informal Size Estimating Procedure 1. Study the requirements. 2. Sketch out a crude design. 3. Decompose the design into “estimatable” chunks. 4. Make a size estimate for each chunk, using a combination of: * visualization. * recollection of similar chunks that youíve previously written * intuition. 5. Add the sizes of the individual chunks to get a total. Estimating Worksheet 1. Conceptual Design (sketch your high-level design here) 2. Module Estimates Module description Estimated Size Total Estimated Size: ____________ PSP2 Project Summary Time in Phase (minutes) Planning Design Code Code Review Test Postmortem TOTAL Estimated Actual To Date To Date % Defects Injected Planning Design Code Code Review Test Postmortem TOTAL Estimated Actual To Date To Date % SUMMARY Estimated Program Size (LOC) LOC/Hour Defects/KLOC • • LOC is lines of Code KLOC is Kilo lines of code (i.e. 1000 lines) Actual To Date PSP Design Form Use this form to record whatever you do during the design phase of development. Include notes, class diagrams, flowcharts, formal design notation, or anything else you consider to be part of designing a solution that happens BEFORE you write program source code. Attach additional pages if necessary. PSP Defect Recording Log Sl. No. Date Defect Type Defect Inject Phase Defect Removal Phase Fix Time Fix Ref Description Instructions • Defect Type: Use your best judgment in selecting which defect type applies from list provided below. • Defect Inject Phase: Enter the phase when this defect was injected using your best judgment. • Defect Removal Phase: Enter the phase during which you fixed the defect. • Fix Time: Enter the time that you took to find and fix the defect. • Fix Ref: If you or someone else injected this defect while fixing another defect, record the number of the improperly fixed defect. If you cannot identify the defect number, enter an X. If it is not related to any other defect, enter n/a. • Description: Write a succinct description of the defect that is clear enough to later remind you about the error and help you to remember why you made it. PSP Defect Type Standard Type Number Type Name Description 10 20 30 40 50 60 70 80 90 100 Comments, messages Spelling, punctuation, typos, instruction formats Change management, library, version control Declaration, duplicate names, scope, limits Procedure calls and references, I/O, user formats Error messages, inadequate checks Structure, content Logic, pointers, loops, recursion, computation, function defects Configuration, timing, memory Design, compile, test, or other support system problems Documentation Syntax Build, Package Assignment Interface Checking Data Function System Environment Code Review Checklist – Java 1. Specification / Design [ ] Is the functionality described in the specification fully implemented by the code? [ ] Is there any excess functionality in the code but not described in the specification? 2. Initialization and Declarations [ ] Are all local and global variables initialized before use? [ ] Are variables and class members of the correct type and appropriate mode [ ] Are variables declared in the proper scope? [ ] Is a constructor called when a new object is desired? [ ] Are all needed import statements included? [ ] Names are simple and if possible short [ ] There are no usages of ‘magic numbers’ (i.e, hard-coded values) 3. General [ ] Code is easy to understand [ ] Variable and Methods names are spelt correctly [ ] There is no dead code (i.e., code inaccessible at Runtime) [ ] Code is not repeated or duplicated [ ] No empty blocks of code 4. Method Calls [ ] Are parameters presented in the correct order? [ ] Are parameters of the proper type for the method being called? [ ] Is the correct method being called, or should it be a different method with a similar name? [ ] Are method return values used properly? Cast to the needed type? 5. Arrays/Data structures [ ] Are there any off-by-one errors in array indexing? [ ] Can array indexes ever go out-of-bounds? [ ] Is a constructor called when a new array item is desired? [ ] Ideal data structures are used [ ] Collections are initialized with a specific estimated capacity 6. Object [ ] Are all objects (including Strings) compared with “equals” and not “==”? [ ] No object exists longer than necessary [ ] Files/Sockets and other resources if used are properly closed even when an exception occurs in using them 7. Output Format [ ] Are there any spelling or grammatical errors in displayed output? [ ] Is the output formatted correctly in terms of line stepping and spacing? 8. Computation, Comparisons and Assignments [ ] Check order of computation/evaluation, operator precedence and parenthesizing [ ] Can the denominator of a division ever be zero? [ ] Is integer arithmetic, especially division, ever used inappropriately, causing unexpected truncation/rounding? [ ] Check each condition to be sure the proper relational and logical operators are used. [ ] If the test is an error-check, can the error condition actually be legitimate in some cases? [ ] Does the code rely on any implicit type conversions? 9. Exceptions [ ] Are all relevant exceptions caught? [ ] Is the appropriate action taken for each catch block? [ ] Are all appropriate exceptions thrown? [ ] Are Catch clauses are fine-grained and catch specific exceptions? 10. Flow of Control [ ] In a switch statement is every case terminated by break or return? [ ] Do all switch statements have a default branch? [ ] Check that nested if statements don’t have “dangling else” problems. [ ] Are all loops correctly formed, with the appropriate initialization, increment and termination expressions? [ ] Are open-close parentheses and brace pairs properly situated and matched? 11. Files [ ] Are all files properly declared and opened? [ ] Are all files closed properly, even in the case of an error? [ ] Are EOF conditions detected and handled correctly? [ ] Are all file exceptions caught? 12. Documentation [ ] All methods are commented in clear language. [ ] Comments exist and describe rationale or reasons for decisions in code [ ] All public methods/interfaces/contracts are commented describing usage [ ] All edge cases are described in comments [ ] All unusual behavior or edge case handling is commented [ ] Data structures and units of measurement are explained

Collepals.com Plagiarism Free Papers

Are you looking for custom essay writing service or even dissertation writing services? Just request for our write my paper service, and we'll match you with the best essay writer in your subject! With an exceptional team of professional academic experts in a wide range of subjects, we can guarantee you an unrivaled quality of custom-written papers.

Get ZERO PLAGIARISM, HUMAN WRITTEN ESSAYS

Why Hire Collepals.com writers to do your paper?

Quality- We are experienced and have access to ample research materials.

We write plagiarism Free Content

Confidential- We never share or sell your personal information to third parties.

Support-Chat with us today! We are always waiting to answer all your questions.