[SOLVED] AE1ISO Coursework 04

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 zips 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.