Analysis, Design and Prototype

School of Science
Object-Oriented Software Design ISYS1084/1083, S1,
2020
Eagle Versus Shark (Board Game)
Assignment Part 1: Analysis, Design and Prototype

1. Overview
Which animal is the best, Eagle or Shark? Your task is to create a board game to find out called Eagles Versus Shark!1
While we have specified some guidelines and functional and non-functional requirements below, we have left this assignment open
enough to explore your creativity and put your group’s personal signature on your project!
Specifically, your task is to develop a two dimensional, turn based board game that is subject to the functional and non-functional
requirements, and design constraints listed below.
This is a two-part assignment and in assignment part 1 you are to perform and analysis and design and produce relevant design
documents as well as implement a working system prototype.
IMPORTANT: Since this is a group-based assignment please make sure you attend the tutelab in week 2 to participate in the group
formation exercise.
2. Assessment Criteria
This assessment will determine your ability to document and apply Object-Oriented Design principles and patterns according to a
written specification. Specifically:
AVOID:
 Redundant/obvious comments that can be inferred from the source code
 Commented out code
 Dead functions
 Large classes and methods
 Data only classes
 Incorrect class hierarchy
 Duplicated code in classes and methods
 Feature envy (see lecture on refactoring)
 Inappropriate intimacy (see lecture on refactoring)
1 If anyone knows the cultural reference without resorting to an Internet Search then feel free to share in class
 Vertical separation (see lecture on refactoring)
 Switch statements (use polymorphism wherever possible)
 Long parameter list in methods and interfaces (use encapsulation)
USE / ALLOW:
 Readable and maintainable code
 Meaningful and consistent naming convention
 Low Coupling between classes
 High Cohesion in classes
 Consistent indentation and spacing
 Comments that add value above the source code e.g. explaining algorithms, dependencies or reasons for design choices
 Javadoc for core interfaces/classes, especially where there is a boundary between implementation from different team
members
 IF IN DOUBT ASK EARLY!
3. Learning Outcomes
This assessment is relevant to the following Learning Outcomes:
 CLO2: Identify and mitigate the risks associated with the development of large-scale software projects.
 CLO3: Apply the UML design notation as part of the OO development process.
 CLO4: Explain and document diagrammatically specific Design Patterns from established pattern catalogues and apply
them to novel design problems.
 CLO5: Apply the process of Refactoring to continuously improve a software product.
 CLO6: Apply Design by Contract to produce robust self-verifying software modules.
