Refactor TACH.json to addressbook.json and fix some errors in ug and dg

docs/DeveloperGuide.md

@@ -106,7 +106,7 @@ The **API** of this component is specified in [`Ui.java`](https://github.com/AY2
 
 ![Structure of the UI Component](images/UiClassDiagram.png)
 
-The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the visible GUI.
+The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `StudentListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the visible GUI.
 
 The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/AY2122S2-CS2103T-W15-3/tp/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/AY2122S2-CS2103T-W15-3/tp/tree/master/src/main/resources/view/MainWindow.fxml)
 
@@ -115,7 +115,7 @@ The `UI` component,
 * executes user commands using the `Logic` component.
 * listens for changes to `Model` data so that the UI can be updated with the modified data.
 * keeps a reference to the `Logic` component, because the `UI` relies on the `Logic` to execute commands.
-* depends on some classes in the `Model` component, as it displays `Person` object residing in the `Model`.
+* depends on some classes in the `Model` component, as it displays `Student` object residing in the `Model`.
 
 ### Logic component
 
@@ -128,7 +128,7 @@ Here's a (partial) class diagram of the `Logic` component:
 How the `Logic` component works:
 1. When `Logic` is called upon to execute a command, it uses the `AddressBookParser` class to parse the user command.
 1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `AddCommand`) which is executed by the `LogicManager`.
-1. The command can communicate with the `Model` when it is executed (e.g. to add a person).
+1. The command can communicate with the `Model` when it is executed (e.g. to add a student).
 1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
 
 The Sequence Diagram below illustrates the interactions within the `Logic` component for the `execute("delete 1")` API call.
@@ -156,12 +156,12 @@ Go back to **[Table of Contents](#table-of-contents)**
 
 The `Model` component,
 
-* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object).
-* stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList<Person>` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
+* stores the address book data i.e., all `Student` objects (which are contained in a `UniqueStudentList` object).
+* stores the currently 'selected' `Student` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList<Student>` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change.
 * stores a `UserPref` object that represents the user’s preferences. This is exposed to the outside as a `ReadOnlyUserPref` objects.
 * does not depend on any of the other three components (as the `Model` represents data entities of the domain, they should make sense on their own without depending on other components)
 
-<div markdown="span" class="alert alert-info">:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Tag` list in the `AddressBook`, which `Person` references. This allows `AddressBook` to only require one `Tag` object per unique tag, instead of each `Person` needing their own `Tag` objects.<br>
+<div markdown="span" class="alert alert-info">:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Tag` list in the `AddressBook`, which `Student` references. This allows `AddressBook` to only require one `Tag` object per unique tag, instead of each `Student` needing their own `Tag` objects.<br>
 
 <img src="images/BetterModelClassDiagram.png" width="450" />
 
@@ -300,7 +300,7 @@ Rationale:
 
 #### Example usage scenario and how the `addtg` mechanism behaves
 
-When the user executes `addtg 2 tg/CS2103T W15-3 tg/CS2101 G08` command to add a tutorial group to the 2nd person listed in the address book.
+When the user executes `addtg 2 tg/CS2103T W15-3 tg/CS2101 G08` command to add a tutorial group to the 2nd student listed in the address book.
 
 The following sequence diagram shows how the `addtg` operation works:
 
@@ -353,7 +353,7 @@ and `Parser`s.
 type in a number than the entirety of someone's name. It is also distinct and much less vague.
 
 
-- Only one tutorial group can be deleted at a time. If a person has some tutorial groups but not all
+- Only one tutorial group can be deleted at a time. If a student has some tutorial groups but not all
 tutorial groups to be deleted, what should the command do? Making it such that only one tutorial group can
 be deleted at a time prevents ambiguity in contrast to if several tutorial groups can be deleted at a time.
 
@@ -746,7 +746,7 @@ testers are expected to do more *exploratory* testing.
    1. Re-launch the app by double-clicking the jar file.<br>
        Expected: The most recent window size and location is retained.
 
-### Deleting a person
+### Deleting a student
 
 1. Deleting a student while all students are being shown
 
@@ -777,7 +777,7 @@ testers are expected to do more *exploratory* testing.
 * Troubleshooting with corrupted files:
    1. Prerequisite: Corrupted data file.
        * To simulate a corrupted data file:
-         * Open the data folder in the folder where TACH is in. Edit TACH.json and change one of the fields to an invalid one 
+         * Open the data folder in the folder where TACH is in. Edit addressbook.json and change one of the fields to an invalid one 
          e.g. Add a `!` at the end of Irfan's email.
            i.e. change from
              > "name" : "Irfan Ibrahim",
@@ -793,7 +793,7 @@ testers are expected to do more *exploratory* testing.
             <br>"gitHub" : "",
             <br>"inTutorialGroups" : [ "CS2106 T01" ]
       
-            > **NOTE:** If there is no data file, open TACH and enter the command `list`. The data file should appeared in the folder where TACH is in.
+            > **NOTE:** If there is no data file, open TACH and enter the command `list`. The data file should appear in the folder where TACH is in.
    2. Test case: Corrupted data file 
    <br>Open the data folder in the folder where TACH is in. Edit all the data such that it meets the requirement stated here.[Input Requirements](https://ay2122s2-cs2103t-w15-3.github.io/tp/UserGuide.html#input-requirements) 
    <br> Expected: TACH will now load the data file and not an empty one.

docs/UserGuide.md

@@ -446,7 +446,7 @@ TACH data is saved in your computer's [hard disk](#glossary) automatically after
 
 ## Editing the data file
 
-TACH data is saved as a [JSON file](#glossary) under `[TACH file location]/data/tach.json`. <br>
+TACH data is saved as a [JSON file](#glossary) under `[TACH file location]/data/addressbook.json`. <br>
 **You should not edit the data file directly unless you are absolutely sure of what you are doing!** <br>
 Only advanced users who are absolutely familiar with the data format should try updating the data directly by editing the data file.