Assignment 1: OOA&D Basics and Brickus GUI Application
The purpose of this assignment is to refresh your Java coding skills get experience with Java GUI coding if you have not yet done any, and to refresh your basic OO design knowledge, by- reading the first part of the Head-First Object Oriented Analysis and Design book, and
- implementing a simple GUI using Swing.
For the book self-study, also be thinking about how some of the principles covered in the book can be applied to the programming part of the assignment. The Java GUI progam is pretty simple, but here are some topics covered in the book which are relevant:
- encapsulation of logical parts (Ch1) (separate the game logic classes from the GUI classes)
- use-cases (Ch 2-3) (work through a couple infomally; we are going to be covering use-cases in detail later in lecture)
- the alternate paths of a use-case (Ch 3), e.g. dealing with incorrect input to the GUI here.
- textual analysis (Ch 4) (you could use it in part I in fact, on the requirements list below)
- delegation and the power of loose coupling (Ch 4)
- UML class diagrams (spread out) (could be helpful in considering alternative class structures for your program)
- Make classes cohesive, focused on a single thing (Ch5) (don't try to put all the game logic in a single class, there are several distinct foci of the application!)
- Never settle for a bad design -- change it! (Ch5)
- Code to an interface, not to an implementation (Ch5) (probably not relevant to your code, but it is common in the Swing classes)
Requirements for Brickus
The notion of requirements are covered in Chapter 2 of the book. For this assignment we will give you some pretty detailed requirements.
The assignment is to write a program that allows two players to play a simple hotseat puzzle game named Brickus. Gameplay is conducted on a grid with fixed-shape pieces which may be flipped or rotated before being placed. Each player takes turns placing pieces with the objective of occupying more squares on the board than their opponent. The following is a breakdown of gameplay rules:
- The game is played on a fixed-size grid. A typical size is 14x14 spaces.
- Each player starts with a set of 21 pieces. No piece can be rotated or flipped in such a manner as to match another piece. Pieces contain between one and five orthogonally connected squares. (Note: there is exactly one such set of 21 pieces. If you start the provided implementation as described below, the first screen displays to you all 21 pieces and their layout.)
- If a player has no pieces on the board, his or her first piece must be placed in an open corner.
- If a player has pieces on the board, the following placement rules
apply:
- Pieces of the same color may never touch orthogonally.
- Each new piece must touch at least one existing piece diagonally.
- Pieces may not be placed on top of other pieces.
- Pieces must be placed entirely on the board.
- Once a piece has been placed, it will never be removed from the board.
- Each player places exactly one piece; play then proceeds to the next player.
- During any turn, a player may choose to pass rather than placing a piece.
- The game is over when both players choose to pass.
- Each player's score is equal to the number of spaces on the board that contains a piece owned by that player.
Resources
You are strongly encouraged to use a professional IDE (such as NetBeans or Eclipse) to complete your coursework; your familiarity with such a tool will be required for future assignments. You are also required to properly document your sources and, as this assignment must be completed in Java, you should use JavaDoc to do so. See the Course CASE tools resources page for an overview and pointers to information on how to use Eclipse and JavaDoc.
You will also need to download the Brickus assignment framework, as it is a necessary portion of the project. It contains the following resources:
- BrickusInterface.jar: The interface to which both the UI and the model are programmed. This allows UIs and models to be interchanged freely.
- BrickusDefaultModel.jar: A complete implementation of the Brickus model. This archive contains compiled bytecode representing the game's logic.
- BrickusDefaultUI.jar: A complete implementation of the Brickus UI. This archive contains compiled bytecode representing the game's Swing implementations.
- BrickusIntefaceJavadoc.zip: An archive containing the Javadocs of the Brickus interface.
To run the provided implementation of the game, you need only invoke the edu.jhu.cs.oose.fall2009.brickus.viewcontroller.StandardBrickusMain class when all three provided JARs are on the classpath. To control the provided UI, use left-click to select (or place) a piece, right-click to flip a piece, and the scroll wheel to rate the selected piece. Holding shift while flipping the piece causes it to flip in a different direction.
Part I: Model Only
You will write this assignment in two parts. The first part consists of the model for your application; the second part consists of your user interface. The assignment must be written in Java and must run properly with the provided libraries.
The objective in this part of the assignment is to implement the logic of the game; you will be using a provided user interface to do so. You must provide correct implementations of the BrickusModel and BrickusPiece classes. Furthermore, your model must have a no-args constructor. You can test your implementation with the provided JAR files by putting your compiled implementations on the classpath instead of the BrickusDefaultModel.jar. After doing so, invoke the provided Brickus GUI by specifying the fully-qualified name of your model class as the first argument. For example:
java -cp BrickusInterface.jar:BrickusDefaultUI.jar:bin/ edu.jhu.cs.oose.fall2009.brickus.viewcontroller.StandardBrickusMain edu.jhu.cs.myjhedid.oose.brickus.MyBrickusModelClass
HFOOA&D Assignment along with part I
- Read the first three chapters of HFOOA&D.
- For the topics that are less than clear to you, work through those exercises in the book.
Part II: GUI
For this part of the assignment, you will write the view and controller of the application. These two parts together comprise what is traditionally considered a user interface. The UI allows the user to interact with the model in a meaningful way (and without having to know how to program!). Your UI must have the following properties:
- It must be written using Swing widgets and presenting a graphical interface.
- It must use a custom component to represent the board. That is, your board may not be composed of a grid of buttons or use any other such approach.
- Your GUI should be visually appealing. 25% of your grade will be based on whether or not your GUI is something that a user would want to see while playing the game. You might include shading, blend orthogonally-connected squares of the same color together, or add a menu in order to improve the appearance. A GUI which has poorly aligned buttons, text which wraps awkwardly, or large sections of wasted space will not receive full credit.
- Your GUI should display the error messages presented to it by the model it was provided. This is part of the feedback of a user interface and must be done in such a way that the user can determine what he or she did wrong.
- The GUI portion of your application absolutely must not create a reference variable to your specific model type anywhere in your program, nor may you cast a reference to your model type. The point of MVC design is that the specific implementation of the model should not matter to your program. In other words, your application needs to be able to work with the provided default model implementation as well as it does with your own.
- You are welcome to design the interface any way you like. You may receive bonus points for additional features. Examples include maintaining a highlight over the most recently placed piece, a status bar to display a running score total, or even sound effects (if you're feeling particularly motivated).
- When running your program, the GUI must not print any stack traces to the console. This behavior may occur if something goes wrong in a Swing event thread (such as a NullPointerException in a call to a custom paint method). If this happens, your program will not stop, but the stack trace will be printed; this represents something going wrong and must be fixed.
HFOOA&D Assignment along with part II
- Read the chapters 4 and 5 of HFOOA&D
- For the topics that are less than clear to you, work through those exercises in the book.
Submission Instructions
We will be using WebCT to submit assigmenents. You are automatically enrolled in the WebCT page for the course via the registrar. One aspect of this system is if you have not yet offically added the course, you won't be able to turn in assignments. So please add the course as soon as possible.
You can log in to webCT via webct.jhu.edu using your JHED ID and password. After logging in you will see a list of courses, hopefully including OOSE, which you select. If OOSE is not listed, it means you are not enrolled as far as the registrar is concerned. The assignment submission process involves uploading the files, and it should be fairly self-explanatory.
Required submission items:
- Part I: Submit your custom model and piece source files. The sources must work correctly with the default UI implementation to allow you to play the game.
- Part II: Submit your custom user interface source files. You must provide a class containing a main method which allows one to run the program and use the GUI to play the game. Your GUI must work correctly with the default model implementation. You should also include a README file identifying the class containing the main method that launches the GUI. In this README, you should also identify any additional features you wish to bring to the grader's attention.
All of your solutions should work in the Sun Java 5 or 6 SDK.
Grading Criteria
Score Calculation
The first part of the assignment is graded 75% on correctness and 25% on style. The second part of the assignment is graded 50% on correctness, 25% on style, and 25% on the appeal of the user interface. The second part of the assignment also affords some opportunity for bonus credit. The course style requirements apply.