Software Architecture

4. A discussion on OO-design and how cohesion and coupling issues were addressed in our design, as well as a discussion of the software development methodology (e.g. iterative and incremental development).

• Object oriented design was implemented by having a single GameObject class which was inherited by all other entities in the game. Each entity then had further instances of itself made when and as required. These instances were also cleared to save heap space and memory leaks.
• Duplication of code was reduced by adding in helper functions, especially in loading levels and reading resource files. This allowed the code to be more manageable, maintainable and easily editable.
• We followed the ‘cascaded waterfall’ method in order to relate closely to our initial proposed game design. While this worked in sync with the ‘iterative and incremental’ method, our team feels that the ‘cascaded waterfall’ was a superior method in this case as it allowed us to stick to the initial project requirement by the client. We were able to create a game very similar in usage to ‘The Legend of Zelda’ while implementing our own features alongside.
• While we have all our files within a single folder (without the use of packages), this evidently worked in our favour to create a Java application that works both on Linux and Windows. A lot of other groups experienced path sourcing errors when running their .jar file on Windows due to the way Linux and Windows treat file paths differently. However, for our group, everything was being accessed within a single folder and worked on the first try across platforms. This gives our application the freedom to run on any desired platform and enhances the usability of the code.
• Our code has very low coupling because the dependency of classes on each other is low. This allows us to make changes in any single class without affecting other classes in any major way. Our Java application consists of 3 primary classes (Home – starting state, Game – main state, EngGame – end state) and numerous helping classes. The three principal states work in sync and control the flow of the game. While our Game class is not highly cohesive, it does control the entire logic of our game. All other classes though are highly cohesive and are specific on their detailed performance requirements. We could have improved our game class by splitting the Game class into two classes but with the size of our targeted game, the team felt it was okay to have the entire game state in one logic block. Therefore, it is safe to say that our game has high cohesion (except for the Game class) and low coupling.
• The MVC pattern was used and allowed specific sorting of the classes in terms of their functionality.
• Our architecture provides us a stable base in continuing our game development process forward and proves to be architecturally superior.

Link to Page 5

https://github.com/uoa-cs302/2019-Java-Group10/wiki/Development-Issues