Homework | Assignment | 代写Java | Javafx代写 – 这是一个利用java和javafx完成的GUI游戏
Design Homework: Tic-Tac-Toe
The nature of this homework is different from previous "programming" style homeworks. The goal isnot to write code. The goal is to make plans for writing code, anticipating the programming of more than one iteration or version of an imagined application. By this point in the course, you are familiar with object-oriented language features, even having tried a graphical user interface (the javafx GUI). Also, you know about collections such as lists, maps, sets, and arrays. Plus, you know how to define classes, interfaces, subclasses, methods and how these are used. This puts you in position to design software even before you write code.
The rest of this homework description starts with a vision of an application, a tic-tac- toe game. Then the concept of a layered design is repeated (it was one lecture in the course, and there is a page on the course website with an example). The homework description ends with a statement of the rubric and expectations. This homework is worth more than any previous homework: 30 points.
Background and Envisioned Application
Tic-tac-toe is a simple children’s game, perhaps thousands of years old. The usual 3x board version is simple to understand, though the game becomes more interesting when the board can be larger, say MxN instead of 3×3 (for larger board sizes the goal can be to get k X’s or O’s in a row, where k is some specified number).
The application we imagine here is more sophisticated than the basic version. When you launch the application first, it asks some questions:
- Is this a two-player game or a player versus the computer?
- Is the size of the board 3×3 or does is it some larger size (more squares)?
- If playing the computer, who should go first?
- Is this regular tic-tac-toe, or do you want to play ultimate tic-tac-toe?
- What is your name (for recording the result of the game)?
After the game starts, playing the game uses a graphical interface, where you can select the square with a click or similar interaction.
Some background: Wikipedia has a page Tic-tac-toe (Links to an external site.)Links to an external site. with a pointer to general board sizes, and Wikipedia also has a page about Ultimate Tic-tac-toe (Links to an external site.)Links to an external site., but look at this page (Links to an external site.)Links to an external site.to get the idea as well. Another tweak mentioned in Wikipedia that could make even basic Tic-tac- toe interesting,in the two-player version, is when the player has to solve a random puzzle in order to mark the chosen square.
All the ideas in this vision are optional features to consider in making your design for a tic-tac-toe application. Don’t think that you have to do it all, just do what you feel confident that could be reasonably planned.
Layering Your Design.
You should describe a software design for a tic-tac-toe application that goes beyond the simplest children’s game. Your design should have the required two elements for layering, decomposition and version iteration. Each layer should describe what is done at that layer, how it can be tested, what interfaces, objects and methods it uses from previous layers, and/or what work would need to be done in revising previous layer work. Decomposition means that your design will be technical: separate modules of the design in an object-oriented framework would need to define classes, interfaces, methods, and properties. The way that individuals modules are interconnected is also part of the design, though this kind of detail is perhaps best shown using a design tool such as UML (we may not study enough UML before the first design assignment’s due date). The textbook on software design philosophy speaks to decomposition and some general ideas about what is good design.
Some Advice and Rubric
This design homework is worth 30 points. The paragraphs below explain how the homework will be evaluated and offer advice on how to prepare your design report.
It’s not a good idea to write down your design all at once from your thoughts. You should design a little at a time, write down some ideas, and think about what comes next. Plan on spreading this out over multiple days. Then take all your notes (perhaps
with some drawings that help you plan out things) and write down a draft of your design. Make one more pass on the draft to polish it, clarifying points that were undefined or too brief.
The submission should be a PDF file of around four pages, which can include text and figures. Your design should have four iterations, going from a basic and simple version to one with enhanced features and more sophistication. You should aim for each iteration being what you imagine to be approximately two weeks of programming, testing and debugging (imagine full time effort programming for two weeks). Having the proper PDF format and describing four iterations is worth 12 points.
The easiest part of layering is adding new features, or generalizing existing, limited features, in each iteration. Because this is so easy, only 3 points credit for adding features over the iterations.
The more difficult part of layering is decomposing the design into modules and explaining how these modules fit together to achieve the design. A good decomposition is worth up to 10 points. Explaining the role of a module is naturally done by interface descriptions: here the word "interface" has a larger meaning than how java and Kotlin use the term "interface, it means the knowledge that other modules need to use this module, such as calling parameters, data types, method names, and so forth. Information from the reading assignment (philosophy of
software design) and from lectures might help you understand better how module design is evaluated.
Module design in an object oriented language usually depends on proposing classes and methods to solve problems. Some classes are externally given, like those in graphical interfaces, and of course the classes in collections, which all software development uses in data structures. Other classes model the application (tic-tac- toegame) and you must invent these classes. As a general rule, classes that are not simply entity modeling bring higher value, and demonstrate deeper thoughtfulness, than obvious classes (e.g, "there has to be a board class for the tic-tac-toe squares"). Going being the obvious and anticipating what will be useful is a valuable contribution to good design.
How can you think up what classes would be used in the design of an application? Your background experience will help you. For example, you know about data structures, you know about some elementary algorithms, loops, functions, and you even know a little about graphical user interface frameworks (JavaFX at least). Thus, if you were presented with a complex tic-tac-toe application, you could make educated guesses of the kind of internal functions it might have. In some sense, that is what you do when you design: you make educated guesses about possible structures (it’s advisable to think of more than one possible design) and then think of
a simplified form of such a structure as a programming problem to solve, much like a homework problem.
Finally, another 5 points in the evaluation of your design is that you took the time to describe the validation plan for each iteration and how each iteration (except the first) takes advantage of the results from previous iterations.