AE1ISO Coursework 04
Command based mail client maintenance (25%)
1. LearningObjectives
This coursework is designed to give you further experience with refactoring and maintaining existing code. This coursework will allow you to gain experience working with:
- Debugging
- Refactoring
- Improving
- Enhancing/Evolution
- The importance of software quality
- Unit testing
2. Question
You will be provided with an existing command based mail client (similar to the one you may have created for CW03). For this assignment, you must use the provided solution as a starting point, not your previous coursework. Before beginning, you should spend some time reviewing the code, making sure that you understand the existing work and, if necessary, refactoring any convention problems (e.g. variable names) or bad practises (e.g. duplicated code), or functionality issues. You are free to change the code in any way you feel appropriate (including the interfaces). You may use your unit tests from CW03 (if appropriate) for testing the provided code – obviously, any issues found should be fixed.
10% of the overall marks will be for coding conventions. The other 90% are for functional correctness (i.e. does it work?), and for proof of your testing (worth about 90%/10%, respectively). Your maintenance/update tasks are numbered below, together with the weighting of each task towards your final grade. The weighting percentages indicate the total marks for that section: for example, Message Flags are worth 10% of the final grade, of which 9 marks will be for functional correctness, and 1 mark for proof of your testing.
1. Reply Command (5%) – You should be able to reply to the last viewed message using the “reply” command. This should be the same as the “compose” command, but with the recipient and subject already known (Prepend “RE: ” to the start of subject from the message received).
2a. Message flags (10%) – The user should be able to ‘flag’ messages with colours. The command to flag a message should be ‘flag [colour] [messageID]’. The available colours are “red”, ”green”, and “blue”. The flags should be seen when listing messages using the “list” command, as seen in the expected output. If there is no flag on a message, the flag “noflag” should show.
2b. Smart folders (15%) – A ‘smart folder’ is a folder which contains references to messages with a certain property, for example all messages with a green flag. Messages cannot be moved into a smart folder manually, they can only be referenced in the smart folder if they meet certain criteria. Deleting a message from a smart folder should delete the message from all folders. Smart folders cannot be manually created, and by default there is one smart folder for each colour flag, named by the colour (in lowercase). e.g., “cf green” should change to the smartfolder “green,” which contains a list of all messages with a green flag, the same for red and blue (note lowercase). Smart folders for red and blue should also exist. There is no command to create new smart folders.
3.a Undo (20%) – You should be able to put each command onto a ‘stack’ of commands, and add an undo method for each command. You will then be able to ‘pop’ the last completed command and undo it. This allows for an undo feature, which should be triggered by the command ‘undo’. If a command cannot be undone, the error “Error: Cannot undo command: class [classname]” (e.g. Error: Cannot undo command: class CommandListMessages) should be printed. An example of an “undo” command is in the expected output. Your undo commands should follow a similar output to when a command is executed. Note that if a command fails for any reason, it should not be added to the undo stack, e.g., if message 999 is marked as read which fails as message 999 does not exist, the next undo should be the last successful command and not the mark command which failed. Note the error message in the expected output for if there are no commands to undo.
Commands which are undoable are:
Move – This will move the email back to its previous location.
Create folder – this will remove the folder that was created.
Mark – this will revert any changes made by the mark command (e.g mark as read or unread). Flag – This will undo any changes made by the last flag command.
Rename – This will rename back to the original value.
Change folder – will change back to the previous active folder.
Undo alias – this will remove any alias which was added last from the previous command.
It is not
incoming message rule, undo receive, undo flag or undo quit.
a requirement to implement undo delete, undo compose, undo sort, undo reply, undo new
Typing “undo” twice should not undo the last undo command, therefore it is important to consider which commands should be added to the undo stack (undo commands themselves should not be added to the stack).
3.b Redo (5%) – The command “redo” should redo a command which was previously undone. You should be able to redo multiple times if there have been multiple undo commands. Remember that some commands which may not be able to ‘undo’ (for example list), should be able to redo. Every time a new command is issued which is successful, the “redo” stack should be cleared. For example, if a move message command is executed, then undone, this is added to the redo stack. If we then change directory and type “redo”, the move message command would not be able to be undone (as the state has since changed), so each time a successful command is executed the redo stack needs
clearing, this example should output “Error: No command to redo” because the redo stack has been cleared.
4. Incoming message rules (20%) – Incoming message rules can be created which specify which folder new messages should arrive in. For example, all messages containing ‘spam’ as part of the address field could be put into a “junk” folder. A rule requires the following:
- A (valid) folder name to put the message in if the rule applies.
- A value representing which part of the message to search for the given String (Recipient
address, Sender address, Subject or Body)
- A String containing the text to look for in the message.
If more than one rule applies to a message, the first rule which was created should be used. If a rule is created after messages are already received, any messages in the “inbox” directory should be re- assessed to check if they are in the correct folder and any future incoming messages should be assessed. A rule can be created using the following command:
cr [foldername] [recipient|sender|subject|body] [search]
5. Aliases for existing commands (15%) – Some users would like to create aliases for existing commands. Aliases should be created using the command:
alias [original] [new]
For example:
alias receive rec
The user can then use the alias in place of the original command; the original command should still function. Following on from the example, the user can use “rec” or “receive”.
3. Expected Output
See expected output document available on Moodle.
4. Submission and Assessment
You are required to submit a .zip file containing all of your source code within one directory (not using packages) to TMA. It would be sensible to include your username in the zip’s filename, for example “AE1ISO-CW04-zy123456.zip”. Do not submit duplicates of your code, inside your directory there should be only one instance of each .java file. You should submit all files required to compile your work, including the provided jar file.