Your job is to revise the instructor's Java program that implements the Advenure Game design to add the implemented rudimentary GUI software, and to create JUnit tests for all methods in the game.
UML Class Model of the GUI: AdventureGameView.java and AdventureGameModelFacade.java
The GUI makes use of the BreezySwing package, which simplifies the design of the GUI. Here is some documentation for BreezySwing (which is the successor to BreezyGUI):
The new Java files, AdventureGameView.java and AdventureGameModelFacade.java are in adventureGUI.jar. You will also need to import the BreezySwing package (BreezySwing.jar) into Eclipse as a separate jar file, and configure the build path to add it via the Libararies tab and teh Add JARs button.
To run the GUI version you need to run "AdventureGameView.main". You will discover that the GUI interface is not connected to the game. CaveGameView displays the GUI, and the GUI buttons make the right calls to AdventureGameModelFacade. However, all of the methods in AdventureGameModelFacade that should implement the buttons are empty.
Your job is to connect AdventureGameModelFacade to the rest of the system, finish implementing AdventureGameView (add the GUI code needed to get the "Grab an Item" and "Drop an Item" buttons to work) and get the whole system working.
Surely, there are some other modifications required to implement the design change. For example, you will need to move some of the functionality (and code) in the original class AdventureGame into class AdventureGameModelFacade. Lots of the code in AdventureGame deals with the command line interface interactions with the user. This code is greatly simplified with a GUI.
Key problems you will find are (1) finding all of the output statements hidden in the code, and (2) writing the dialog GUI code. You may need to add an additional TextArea to the GUI to display information other than the room descriptions.
You may use your own creativity to add more interesting textual descriptions of the rooms. The descriptions should be consistent with the layout in the instance diagram. Use good taste in your descriptions --- do not use offensive language. Keep the room numbers in your descriptions to make it easier to test.
We have prepared some slides to introduce JUnit. These slides reference other locations where you can find information about JUnit:
- Junit.org: http://www.junit.org/
- Paul Ammann and Jeff Offutt: http://www.cs.gmu.edu/~offutt/softwaretest/
1. Continue splitting the user stories if needed. With your team, estimate story points for all split user stories. If you find a split story still has 13 or more story points, split it.
2. With your team, create the tasks needed to implement each split user story so that the Acceptance Criteria can be met. Make sure to meet the definition of done listed above. Add to your team's definition of done if needed. Estimate the number of hours for each task. Create tasks that are between 1 and 10 hours long.
3. Decide which teammembers will be working on which tasks.
4. Add the split user stories and tasks to the UserStory folder of your project, one text file for each user story: e.g. A2-US-1.txt and A2-US-2.txt. Please see A2-US-1.txt for an example file format; estimated story points and task estimated and actual times must be included.
5. As each person finishes a task, update the task in the repository to include the time it actually took to complete.
6. Make sure the plain text file in the src directory called overview.txt has been modified by each person so that it contains:
- Names of the team members.
- Specific contributions by each team member.
- Time (in hours) spent by each team member on this assignment.
- Test results for all unit tests. A summary is OK; e.g. all 60 unit tests passed
- The CSU Honor Pledge:"I have not given, received, or used any unauthorized assistance." with the team members' names listed below.
7. Create a single jar file of the code on the master branch that includes sources, the overview.txt file, and the user story file(s) (e.g. A2-US-1.txt and A2-US-2.txt). (See A2rubric-revised.txt, PART 1 for details on the required jar file structure.) Part of your grade for A2 is that your program compiles and runs on the Computer Science Department's Linux systems, so test your program appropriately. Your program will be tested in Eclipse.
8. Submit your jar file to the Canvas dropbox for Assignment 2 (A2) to check-in your assignment.
Post questions or comments about this assignment, or problems with the design to the Assignment 2 Discussion on the Canvas discussion board, or send email to cs314@cs.colostate.edu.
Grading: (for details see A2rubric-revised.txt)
1. You will receive a team grade based on the Canvas submission, your design, and the game functionality.
2. You will receive an individual grade based on GitHub logs of your repository submissions and review system comments. Each team member is expected to have created and used branches for their own work for A2, with frequent pushes from their local systems to GitHub, and review requests when they are ready to merge to the master. Each team member is expected to review code changes proposed by their teammates and provide comments.
Return to CS-314 Home Page