Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
FIT3077 Software Engineering:
Architecture and Design
Sprint 3 is individual assessment so students will be given an individual Monash GitLab repository provided based on their group’s repository state, at the following URL: https://git.infotech.monash.edu/fit3077-s1-2025/assignment-individual/<YOUR-STUDENT AUTH>. The repository has been set up and is ready to use.
The extensions are divided into three categories: (i) required, (ii) pick-from-the-list, and (iii) self-defined. For Sprint 3, you must implement one extension each from all three categories, respectively - so in total we have 3 extensions.
Required Extension
Note: we recommend you carefully consider the extensibility of your Sprint 2 implementation in order to determine which God/Power Card to add to the existing God/Power cards. As for Sprint 2, God/Power cards are to be randomly allocated to the available players.
Pick-From-The-List Extensions
- Dynamic configuration of the game. The game facilitates more than 2 players with a dynamic board configuration (e.g., not restricted to a 5x5 game board - a different number of rows and columns, with the board not necessarily in the shape of a square or rectangle, “holes” in the middle of the board). You can ask the user how many players will play at the start of that session. Regarding the board configuration, having an external medium (e.g., a file) would be helpful as you can easily change the board configuration there.
- Undo mechanism. The game facilitates the user to undo the last two turns (the turn of the previous player, plus the one of their own). This feature must move the workers back into the positions they were and any levels/domes that have been built must also be reverted.
- Save-Load system. The game facilitates the user to save a game to an external medium (i.e. a file) and being able to load saved games from external files.
Note: to facilitate debugging of such a feature, we recommend using a text-based file format that you can open and inspect in a text editor. Binary formats, in general, make debugging much more difficult.3
- Timer: each player gets a fixed amount of time (e.g., 15 minutes) for “thinking” and executing their turns. Once a player has completed their turn, their clock pauses and the clock starts for the next player. If the clock of a player reaches zero, this player loses the game. The timers for each player need to be made visible in the user interface so that each player can see how much time they have left.
If you decide to implement more than one of these extensions, please choose one of them that we will use for assessment.
Self-Defined Extensions
Examples include (but these are only examples to stimulate curiosity) - you may not implement any of these examples:
- Adding a mini-guide for each god/power card, linking to mythology, history, aligning to the human value of ‘respect for tradition’.
- Tying up with a local charity organisation and allowing the player to make a donation to the charity every time they win 5 games in a row, aligning with the human value of ‘social justice’ (under universalism) and ‘helpful’ (under benevolence).
We hope that you will have many great ideas on how to extend the game.
Further details of each of these tasks is given below.
Sprint 3 Deliverables (40% of final unit mark – Individual Assessment)
- Revised design: an updated class diagram that illustrates what changes you have made to design/implementation from Sprint 2 in order to add the extensions for Sprint 3. If in the process of working on the extensions you fixed any defects that were in Sprint 2, please include them in the updated class diagram as well. You must highlight what has changed (e.g. using colour or annotations, before vs after) compared to your Sprint 2 class design so that the teaching team can easily identify the changes made.
As in Sprint 2, the aim is to use a class diagram to help you think through the changes that are to be made in order to cover the chosen extensions. If you have sketches of work in progress, please add them to the repository. We are more interested in seeing a progression of work than a “documentation” of your final implementation. Hence it is perfectly fine to split the changes into multiple diagrams that each highlight specific changes that you are making.
Focus on class names, relationships between classes and cardinalities. You do not need to add method names and parameters unless they are deemed to be really important for the understanding of your design.
It is perfectly fine to create a class diagram by hand (on paper) and include a scanned version thereof in your submission. You do not need to create the class diagram using an electronic tool if you prefer to draw it on paper. Although we do not require the submission of any sequence diagrams (or similar), it is strongly recommended that you reflect on interaction patterns in your design before jumping into any coding. If you start with the latter, it may actually take you longer to get the code working.
Note: Reverse engineering designs from source code is – most of the time – a waste of your time and defeats the purpose of doing a design in the first instance. It is OK if your design is not a perfect match with the source code you are creating as long as the difference is not too substantial and you provide a brief summary what the difference is. We reserve the right to penalise students where we detect an obvious reverse engineering of diagrams from a code base.
- Provide a minimum of 3 CRC (Class-Responsibility-Collaborator) cards for non-trivial classes based on the extensions that you have chosen to implement (not for classes that existed from Sprint 2). Please keep in mind that CRC cards should be no larger than size A5 as otherwise you are adding too many responsibilities. Please also note that CRC cards are a tool that help with design/implementation and should be used as such (and not as a tool to document a final implementation), hence if you have created more than three CRC cards, feel free to include them (not bonus or penalty will be applied for doing so).
- Design Rationales (explaining the ‘Why’s)
- Explain interfaces and classes that you have included in your updated design and provide the reasons why those are needed. Could its responsibilities have been handled by an existing class? Why and why not? Did you need to reassign responsibilities from Sprint 2 to facilitate the extensions for Sprint 3?
- Explain any alternative designs that you have come up with and the reason why you might use or might not use that design at all.
- If you have used any Design Patterns in the design, explain why and where you have applied them. If you have not used any Design Patterns for any of your extensions, list at least 3 known Design Patterns (not the same as you may have discussed in Sprint 2) and justify why they were not appropriate to be used in your design.
- Explain how your selected third extension aligns with the claimed human value.
2. Tech-based Software Prototype
- Fully functional/playable implementation of the Santorini Board game according to the basic requirement as well as all extensions that you have decided to add/implement.
- Create an executable of the Santorini Board game together with clear instructions on how to build and run it on the target platform (as per previous sprints).
- If we cannot run the executable, the tech-based final prototype will be assessed as a fail (below ‘poor’).
3. Reflection on Sprint 2 Design
- A reflection on how easy/difficult/hard it was to incorporate the extensions you have implemented to the design and implementation from Sprint 2.
- Please discuss the level of difficulty for each of the incorporated extensions separately and briefly outline what aspects of the Sprint 2 design/implementation (for example, distribution of system intelligence; presence of code smells; use of appropriate Design Patterns) made a particular extension easy/difficult to address. If you were to go back to Sprint 2 and could start all over again, what would you change so that the extension under consideration would have been easier to add?
Note: this is one of the key learning aspects of Sprint 3 - reflecting on the constraints introduced by your Sprint 2 design/implementation and what you would do differently in the future if you were in a similar situation.
4. Video Demonstrations
- Prepare and submit a video that demonstrates your game implementation (focuses on your extensions) of maximum 3 minutes - you should aim for 2-3 minutes of video. You do not need to demonstrate the compilation process (as was required for Sprint 2).
- You are required to submit the demonstration video through Moodle as per the submission instructions given towards the end of this document.
- Focus on the functionality you have added in this sprint. Give a brief overview of what the extensions are that you have made and demonstrate how they work.
- The demonstration of the loading/saving functionality (where applicable) must include the contents of a file that was created as the outcome of saving a game’s state.
General Guidance
- Your implementation will still need to fully meet the basic requirements, where all standard rules of the Santorini Board game have been implemented.
- To boost your chances of getting the best mark you can, ensure that frequent and multiple Git commits are made throughout the Sprint, and that all submission instructions are followed. All artefacts that are part of your Sprint 3 submission (unless otherwise stated) must be available in the repository.
- In this assessment, you can use generative artificial intelligence (AI) in order to consider design alternatives/options and explore their advantages and disadvantages. You can also use generative AI to create art work if you wish to do so. You may even use Generative AI to generate ideas for extensions. Your final design decisions should be your own (and justified if it matches AI recommendation) along with your rationale description.
- Any use of generative AI must be appropriately acknowledged (see Learn HQ).
- The remainder of the description is the same as with previous sprints, except see new rubric below.
The precise submission instructions are given towards the end of this document - please carefully read them to ensure your submission is in line with expectations.