4. Assessment details
FUNCTIONAL REQUIREMENTS:
BOARD: Your game is to be based on the classic “board game” design where a two-dimensional board is composed of a number of
smaller play segments (such as squares on a chess board or real estate properties on a monopoly board). However, you are encouraged
to use irregular geometric designs: curves, polygons etc. are all fair game, but for simplicity, the graphical representation will be a
topographical (top down) view.
NOTE: In assignment part 2 the board will become more complex (blocked paths, obstacles etc.) so you may like to consider this in
your design.
PIECES: Both opposing teams (Eagles and Sharks) will be represented by a collection of pieces. At least three different categories of
piece are required for each team that move and behave differently (e.g. Hammerhead and Great White etc. for Sharks, Bald Headed,
American etc. for Eagles). You can have as many pieces on each team as you like but less than 10-12 will keep things manageable. The
behaviour of the pieces in each team category are to be different (different capabilities, strengths, weaknesses).
TURN BASED: Play is to be turn based where each player makes a single move of a single piece at each alternating turn. A configurable
time limit for each turn must also be provided.
GAME RULES: The gameplay is win/lose (as in chess) rather than score based and involves players capturing each other’s pieces. We
do not specify exactly how this occurs (this is left to your team to analyse and document). For example, it could be based on capturing
a square, line of sight, combat or any other mechanism. However, there must be some form of hierarchy or specific rules involved in
the process of how a piece is defeated and captured … think rock, scissors, paper (lizard, Spock) where scissors cut paper, rock blunts
scissors, Spock disproves paper etc.
NOTE1: You cannot just do a basic game like chess or checkers with symmetrical team play where both sides have the same pieces
with the same capabilities.
NOTE2: You can make the gameplay either as friendly or combative as you choose, but avoid any graphic depictions that go beyond a
reasonable PG/Family friendly nature (if in doubt your tutors and fellow students can offer guidance in the labs!)
DELIVERABLES AND MARKING BREAKDOWN:
ANALYSIS AND GAMEPLAY (2.5 marks)
Since this assignment requires some analysis and synthesis of game behaviour you need to document the gameplay in a suitable
fashion. You can use a combination of use case, sequence, and activity diagrams (whichever you feel best expresses your gameplay)
as well as written descriptions. You must provide at least 2 formal diagrams which capture all gameplay/rules as well as additional
written descriptions.
SYSTEM DESIGN (2.5 marks)
You should provide at least 2 class diagrams that show your class structure in terms of a Model View Controller Approach (MVC).
You should provide at least one non-trivial sequence diagram which illustrates an example of gameplay for a specific scenario based
on your chosen game rules.
SYSTEM IMPLEMENTATION (PROTOTYPE) (7 marks)
Your assignment will be extended to a full game for Assignment 2 but for Assignment 1 you should create a working prototype
which shows the game board, the pieces and allows players to choose and move a piece from each opposing team. At this stage you
do not need to implement the capturing phase.
Your implementation should be in Java using the standard libraries of Java SE such as AWT/Swing or JavaFX and/or the Java 2D API.
Note that since the focus of this course is on OO design you should not dedicate excessive effort to the graphical representation and
can use any freely available media assets within their licensed terms of use.
NON FUNCTIONAL REQUIREMENTS (3 marks)
 Code should adhere to assessment criteria in section 2 of this document.
 Code should follow the SOLID and GRASP principles.
 Use of design by contract (class invariants, pre and post-conditions for methods).
 Separation of Model, View and Controller.
5. Referencing and third party code exclusion
 You are free to refer to textbooks or notes and discuss the design issues (and associated general solutions) with your fellow
students or on Canvas; however, the assignment should be your group’s OWN WORK and you should clearly document your
own individual contribution to this group assignment (e.g. by maintaining logs in Microsoft Teams, a PRIVATE git repository,
providing author attribution on any code artefacts or documentation etc.).
 You may also use other references, but since you will only be assessed on your own work you should NOT use any third-party
packages or code, or any generated code (e.g. UI builders) (i.e. not written by you/your team) in your work. You may use third
party media assets within their licensed terms of use.
6. Submission format
The source code for this assignment (i.e. complete compiled Eclipse project2) should be submitted as a .zip file by the due date. You
should use the Eclipse option export->general->archive to create the zip file for submission. All members of the group should
submit the same submission via Canvas.
You should submit all documentation (diagrams etc.) in a separate clearly named .zip file.
2
You can develop your system using any IDE but will have to create an Eclipse project using your source code files for submission purposes.
7. Academic integrity and plagiarism (standard RMIT warning)
NOTE: Any discussion of referencing below in the standard RMIT policy is generic and superseded by the third-party code exclusion in
section 5.
Academic integrity is about honest presentation of your academic work. It means acknowledging the work of others while developing
your own insights, knowledge and ideas. You should take extreme care that you have:
 Acknowledged words, data, diagrams, models, frameworks and/or ideas of others you have quoted (i.e. directly copied),
summarised, paraphrased, discussed or mentioned in your assessment through the appropriate referencing methods,
 Provided a reference list of the publication details so your reader can locate the source if necessary. This includes material
taken from Internet sites.
If you do not acknowledge the sources of your material, you may be accused of plagiarism because you have passed off the work and
ideas of another person without appropriate referencing, as if they were your own.
RMIT University treats plagiarism as a very serious offence constituting misconduct. Plagiarism covers a variety of inappropriate
behaviours, including:
 Failure to properly document a source
 Copyright material from the internet or databases
 Collusion between students
For further information on our policies and procedures, please refer to the University website.
8. Assessment declaration
When you submit work electronically, you agree to the assessment declaration.