Assignment Part 2: Full Implementation

School of Science
Object-Oriented Software Design ISYS1084/1083, S1,
2020
Eagle Versus Shark (Board Game)
Assignment Part 2: Full Implementation/Gamma et al. Patterns

Assessment Type: Group assignment. Submit online via Canvas→Assignments→Assignment 1. Marks are awarded for
meeting requirements as closely as possible according to section 2 and the supplied rubric. Clarifications/updates may be
made via announcements/relevant discussion forums.
Due date: Due Friday 29th May 6:00PM. Late submissions are handled as per usual RMIT regulations – 10% deduction (2.5
marks) per day (Saturday and Sunday count as separate days). You are only allowed to have 5 late days maximum unless
special consideration has been granted.
Weighting: 25 marks (25% of your final semester grade)

1. Overview
This assessment is a continuation of the Eagle versus Shark Board Game from assignment 1. This part 2 extension incorporates the
Gamma et al. design pattern taught from weeks 6 to 10. For this assignment you are also required to provide additional game features
that make the game more functional and playable. As with part 1 you should follow all of the quality/assessment criteria provided in
section 2 below.
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)
 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
ADDITIONAL FUNCTIONAL REQUIREMENTS (10 marks )
Complete the implementation for ALL of the requirements in Part I and implement the following two mandatory extra
functionalities:
 Incorporate an undo moves option. Each player can undo from 1 to 3 moves in one go but can exercise this option only
once per game. Undoing affects both players regardless of who initiated it. For example if Player 1 undoes the last two
moves then both players last two moves are cancelled and Player 1 now plays their turn.
 Add an alternative capability to each piece category where players can switch to the alternative capability before making a
move (for example and Eagle may switch from Scout to Attack mode or a Shark may switch from Silent to Aggressive mode).
In addition, two of the following extra functionalities or graphical user interface requirements must be met to get full marks.
 An option to save the game state midway and restart later.
 An option to create different sized boards and varying number of pieces.
 An option to introduce obstacles onto the game board which limits available moves.
 Allow playing against the system. Since this is not an AI course you can keep the “AI” logic simple i.e. it does not matter if the
system does not always win!
 Extend the game to a client server application (e.g. using proxy pattern and RMI).
ADDITIONAL NON-FUNCTIONAL REQUIREMENTS (BASED ON DESIGN/CODE) (5 marks)
In your solution you must use and document: two creational, two structural, and two behavioural patterns from the Gamma et al.
pattern catalogue as covered in lectures 6-10.
For each of the three categories (creational, structural and behavioural) you must choose at least one pattern from the following list
(these are some of the more complex and/or significant patterns that can be readily applied in a good solution to the assignment).
i.e. total of three patterns from the list (one from each category) and three patterns of your own choosing (one from each category),
for a total of SIX patterns.
Creational
Abstract Factory
Prototype
Structural
Composite
Decorator
Behavioural
Visitor
Observer
Chain of Responsibility
Command
For each of the 6 chosen patterns you should provide a class diagram showing the specific usage in your assignment using the exact
naming (class, method names etc.) of your source code so we can cross reference your diagram and the code when marking. Include
only classes that directly relate the specific pattern usage. Also, for each pattern you should provide a description of why and how
the patterns were used and what advantages it provided in this specific use case. These diagrams and descriptions are to be
submitted along with your final code at the end of week 12.
VIDEO PRESENTATION (5 marks)
You are required to create a short (5 minute) group video presentation for submission alongside your working system and class
diagrams described above, where you:
 Justify your design decisions (emphasis on the use of specific GoF design patterns).
 Show a video screen capture of working gameplay with a voice over commentary that describes what is happening in the
game keeping in mind that this will allow the markers to accurately assess your implementation of the functional game
requirements.
Please make sure you stick to the 5 minute limit and use judicious editing to achieve this!
CODE QUALITY (5 Marks)
 Quality of code based on how effectively you implemented the GoF design patterns.
 Emphasis on high cohesion, low coupling, indirection and good extensibility.
 Final code to meet the code quality guidelines (see assessment criteria above).
 Use of design by contract (class invariants, pre and post-conditions for methods).
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 groups’ 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 project1) 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, video etc.) in a separate clearly named .zip file.
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.
1 You can develop your system using any IDE but will have to create an Eclipse project using your source code files for submission purposes.
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.

WhatsApp
Hello! Need help with your assignments?

For faster services, inquiry about  new assignments submission or  follow ups on your assignments please text us/call us on +1 (251) 265-5102

🛡️ Worried About Plagiarism? Run a Free Turnitin Check Today!
Get peace of mind with a 100% AI-Free Report and expert editing assistance.

X