Download
1 / 36
360 likes | 474 Vues
Object-Oriented Programming (Java), Unit 24 Stand In Final Project Description. Kirk Scott. CS 202 Final Programming Project, 130 Points Total.
E N D
Object-Oriented Programming (Java), Unit 24 Stand InFinal Project Description Kirk Scott
CS 202 Final Programming Project, 130 Points Total • ***Note that each student will be given layout specifications that differ in the number of cups and seeds, and whether the board is oriented horizontally or vertically on the screen. • Your version of the final programming assignment has to conform to the specifications you are given.
What's old: • Your version of TogizKumalak should have a main frame that does not include the game board, with a menu including options to create a subframe and exit the application. • Your version of TogizKumalak should have a subframe that does include the game board, with a menu including options to restart, load, save, and close the subframe.
The structure of the frames and the menu options in the frames are a review of topics that were covered up through unit 23. • You can just carry over code that you wrote before. • Notice that the contents of the listeners for the menu items for the subframe will have to be changed.
Your version of TogizKumalak should also have a text area recording the moves that have been made. • This was introduced in unit 22, and to a large extent this can also just be carried along in the new code.
1. 30 points. • Your version of TogizKumalak should have all of these features which are based on previous work: • 1.a. The game should still play correctly. This includes both moving and capturing seeds, as well has alternating active sides of the board. Note that the functionality is worth points separately from simply including (potentially non-functional) buttons as listed in question 2. 10 points
1.b. The application should be based on a main frame and a subframe. 10 points • 1.c. It should have a JTextField that has the moves recorded in it. 10 points
What's new: • Overall, your new version of TogizKumalak should have cups which are represented by instances of the JTextField class. • The cups should have instances of the JButton class associated with them, and clicking one of these buttons should cause the corresponding cup to be played. • Also, the text fields/buttons for the cups should be labeled on the screen with instances of the JLabel class.
The visual components of the new application should be arranged using an instance of the GridLayout class for whatever panel contains the application components. • There are other aspects of the new version which are not visual in nature.
The specific parts of the assignment which will be noted when black box testing, and the points associated with them are listed below. • The different graded items are listed in an order which you might find convenient to follow when working on the implementation.
2. 40 points. • Your version of TogizKumalak should have cups represented by text fields, identified by labels, and playable by clicking a button. • The various components should appear in a neat rectangular layout. • Since black box testing is used, I won't literally know if you used a grid layout, but only a crazy person would try to accomplish this without it. • (This is material from units 25 and 26.)
2.a. The cups should be represented by text fields. 10 points • 2.b. The cups should have matching labels. 10 points • 2.c. The cups should have matching buttons for play. 10 points • 2.d. The application should have a rectangular layout. 10 points
If your implementation does not successfully do point 2, you are ineligible for any of the following points.
3. 30 points. • Your version of TogizKumalak should have a subframe with a menu including options to restart, load, save, and close the subframe. • The listeners for restart, load, and save will have to be changed from their previous versions in order to support the new form of the cups and board. • The load and save options should make use of file choosers. • (Note that this is a review of a topic that was covered up through unit 23.)
3.a. The subframe menu should have a restart option. 10 points • 3.b. The subframe menu load and save options both have to work—when black box testing it's impossible to tell which is faulty if the functionality doesn’t work. 20 points total
4. 10 points. • Although not critical to the way TogizKumalak works, your version should include this aspect, which is based on the concept of focus: • If you hit the enter key in one of the text fields representing a cup, the cursor (focus) should move to the next cup.
This should be set up so that you could go all the way around the board this way (in play order). • Once you understand this, it turns out to be a very simple addition to the code. (This is material from unit 27.) • 4.a. The application should pass focus from cup to cup. 10 points
5. 20 points. • Your version of TogizKumalak should be playable by using keystrokes as well as clicking buttons. • It is possible to do this using the ideas from unit 22. • (If so, you should add the method requestFocus() to your bag of tricks.) • It is also possible to do this using the new material from unit 28.
In general, the application should be keeping track of whose turn it is, and all that's necessary is for the user to specify the desired cup by entering a keystroke like '1', '2', etc., or if following the model from unit 28, a combination of keystrokes, like 'CTRL+1'. • It is necessary to let me know what keystroke convention I am supposed to use when testing your code.
5.a. Although this is only one part, it may require a significant effort to get it to work correctly, so it is worth double, 20 points. If your program accepts keystrokes and then button clicks, but after that the keystrokes are inactivated, that's worth 10 points. • A full 20 points will be given if you can alternate seamlessly between keystrokes and button clicks.
Notice that you do not have to create a UML diagram for your solution. • Following the screenshots of the application, UML diagrams are given for a working solution to the problem. • You are not obligated to follow the design given by those diagrams. • Also, depending on the specific layout of the version you have been given, that design may not be entirely appropriate.
The UML diagrams are given for two reasons. • 1. They might help you design your own solution. • 2. Whether they are helpful as a guide to writing a solution or not, they serve as notice to you of the complexity of project.
It is important for you to have a grasp of the complexity involved so that you start working on a solution right away and don't put it off too long. • Having the UML diagrams as a guide might save you from having to massively redesign or recode your project if you run into trouble.
On the other hand, the diagrams might not save you from that eventuality. • You should understand that large-scale problems like that are possible, and budget the time for them in case they happen.
When you hand in your final code, it should not be a guessing game on my part as to which parts of the assignment you did. • You have to tell me up front which of the 11 subpoints above I should be looking for when grading.
If you didn't do one or didn't get one to work, it would be a great courtesy if you let me know so that I won't be looking for things that don't exist. • Also, as noted under point 5, you need to let me know what keystroke convention to use if you did that part. • The grading checkoff sheet is appended at the end of this document for your reference.
These screenshots show what my solution to the problem looked like.
UML diagrams for a solution are given on the following overheads.
