Merge pull request #203 from getsquared/update-dg

Fix DG typos

docs/DeveloperGuide.md

@@ -13,7 +13,7 @@
 
 ## **Acknowledgements**
 
-* This project was based on the [AddressBook-Level3 (AB3](https://se-education.org/addressbook-level3/) from [SE-EDU](https://se-education.org/).
+* This project was based on the [AddressBook-Level3 (AB3)](https://se-education.org/addressbook-level3/) from [SE-EDU](https://se-education.org/).
 * The `remark` command in this project was implemented with reference to the CS2103T AB3 [Tutorial: Adding a command](https://nus-cs2103-ay2324s2.github.io/tp/tutorials/AddRemark.html).
 * The user guide approach in breakdown of sections and header styling was inspired by [ArtBuddy](https://ay2223s1-cs2103t-w11-3.github.io/tp/UserGuide.html)
 --------------------------------------------------------------------------------------------------------------------
@@ -58,7 +58,7 @@ The *Sequence Diagram* below shows how the components interact with each other f
 Each of the four main components (also shown in the diagram above),
 
 * defines its *API* in an `interface` with the same name as the Component.
-* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point.
+* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point).
 
 For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
 
@@ -104,19 +104,19 @@ The sequence diagram below illustrates the interactions within the `Logic` compo
 
 How the `Logic` component works:
 
-1. When `Logic` is called upon to execute a command, it is passed to an `AddressBookParser` object which in turn creates a parser that matches the command (e.g., `DeleteCommandParser`) and uses it to parse the command.
-1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `DeleteCommand`) which is executed by the `LogicManager`.
-1. The command can communicate with the `Model` when it is executed (e.g. to delete a person).<br>
+1. When `Logic` is called upon to execute a command, it is passed to an `AddressBookParser` object which in turn creates a parser that matches the command (e.g. `DeleteCommandParser`) and uses it to parse the command.
+2. This results in a `Command` object (more precisely, an object of one of its subclasses e.g. `DeleteCommand`) which is executed by the `LogicManager`.
+3. The command can communicate with the `Model` when it is executed (e.g. to delete a person).<br>
    Note that although this is shown as a single step in the diagram above (for simplicity), in the code it can take several interactions (between the command object and the `Model`) to achieve.
-1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
+4. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`.
 
 Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command:
 
 <puml src="diagrams/ParserClasses.puml" width="600"/>
 
 How the parsing works:
-* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as a `Command` object.
-* All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing.
+* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g. `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g. `AddCommand`) which the `AddressBookParser` returns back as a `Command` object.
+* All `XYZCommandParser` classes (e.g. `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing.
 <div style="page-break-after: always;"></div>
 
 ### Model component
@@ -128,7 +128,7 @@ How the parsing works:
 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 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 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)
 
@@ -243,7 +243,7 @@ The following sequence diagram shows the `sort` operation:
 #### Design Considerations
 
 In order to keep `ModelManager#filteredPersons` as an immutable `final` field, we have decided not to modify the `filteredPersons` directly. Instead, we do the following:
-- we store the `Comparator<Person>` object in `ModelManager#personComparator`, which can be updated by `ModelManager#updateSortPersonComparator(Comparator<Person>)`.
+- We store the `Comparator<Person>` object in `ModelManager#personComparator`, which can be updated by `ModelManager#updateSortPersonComparator(Comparator<Person>)`.
 - When a sorted list of persons is needed, we call `ModelManager#getSortedFilteredPersonList()` which returns a new sorted list of persons sorted using the `ModelManager#personComparator`.
 
 This way, the original order of `ModelManager#filteredPersons` is preserved, and we can get a sorted list of persons when needed.
@@ -322,7 +322,6 @@ The method `ScheduleCommand#execute()` returns a CommandResult object which cont
   * The user can schedule an appointment for each client.
   * This is to prevent the schedule display from having too many schedules which can overcrowd the display.
   * This also keeps the command for scheduling and completing appointments simple as there are fewer commands available for the user.
-
 * Alternative (not taken): Multiple appointments per client.
   * Too many appointments in a single schedule display can make it hard to see for the user.
   * A much more complex GUI is also needed to support such a feature which will be too much work for the project.
@@ -355,7 +354,6 @@ The method `MarkCommand#execute()` returns a CommandResult object which contains
   * The user can mark a schedule as completed, then use `met` to update the last met of the client separately.
   * This is to streamline the completion and closing of open appointments to a single command.
   * Postponing an appointment is also in-built into the `schedule` command.
-
 * Alternative (not taken): Marking an appointment updates the last met for the client automatically.
   * Users may wish to complete or close an open appointment where they did not meet the client.
   * As Last Met cannot be updated to a future date that has yet to pass, this can introduce problems where users may want to close future appointments.
@@ -426,14 +424,13 @@ The following sequence diagram shows the deletepolicy operation:
   * The user can delete a policy using the PolicyID.
   * This allows user to delete the policy without having to type in the whole name of the policy which can be complicated and long.
   * This will allow the user to delete the policy using the PolicyID which is unique to each policy.
-
 * Alternative (not taken): Deleting a policy using PolicyName.
   * The user can delete a policy using the PolicyName.
   * This will cause the user to need to type in the whole policy name to delete the policy, which can be slower and more error-prone.
   * This will also result in the need for policy names saved within the client to be unique which may not be the case in real-world scenarios, different policies can have the same name.
 <div style="page-break-after: always;"></div>
 
-### Extensions to add command and edit command: Add birthday, edit birthday, add priority, edit priority features
+### Extensions to add command and edit command: birthday and priority features
 
 The add birthday and edit birthday features allow users to add and edit the birthday of a client. Birthdays support the birthday reminders feature. The birthday is stored in the `Birthday` class, which contains the birthday details such as day, month, and year. The `Birthday` class is part of the `Person` object in the `Model` component.
 
@@ -506,8 +503,8 @@ More on `PriorityValue` enum class
 
 **Value proposition**:
 
-* conveniently manage client details and schedules faster than a typical mouse/GUI driven app
-* Convenient tracking of when agent last checked up on clients (eg. reminders)
+* Conveniently manage client details and schedules faster than a typical mouse/GUI driven app
+* Convenient tracking of when agent last checked up on clients (e.g. reminders)
 * Organise client contacts details
 * Optimization by client’s importance (VIP status etc)
 * Monitor client’s insurance policies
@@ -1385,7 +1382,7 @@ their respective class methods should interact with each other, especially with
 We decided to simplify the process by restricting the user to 1 appointment per client as our initial beta version faced multiple bugs due to higher number of classes and functions when supporting multiple appointments per client.
 
 To implement the Reminders feature, we had to get the list of clients, so that we are able to filter out the clients that have appointments/ met is overdue/ or have upcoming birthdays, so that we can display them in the reminders panel. 
-However, the prior implementation in the `AddressBook` class of the method `getPersonList()` returns a unmodifiable list, which means that we are unable to use that list to get the new list of filtered out the clients that have appointments/ met is overdue/ or have upcoming birthdays.
+However, the prior implementation in the `AddressBook` class of the method `getPersonList()` returns an unmodifiable list, which means that we are unable to use that list to get the new list of filtered out the clients that have appointments/ met is overdue/ or have upcoming birthdays.
 Thus, we had to create methods within the `UniquePersonList` class to get the list of clients that have appointments/ met is overdue/ or have upcoming birthdays, so that we can display them in the reminders panel. Furthermore, we had to sort this new list so that the reminders will be displayed in the correct order.
 
 `set` is also saved in a separate txt file as it is not related to client traits. Hence, additional testing is needed to ensure the value that `set` updates is saved correctly and is able to handle