Update README.md

Author: kmargtaylor

README.md

@@ -1,28 +1,34 @@
-# **Project 6**
-Edited to reflect changes for new project-6-release 
+# **Project 7**
 
 ## **Design Overview:**
-We used a command pattern and undoable interface to implement Undo and Redo. It consisted of two deques, because they are faster than stacks according to the internet. The Command Manager has six children commands: DeleteCommand, AddNoteCommand, MoveCommand, SelectCommand, GroupCommand and StretchCommand. 
-We wanted to have a buttonController and ClickController with their owm FXML files to refactor TuneComposer but ran into techincal debt and reverted back to having everything in TuneComposer. We fixed several small issues related to the code reviews, but could not accomplish the refactoring issues due to technical debt. 
+We made five new classes FileSaver, XMLParser, ClipboardWrapper, PasteCommand, and CutCommand. FileSaver is responsible for saving files in the directory the user chooses in the save dialog. XML parser takes an XML file with notes and gestures represented by strings in it and turns them into playables. ClipboardWrapper changes notes and gestures from XML to Playables (and the other way around) and pushes and pops these to the clipboard. PasteCommand and CutCommand take a Collection of playables and add or remove them from the composition. They can be undone and redone. 
 
-We made it so that menu items are disabled when appropriate. 
+From feedback for earlier projects, we finally implemented platform independent keyboard shortcuts and resolved some generics. 
 
-## **Elegancy:**
-Our Command Manager is by far the most elegant class in this project. This class does one thing, manages all 6 commands, and it does it well(Single Responsibility Principle). On the other side of the same principle, our tunecomposer class has many responsibilites making it quite inelegant as well as being lengthy. As noted in Design Overview, we tried to refactor into multiple different classes but ran into technical debt. Despites its inelegancy, TuneComposer is the only class that deals with and knows about the set of playables, gestures and notes, making it slightly less bad. In reference to the other classes, our Group Command and Add Note Command are essentially the same thing but one deals with gestures and the other with notes making it inelegant for having code duplication. 
+## **Elegance:**
+We were able to use the CommandManager that we made in the last project to quickly and easily add the new functionality of making cut and paste redo/undoable. CommandManager is extensible which is a characteristic of elegant software. Command pattern. 
 
-We coded to interfaces because we referred to Collections instead of specific classes. 
+The XMLParser uses recursion and follows the single-responsibility principle of only doing one thing. 
 
-## **Velocity:**
-We thought that each of the commands classes would be just 1 story point, the command manager 6 points, and refactoring around 3 points. In reality, the command classes did take around 1 story point per and the command manager took around 8. The Stretch, Move, and Select commands were much more difficult to implement than AddNote so we should have given them more story points. The refactoring however took well over 25 person-hours and we ended up just reverting all of our changes back due to the technical debt established. In project 5 we did no refactoring so most of the project 5 time was actually working on implementing the requirements, while project 6 we spent alot of time working on understanding how to have multiple FXML files and how to connect them all together. We believe that if we did not have to deal with the refactoring and its resulting technical debt and focused on the requirements we would have been able to accomplish this project more elegantly.
+Not Elegant: 
+FileSaver should probably have the code for open in addition to the code for save because now FileChooser is used in two different classes. 
+We have an instrument in XML parser that is only used to make a different instrument because we couldn't figure out how to go from an XML string to an instrument. 
+When we convert something into XML we call the toString method because we could not figure out in the amount of time we had the serializable interface. 
+
+We have high coupling between TuneComposer and all our other classes.  
 
-Since the original deadline, we have spent an additional 20 person hours trying to get more of the requirements to work. We met with Janet many times to figure out how to get stuff to work and what tasks we should prioritize. We hope to be able to refactor and fix more issues that have been pending for a while before we submit project 7 but we are going to prioritize the implementation requirements first because we did not for this project and that delayed our progress significantly. 
+## **Velocity:**
+We thought that Copy,Cut,and Paste Commands would each take 1 story point. We estimated that XML Parser,ClipboardWrapper, and FileSaver would each be 2 story points. Addtionally, we thought that implementing Save,Open,and New would each take 1 story point.Other miscellaneous implementation tasks (such as disabling menu items and adding new menu items) would take 1 story point total. In total, that is 13 story points.  
+We spent a total of 40 person hours on this project. These 40 hours were in the span of one week since the first week that we had to do this project we were still working on implementing the previous project. Since we completed this project in a week, we did not have the time to make it as elegant as we would have liked or refactor. 
+The ratio of points to person hours is 13/40 = .3 story points per hour.
 
 ## **Team Retrospective:**
-It was hard for all us to meet together, and most of our work time was spent in groups of two or three people who were available at a given time. This made it hard to get a decent planned design that we all agreed on. Also because we met in groups of two or three, it meant that those who were not there got left out of the loop which led to confusion about the project's direction. In the future we will work on projects everyday from day 1 till it is due.
+We spent so much time on this project because we really struggled with the previous one and really wanted to make sure we were able to complete this project. We ended up meeting in groups of 2 or 3 everyday of the week. Spending time every single day on the project worked well as we were able to get much more of this project completed in time compared to the last one. 
+
 
+We weren't sure if you should be abel to save blank compositions or not but decided that you should since you are able to save blank documents in Word. 
 
-Project 7:
-You can save blank compositions!
 
+Notes for future projects:
 Project 8:
 Warn the user if they will override a file