Reference no: EM133765800

Software Engineering

Assignment - Software Development

For this individual assessment task, you will use skills acquired through the lectures and tutorials to design, implement and debug a small program using sound software engineering principles.

You will be creating a GUI-based application to help manage actions in a role-playing game called Quest for the Crown (or QfC for short).

Learning outcomes:
S1. Apply software engineering principles to design and implement software applications.
S2. Operate CASE software to develop appropriate models of software systems.
S3. Develop comprehensive unit test suites.
A1. Write integrated reports, using appropriate models, providing detailed analysis of given textual scenarios.
A2. Implement software applications, using appropriate software engineering techniques, from a given textual scenario.

Assessment Details / Tasks
Your group needs to complete various tasks as outlined below and described further in the following pages.
Read the complete assignment, to understand the system that you need to develop.

Select or be assigned a partner that you will work collaboratively with to do the assignment. Email your lecturer when you have agreed on your partner and include the partner in the email recipient list. Anyone who has not selected a partner by early in week 9, will be randomly paired by the lecturer.
Perform appropriate analysis and design activities to plan the structure of the system. You will be required to submit a class diagram showing the relationship of classes and significant attributes and methods, and each person must make at least one sequence diagram for one of the potential actions that can be performed in the system. You can either use Enterprise Architect (available for download from Moodle in ‘Study Resources' section), or any other modelling software or website to create these diagrams. If the design changes while you code, you should update the diagrams to correspond with the code. The submitted diagram should match the final version of the code.

Gain access to a shared repository hosted on the GitHub classroom site. The initial repository will contain an empty Eclipse project suitable to be imported into Eclipse.

Code the system, using a test-driven development approach for at least all of the domain classes, and dividing the work approximately equally between you both. As you code (or design), make certain that you are applying relevant patterns (as taught in the lectures).

This will require you both to be regularly committing & pushing your work, and pulling/merging your partner's work using the repository, so that you gain the work changes done by the other person into your local copy of the repository. Remember that you may need to resolve conflicts that occur when you attempt to merge pulled code, if your partner has altered the same code lines as you had. Each person should be expected to make at least 10 separate commits of substance. You should not ever commit code which contains errors that prevent the compiler from working, or which leave the code incomplete in some way (e.g. committing a subclass without its superclass being in the repository).
When nearing submission time, assemble your personal written report containing things listed later under the heading "Submission Requirements". This report is expected to be done individually, without any help from other members of the group.

You are expected to work together over the course of at least a week, and most likely longer. Ideally you and your partner should conduct live meetings at the start and at various other stages, by having a Microsoft Teams call or meeting in person at an agreed time. All of you are entitled to create a new ‘Team' on Microsoft Teams where you can then set up meetings and conduct text- chats at other times, to coordinate your work.
If you feel that your partner is not adequately contributing and consequently preventing you from progressing, you should try to send them an email. If they haven't responded after 24 hours, you can send a second email and copy the lecturer into the email. If the partner is still not responding after another 24 hours then contact the lecturer, and the lecturer will then make direct contact with your partner (e.g. by telephone call) to attempt to resolve the issue.

Game Description: Quest for the Crown
Quest for the Crown is a work-in-progress role-playing game, for groups of friends to play together socially (sitting around a table).
Adventuring players explore a mythical world looking for a crown to place onto one of the player's heads, but along the way find monsters that try to attack, and objects such as weapons and magical wands that may help them avoid the monster's attacks. Players can engage in combat with monsters to reduce or eliminate the threat they pose.
One person is chosen as the Tactician, whose role is to describe the behaviour of monsters, and interpret the actions of other players. The Tactician does not participate in the game themselves, rather, they manage all of the details of the encounters (i.e. they are the coordinator of the game). The Tactician announces whose turn it is. The Tactician also interprets the effect of each player's actions (such as attacks on the monsters). The Tactician also acts on behalf of the monsters (making the decisions about whether monsters will attack a player or move).
Your group is tasked with creating a standalone software product that allows the Tactician to manage this game (by keeping track of data and performing the calculations/actions so that the Tactician doesn't need to use pen and paper).

The following are the ‘rules' regarding players and monsters and how they can interact to effect each other, and how the game world is designed:
The game takes place in a world that involves neighbouring spatial zones. The diagram on the right is an example of a spatial world you might like to create (each square represents a separate zone). This example has 9 zones. The world(s) that you create should have at least 4 zones but at most 9 zones.
Each player-controlled entity, and each non-player-controlled entity or object, can only be in one zone at a time. But multiple entities can be simultaneously in a particular zone.
Movement between zones is either west, east, north or south and is only possible if there is a zone that is touching in that direction.

Each Player and Monster has five properties: Life, Health, Speed, Power, and Defense.
Each Player and Monster starts the game in a random zone.
At the start of a round, all Players and Monsters are allocated a number of turns equal to their Speed. Each Monster's Health is set to be the same as their Life.
The order in which these turns occur is randomized.
Once all turns for the current round are completed, a new round begins with a new set of turns allocated in the same way.
When it is time for a particular player or monster to have their turn (remember the Tactician is responsible for all input), information about the current zone they are in is to be displayed, such as what entities and collectible objects are in the zone. If any entity is dead, this is indicated.
If a Monster or Player's Health is reduced to zero, it becomes dead and cannot take any more turns for the remainder of the game (unless revived - see below). If all Monsters are dead or all Players are dead the game is complete.
There are several objects randomly spread across the zones which players can collect and then later can use.
One object is the Crown. If a player has collected and later uses the Crown on another player (putting it on that player's head), the game is complete (the players winning). They cannot use the crown on themselves.
Other objects include some magic wands which can be used on a player or a monster:
- The yellow wand will cause the target on which it is used, to become stunned for the next round - it won't be able to do anything (no ‘turns').
- The green wand will have a 50% chance of success. If successful, the Player's Power amount is added to the other Player's Health. (Note that a player's Health cannot ever go higher than their Life).
- The red wand will halve the health of the target - if the target's health is currently 1, they will become dead.
- The blue wand can only be used on a dead player. The target player will be brought back to life with their Health equal to 50% of their Life. They cannot participate in the rest of this round.
Other objects include some weapons. The different types of weapons have different effects on the target.
On their turn, a Monster can only choose to Move or to Attack a Player.
On their turn, Players can choose to:
- Move
- Collect an object
- Drop an object
- Use an object
Each Monster can be one of three types: Lightning, Wood, Metal.
Players can have weapons if they find and collect them. They can only use one weapon at a time. Collecting a weapon will simply add it to the items being carried by the player. These weapons have the same three types as monsters, with the following effects when used:
- Lightning weapons do double damage to Metal monsters, and half damage to Wood
monsters;
- Wood weapons do double damage to Lightning monsters, and half damage to Metal
monsters;
- Metal weapons do double damage to Wood monsters, and half damage to Lightning
monsters;

The following are explanations of how each action works:
Attack a Player (Monster only): Damages a player (as specified by the Tactician). The Player's Defence is subtracted from the monster's Power and the result is subtracted from the Player's Health (unless negative). Monsters will always do a minimum of 1 damage.

Move: Both players and monsters can move. They must choose a valid direction for the current zone they are in and then will move into the zone in the indicated direction (if they select an invalid zone, they should try again until they select a valid zone, as part of the current turn). Once moved, they cannot be influenced or affected by the entities that are in their previous zone, but they can be affected by the entities that are in the new zone where

they have arrived.
Collect an object (Player only): The player chooses to pick-up an object that has been found in the current zone, to carry as they journey around.
Drop an object (Player only): The player chooses to drop an object that is in their personal collected items, so that it is now in the current zone where the player is. The player or another player could then collect it.
Use an object (Player only): The player chooses to use any of the objects which they have collected, and must specify which entity to use it on (the Tactician asks the Player which object and which target). If the object is a weapon, the monster's Defence is subtracted from the Player's Power and the result is subtracted from the Monster's Health. Players will always do a minimum of 1 damage. Calculation must take the type of the Monster and the type of weapon the player is using into account. If the object is a wand, it can only be used 2 times before it vanishes from the game (even if used once by one player, then dropped, when another player later collects it they will have just 1 use remaining).
There may be ambiguities or missing details in the above rules, please use your own judgement as appropriate. An example play session (text-only) may be made available in Moodle.

Essential Requirements:
The program is required to be written in Java.
Your program is intended to be used by the Tactician to manage the game and interactions. This should be via a GUI rather than the text console.
There are three distinct modes to the software:
Player Setup - The Tactician enters the details of the Players. Each Player's Health is initially set to their Life.
Monster Setup - The Tactician chooses one or more Monsters from a list, with pre-configured attributes. It is ok to have multiple identical type of Monsters in the world.
Main Game - When the Tactician has completed selecting the Monster details, the software enters the main game loop of rounds as described in the rules above. During this mode, the Tactician can enter information/actions as required, depending on which Player's or Monster's turn it is. After the round is complete, the software should prepare for the next round, and continue this way until an end-game condition has occurred.
The only person interacting with your software is the Tactician.
You must create 4 unique Monster types that the Tactician can select from. One of them should be named after yourself - if you were a Monster! (e.g. if your name is Dan, you might name a monster as "The Abominable Snow-Dan").
It is up to your group to break this high-level specification into smaller requirements. You are the owner of this project, and can make any design decisions necessary to implement the software.
Fundamentally, your software should enable the Tactician to manage a play scenario like the one available on Moodle (with your own Monsters).

Additional Requirements:
Your software must be developed with comprehensive Unit Testing using JUnit 5 - the best way to achieve this reliably is to use a Test-Driven Development approach from the start.
You are expected to follow good design and coding principles and practices learned in lectures. You should use applicable design patterns, use appropriate refactoring as you go (to remove code bad smells). You must use at least some degree of automated testing using JUnit to run unit testing and regression testing of your code.
You are expected to thoroughly test each functionality you add: for how it handles invalid or unexpected input, for success cases, for failure cases, positive results, negative results, boundary conditions, etc.

Optional Challenge!
Optionally, you may extend the game in interesting ways but preserve the essential requirements. An additional 2 bonus marks for the ‘product' portion of marks, are available for creative and technically sound extensions to the software.
Some examples of extensions which may be accepted are:
Adding images and/or animations.
Introducing more complex game mechanics, such as players becoming unconscious, or poisoned, or immune for a number of turns, or objects having a weight and players having a maximum capacity of weight they can carry.
Saving Player data so it persists between program launches
Adding more Monster types into the program
Configuring your Tactician software as a server, and creating Player client software for handling player actions (highly difficult)

Submission Requirements
Along with the well-written code and comprehensive unit tests covering all functionalities of the game, you are individually expected to prepare a report which includes the following:
A personal reflection (approx. 500 words) which discusses your views on your group's approach to software development in developing the game. Indicate any technical difficulties (of coding) which you personally encountered, and how you went about solving them, and also any personal insights you had about the appropriateness of design choices made along the way. If you had trouble with your partner, you can also discuss any personal insights you had about teamwork but this should only be a minor part.
Discussion of the design patterns applied in the software. Clearly identify which pattern has been used, and where, giving some code examples as evidence to support your explanation. This needs to be your own explanation.
A class diagram (or set of diagrams) of the game showing all classes (concrete and abstract) and interfaces. This should match your partner's and the final code. Field's types and method's parameters/return types are optional.
A sequence diagram of a part of the program that you personally worked on solving which involves several different classes (as lifelines for receiving/sending of messages). It should correspond to the method calls in the code.
An explanation of 3 sets of your unit tests that had very different types of purpose to each other, explaining what you were trying to achieve by those tests (this can be written in code comments in the test class, or in the document). Explain why you chose the particular assertions, the particular set-up prior to the assertion, and the particular values. Try to show explain both a test which is expected to make a change, and another test which is expected to prevent a change for invalid attempt. Avoid discussing basic value-get tests, try to explain more complex tests.
A statement of completion indicating what portions of the final code you personally worked on in your group's implementation, and note any major omissions for the group; and
A statement of assistance showing what help you may have obtained, found, or utilised, clearly indicating which components (if any) are work adapted from elsewhere*.

* If you use any third-party code, including code from online tutorials or examples, ensure it is available under an appropriate license and that it is acknowledged both in your report and in your source code. This applies even to code that is available in the public domain or under licenses that do not require attribution. It is expected that the vast majority of your submission is your group's own work. You should avoid using generative AI tools other than any functionality built-into Eclipse.