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).
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.
@@ -119,9 +138,9 @@ Here's a (partial) class diagram of the `Logic` component:
-The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete 1")` API call as an example.
+The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete EID1234-5678")` API call as an example.
-
+
++
:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Department` list in the `AddressBook`, which `Employee` references. This allows `AddressBook` to only require one `Department` object per unique department, instead of each `Employee` needing their own `Department` objects.
-
+
@@ -176,135 +195,14 @@ The `Storage` component,
Classes used by multiple components are in the `seedu.address.commons` package.
+
+
--------------------------------------------------------------------------------------------------------------------
## **Implementation**
This section describes some noteworthy details on how certain features are implemented.
-### \[Proposed\] Undo/redo feature
-
-#### Proposed Implementation
-
-The proposed undo/redo mechanism is facilitated by `VersionedAddressBook`. It extends `AddressBook` with an undo/redo history, stored internally as an `addressBookStateList` and `currentStatePointer`. Additionally, it implements the following operations:
-
-* `VersionedAddressBook#commit()` — Saves the current address book state in its history.
-* `VersionedAddressBook#undo()` — Restores the previous address book state from its history.
-* `VersionedAddressBook#redo()` — Restores a previously undone address book state from its history.
-
-These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and `Model#redoAddressBook()` respectively.
-
-Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
-
-Step 1. The user launches the application for the first time. The `VersionedAddressBook` will be initialized with the initial address book state, and the `currentStatePointer` pointing to that single address book state.
-
-
-
-Step 2. The user executes `delete EID1234-5678` command to delete an employee in the address book. The `delete` command calls `Model#commitAddressBook()`, causing the modified state of the address book after the `delete EID1234-5678` command executes to be saved in the `addressBookStateList`, and the `currentStatePointer` is shifted to the newly inserted address book state.
-
-
-
-Step 3. The user executes `add n/David …` to add a new employee. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
-
-
-
--
+
:information_source: **Note:** If a command fails its execution, it will not call `Model#commitAddressBook()`, so the address book state will not be saved into the `addressBookStateList`.
-
-
-
-Step 4. The user now decides that adding the employee was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#undoAddressBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous address book state, and restores the address book to that state.
-
-
-
-:information_source: **Note:** If the `currentStatePointer` is at index 0, pointing to the initial AddressBook state, then there are no previous AddressBook states to restore. The `undo` command uses `Model#canUndoAddressBook()` to check if this is the case. If so, it will return an error to the user rather
-than attempting to perform the undo.
-
-
-
-The following sequence diagram shows how the undo operation works:
-
-
-
-:information_source: **Note:** The lifeline for `UndoCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-
-
-
-The `redo` command does the opposite — it calls `Model#redoAddressBook()`, which shifts the `currentStatePointer` once to the right, pointing to the previously undone state, and restores the address book to that state.
-
-:information_source: **Note:** If the `currentStatePointer` is at index `addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone AddressBook states to restore. The `redo` command uses `Model#canRedoAddressBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.
-
-
-
-Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such as `list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
-
-
-
-Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not pointing at the end of the `addressBookStateList`, all address book states after the `currentStatePointer` will be purged. Reason: It no longer makes sense to redo the `add n/David …` command. This is the behavior that most modern desktop applications follow.
-
-
-
-The following activity diagram summarizes what happens when a user executes a new command:
-
-
-
-#### Design considerations:
-
-**Aspect: How undo & redo executes:**
-
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
-
-* **Alternative 2:** Individual command knows how to undo/redo by
- itself.
- * Pros: Will use less memory (e.g. for `delete`, just save the employee being deleted).
- * Cons: We must ensure that the implementation of each individual command are correct.
-
-
-### Sort feature
-
-#### Implementation
-
-The sorting mechanism is facilitated by `SortCommandParser`. It implements the following operations:
-
-* `SortCommandParser#parse()` — Parses the input arguments by storing the prefixes of its respective values as an `ArgumentMultimap`,
-and creates a new `SortCommand` object with the parsed field and order.
-
-The `SortCommand` object then communicates with the `Model` API by calling the following methods:
-
-* `Model#updateSortedEmployeeList(field, order)` — Calls `sortEmployees` method of `AddressBook` class.
-* `AddressBook#sortEmployees(field, order)` — Calls `sortEmployees` method of `UniqueEmployeeList` class.
-* `UniqueEmployeeList#sortEmployees(field, order)` — Sorts the internal list according to the field and order given.
-
-The following sequence diagram below shows how the sort operation works:
-
-
-
-Given below is an example usage scenario for the command:
-
-**Step 1**: The user launches the application.
-
-**Step 2**: The user executes the `sort f/FIELD in/ORDER` command in the CLI
-(note that only `name`, `salary`, `overtime` and `leaves` fields, as well as `asc` and `desc` orders are valid).
-
-**Step 3**: The list of all employees in the employee book will be sorted accordingly.
-
-The following activity diagram summarizes what happens when a user executes the sort command:
-
-
-
-#### Design considerations:
-
-**Aspect: How sort executes:**
-
-* **Alternative 1 (current choice):** Sorts the internal list directly
- * Pros: Easy to implement.
- * Cons: Disable the ability to list by order of employee added.
-
-* **Alternative 2:** Performs a sort on a copied list in `ModelManager`.
- * Pros: Allows the `list` command to list all employees by the order they were added.
- * Cons: Different lists in the `ModelManager` class may cause inconsistencies when `find` and `sort` commands are called consecutively.
-
### Add Employee feature
The add employee feature allows HouR to add employees to the employee list.
@@ -397,61 +295,6 @@ The following activity diagram summarises what happens when a user executes the
* Pros: Shorter command execution, one less point of failure by eliminating the `model` class.
* Cons: May violate immutability within Employee and Model classes as well as SLAP by having `DeleteCommand#execute()` perform the editing directly.
-
-### Report feature
-
-#### Implementation
-
-The proposed reporting mechanism is facilitated by `ReportCommandParser`. It implements the following operations:
-
-* `ReportCommandParser#parse()` — Parses the input employee ID and creates a new `ReportCommand` object with the parsed employee ID.
-
-The `ReportCommand` object then communicates with the `Model` and `ReportStorage` APIs by calling the following methods:
-
-* `Model#getFilteredEmployeeList()` — Gets the existing employee list, which is then looped through to get the employee with the given employee ID.
-
-* `ReportStorage#saveReport(Report)` — Saves the report generated in `ReportCommand#execute()` by `ReportCommand#generateReport(employee)`, which is then stored on the hard disk as a `.txt` file.
-
-The method `ReportCommand#execute()` returns a `CommandResult` object, which stores information about the completion of the command.
-
-The following sequence diagram below shows how the report operation works:
-
-
-
-Given below is an example usage scenario for the command:
-
-**Step 1**: The user launches the application.
-
-**Step 2**: The user executes the `report id/EMPLOYEE_ID` command in the CLI.
-
-**Step 3**: A report will be generated for the employee with the given ID.
-
-The following activity diagram summarises what happens when a user executes the report command:
-
-
-
-#### Design considerations:
-
-**Aspect: Command-Model Interaction**
-
-* **Alternative 1 (current choice):** Utilise `Model#getFilteredEmployeeList()` to get the existing employee list, which is then looped through to get the employee with the given employee ID.
- * Pros: Maintain immutability within Employee and Model classes.
- * Cons: Longer command execution, requiring more parts to work together.
-
-* **Alternative 2:** Create methods in `Model` class specifically to get the employee with the given employee ID.
- * Pros: Shorter command execution.
- * Cons: May reduce immutability between Employee and Model classes.
-
-**Aspect: Command-Storage Interaction**
-
-* **Alternative 1 (current choice):** Utilise a dedicated storage class `ReportStorage` with the method `ReportStorage#saveReport(Report)` to save the report.
- * Pros: Maintain SRP and SLAP within the command class.
- * Cons: Longer command execution, requiring more parts to work together.
-
-* **Alternative 2:** Create methods in `ReportCommand` class to write and save the report.
- * Pros: Shorter command execution, one less point of failure by eliminating the `ReportStorage` class.
- * Cons: Less OOP, may violate SLAP within the command class.
-
### Find Employee feature
The find employee feature allows HouR to find employees that match the given search criteria from the employee list.
@@ -498,164 +341,76 @@ The following activity diagram summarises what happens when a user executes the
* Pros: Shorter command execution, one less point of failure by eliminating the `model` class.
* Cons: May violate immutability within FindCommand and Model classes as well as SLAP by having `FindCommand#execute()` perform the editing directly.
-### Reset feature
-
-The reset feature allows HouR to reset employee overtime hours and leaves.
+### Sort feature
#### Implementation
-The reset command mechanism is facilitated by `ResetCommandParser` class which implements the `Parser` interface.
-
-`ResetCommandParser#parse()` is exposed in the `Parser` interface as `Parse#parse()`.
+The sorting mechanism is facilitated by `SortCommandParser`. It implements the following operations:
-`ResetCommandParser` implements the following operations:
-* `ResetCommandParser#parse()` — Parses the input arguments by storing the index and the prefix of its respective values as an `ArgumentMultimap`,
-and creates a new `ResetCommand` object with the parsed field.
+* `SortCommandParser#parse()` — Parses the input arguments by storing the prefixes of its respective values as an `ArgumentMultimap`,
+and creates a new `SortCommand` object with the parsed field and order.
-The `ResetCommand` object then communicates with the `Model` API by calling the following methods:
-* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee` object which has been edited by `ResetCommand#execute()`.
-* `Model#updateFilteredEmployeeList(Predicate)` — Updates the view of the application to show all employees.
+The `SortCommand` object then communicates with the `Model` API by calling the following methods:
-The method `ResetCommand#execute()` returns a new `CommandResult` object, which stores information about the completion of the command.
+* `Model#updateSortedEmployeeList(field, order)` — Calls `sortEmployees` method of `AddressBook` class.
+* `AddressBook#sortEmployees(field, order)` — Calls `sortEmployees` method of `UniqueEmployeeList` class.
+* `UniqueEmployeeList#sortEmployees(field, order)` — Sorts the internal list according to the field and order given.
-The following sequence diagram below shows how the reset operation works:
+The following sequence diagram below shows how the sort operation works:
-
+
Given below is an example usage scenario for the command:
**Step 1**: The user launches the application.
-**Step 2**: The user executes the `reset f/FIELD` command in the CLI (note that only `overtime` and `leaves` are valid).
+**Step 2**: The user executes the `sort f/FIELD in/ORDER` command in the CLI
+(note that only `name`, `salary`, `overtime` and `leaves` fields, as well as `asc` and `desc` orders are valid).
-**Step 3**: The given field of all employees in the employee book will be reset to their default value.
+**Step 3**: The list of all employees in the employee book will be sorted accordingly.
-The following activity diagram summarizes what happens when a user executes the reset command:
+The following activity diagram summarizes what happens when a user executes the sort command:
-
+
#### Design considerations:
-**Aspect: Model-Employee Interaction:**
+**Aspect: How sort executes:**
-* **Alternative 1 (current choice):** Utilise `Model#setEmployee` to add the edited employee into the model, doing the direct editing in `ResetCommand#execute()`.
- * Pros: Maintain immutability within Employee and Model classes.
- * Cons: Potentially violates SRP.
+* **Alternative 1 (current choice):** Sorts the internal list directly
+ * Pros: Easy to implement.
+ * Cons: Disable the ability to list by order of employee added.
-* **Alternative 2:** Create methods in `Model` class specifically to edit the fields of the employees.
- * Pros: More OOP, follows SRP by not having `ResetCommand#execute()` perform the editing directly.
- * Cons: Longer command execution, requiring more parts to work together.
+* **Alternative 2:** Performs a sort on a copied list in `ModelManager`.
+ * Pros: Allows the `list` command to list all employees by the order they were added.
+ * Cons: Different lists in the `ModelManager` class may cause inconsistencies when `find` and `sort` commands are called consecutively.
-### Add Remark feature
+### Add Leave feature
-The add remark feature allows HouR to add employee remarks.
+The add leave feature allows HouR to manage employee leaves.
#### Implementation
-The add remark command mechanism is facilitated by `AddRemarkCommandParser` class which implements the `Parser` interface.
+The add leave command mechanism is facilitated by the `AddLeaveCommandParser` class which extends the `AddressbookParser`.
-`AddRemarkCommandParser#parse()` is exposed in the `Parser` interface as `Parse#parse()`.
+`AddLeaveCommandParser#parse()` overrides `Parser#parse()` in the Parser interface.
-`AddRemarkCommandParser` implements the following operations:
-* `AddRemarkCommandParser#parse()` — Parses the input arguments by storing the index and the prefix of its respective values as an `ArgumentMultimap`,
- and creates a new `AddRemarkCommand` object with the parsed id and remark.
+`AddLeaveCommandParser` implements the following operations:
-The `AddRemarkCommand` object then communicates with the `Model` API by calling the following methods:
-* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee` object which has been edited by `AddRemarkCommand#execute()`.
+* `AddLeaveCommandParser#parse()` — Parses the input arguments by storing the prefixes of its respective values as an `ArgumentMultimap`, and creates a new `AddLeaveCommand` object with the parsed employee ID, start date and end date.
+
+The `AddLeaveCommand` object then communicates with the `Model` API by calling the following methods:
+
+* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee` object which has been edited by `AddLeaveCommand#execute()`.
* `Model#updateFilteredEmployeeList(Predicate)` — Updates the view of the application to show all employees.
-The method `AddRemarkCommand#execute()` returns a new `CommandResult` object, which stores information about the completion of the command.
+The method `AddLeaveCommand#execute()` returns a `CommandResult` object, which stores information about the completion of the command.
-The following sequence diagram below shows how the add remark operation works:
+The diagram below details how the operation of adding leave date(s) works.
-
+
-Given below is an example usage scenario for the command:
-
-**Step 1**: The user launches the application.
-
-**Step 2**: The user executes the `addremark id/EMPLOYEE_ID r/REMARK` command in the CLI.
-
-**Step 3**: The given remark will be added to the remark list of the employee with the given id.
-
-**Aspect: Model-Employee Interaction:**
-
-* **Alternative 1 (current choice)**: Utilise `model#setEmployee` to add the edited employee into the model, doing the direct editing in `AddRemarkCommand#execute()`.
- * Pros: Maintain immutability within Employee and Model classes.
- * Cons: Potentially violates SRP.
-
-* **Alternative 2**: Create methods in model specifically to edit the `remarkList` attribute of the employee.
- * Pros: More OOP, follows SRP by not having `AddRemarkCommand#execute()` perform the editing directly.
- * Cons: Longer command execution, requires more parts to work together.
-
-### Delete Remark feature
-
-The delete remark feature allows HouR to delete employee remarks.
-
-#### Implementation
-
-The delete remark command mechanism is facilitated by `DeleteRemarkCommandParser` class which implements the `Parser` interface.
-
-`DeleteRemarkCommandParser#parse()` is exposed in the `Parser` interface as `Parse#parse()`.
-
-`DeleteRemarkCommandParser` implements the following operations:
-* `DeleteRemarkCommandParser#parse()` — Parses the input arguments by storing the index and the prefix of its respective values as an `ArgumentMultimap`,
- and creates a new `DeleteRemarkCommand` object with the parsed id and remark.
-
-The `DeleteRemarkCommand` object then communicates with the `Model` API by calling the following methods:
-* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee` object which has been edited by `DeleteRemarkCommand#execute()`.
-* `Model#updateFilteredEmployeeList(Predicate)` — Updates the view of the application to show all employees.
-
-The method `DeleteRemarkCommand#execute()` returns a new `CommandResult` object, which stores information about the completion of the command.
-
-The following sequence diagram below shows how the delete remark operation works:
-
-
-
-Given below is an example usage scenario for the command:
-
-**Step 1**: The user launches the application.
-
-**Step 2**: The user executes the `deleteremark id/EMPLOYEE_ID r/REMARK` command in the CLI.
-
-**Step 3**: The given remark will be deleted from the remark list of the employee with the given id.
-
-**Aspect: Model-Employee Interaction:**
-
-* **Alternative 1 (current choice)**: Utilise `model#setEmployee` to add the edited employee into the model, doing the direct editing in `DeleteRemarkCommand#execute()`.
- * Pros: Maintain immutability within Employee and Model classes.
- * Cons: Potentially violates SRP.
-
-* **Alternative 2**: Create methods in model specifically to edit the `remarkList` attribute of the employee.
- * Pros: More OOP, follows SRP by not having `DeleteRemarkCommand#execute()` perform the editing directly.
- * Cons: Longer command execution, requires more parts to work together.
-
-### Add Leave feature
-
-The add leave feature allows HouR to manage employee leaves.
-
-#### Implementation
-
-The add leave command mechanism is facilitated by the `AddLeaveCommandParser` class which extends the `AddressbookParser`.
-
-`AddLeaveCommandParser#parse()` overrides `Parser#parse()` in the Parser interface.
-
-`AddLeaveCommandParser` implements the following operations:
-
-* `AddLeaveCommandParser#parse()` — Parses the input arguments by storing the prefixes of its respective values as an `ArgumentMultimap`, and creates a new `AddLeaveCommand` object with the parsed employee ID, start date and end date.
-
-The `AddLeaveCommand` object then communicates with the `Model` API by calling the following methods:
-
-* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee` object which has been edited by `AddLeaveCommand#execute()`.
-* `Model#updateFilteredEmployeeList(Predicate)` — Updates the view of the application to show all employees.
-
-The method `AddLeaveCommand#execute()` returns a `CommandResult` object, which stores information about the completion of the command.
-
-The diagram below details how the operation of adding leave date(s) works.
-
-
-
-Given below is an example usage scenario for the command.
+Given below is an example usage scenario for the command.
**Step 1**: The user launches the application.
@@ -677,7 +432,6 @@ Given below is an example usage scenario for the command.
* Pros: More OOP, follows the Single Responsibility Principle by not having `AddLeaveCommand#execute()` perform the editing directly.
* Cons: Longer command execution, requires more parts to work together.
-
### Delete Leave feature
The delete leave feature allows HouR to delete employee leaves.
@@ -731,7 +485,6 @@ The following activity diagram summarizes what happens when a user executes the
* Pros: More OOP, follows the Single Responsibility Principle by not having `DeleteLeaveCommand#execute()` perform the editing directly.
* Cons: Longer command execution, requires more parts to work together, which can cause more bugs.
-
### Edit Leave feature
The edit leave feature allows HouR to edit employee leaves.
@@ -780,7 +533,6 @@ The following activity diagram summarizes what happens when a user executes the
* Pros: More OOP, follows SRP by not having `DeleteRemarkCommand#execute()` perform the editing directly.
* Cons: Longer command execution, requires more parts to work together.
-
### List Leave feature
The list leave feature allows HouR user to view employees on leave on the specified date.
@@ -815,9 +567,321 @@ Given below is an example usage scenario for the command.
**Step 3**: Employees will be filtered based on whether they are on leave on the specified date.
* The Employee List will be updated to contain only employees which have leaves taken on the specified date.
+### Add Remark feature
+
+The add remark feature allows HouR to add employee remarks.
+
+#### Implementation
+
+The add remark command mechanism is facilitated by `AddRemarkCommandParser` class which implements the `Parser` interface.
+
+`AddRemarkCommandParser#parse()` is exposed in the `Parser` interface as `Parse#parse()`.
+
+`AddRemarkCommandParser` implements the following operations:
+* `AddRemarkCommandParser#parse()` — Parses the input arguments by storing the index and the prefix of its respective values as an `ArgumentMultimap`,
+ and creates a new `AddRemarkCommand` object with the parsed ID and remark.
+
+The `AddRemarkCommand` object then communicates with the `Model` API by calling the following methods:
+* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee` object which has been edited by `AddRemarkCommand#execute()`.
+* `Model#updateFilteredEmployeeList(Predicate)` — Updates the view of the application to show all employees.
+
+The method `AddRemarkCommand#execute()` returns a new `CommandResult` object, which stores information about the completion of the command.
+
+The following sequence diagram below shows how the add remark operation works:
+
+
+
+Given below is an example usage scenario for the command:
+
+**Step 1**: The user launches the application.
+
+**Step 2**: The user executes the `addremark id/EMPLOYEE_ID r/REMARK` command in the CLI.
+
+**Step 3**: The given remark will be added to the remark list of the employee with the given ID.
+
+**Aspect: Model-Employee Interaction:**
+
+* **Alternative 1 (current choice)**: Utilise `model#setEmployee` to add the edited employee into the model, doing the direct editing in `AddRemarkCommand#execute()`.
+ * Pros: Maintain immutability within Employee and Model classes.
+ * Cons: Potentially violates SRP.
+
+* **Alternative 2**: Create methods in model specifically to edit the `remarkList` attribute of the employee.
+ * Pros: More OOP, follows SRP by not having `AddRemarkCommand#execute()` perform the editing directly.
+ * Cons: Longer command execution, requires more parts to work together.
+
+### Delete Remark feature
+
+The delete remark feature allows HouR to delete employee remarks.
+
+#### Implementation
+
+The delete remark command mechanism is facilitated by `DeleteRemarkCommandParser` class which implements the `Parser` interface.
+
+`DeleteRemarkCommandParser#parse()` is exposed in the `Parser` interface as `Parse#parse()`.
+
+`DeleteRemarkCommandParser` implements the following operations:
+* `DeleteRemarkCommandParser#parse()` — Parses the input arguments by storing the index and the prefix of its respective values as an `ArgumentMultimap`,
+ and creates a new `DeleteRemarkCommand` object with the parsed ID and remark.
+
+The `DeleteRemarkCommand` object then communicates with the `Model` API by calling the following methods:
+* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee` object which has been edited by `DeleteRemarkCommand#execute()`.
+* `Model#updateFilteredEmployeeList(Predicate)` — Updates the view of the application to show all employees.
+
+The method `DeleteRemarkCommand#execute()` returns a new `CommandResult` object, which stores information about the completion of the command.
+
+The following sequence diagram below shows how the delete remark operation works:
+
+
+
+Given below is an example usage scenario for the command:
+
+**Step 1**: The user launches the application.
+
+**Step 2**: The user executes the `deleteremark id/EMPLOYEE_ID r/REMARK` command in the CLI.
+
+**Step 3**: The given remark will be deleted from the remark list of the employee with the given ID.
+
+**Aspect: Model-Employee Interaction:**
+
+* **Alternative 1 (current choice)**: Utilise `model#setEmployee` to add the edited employee into the model, doing the direct editing in `DeleteRemarkCommand#execute()`.
+ * Pros: Maintain immutability within Employee and Model classes.
+ * Cons: Potentially violates SRP.
+
+* **Alternative 2**: Create methods in model specifically to edit the `remarkList` attribute of the employee.
+ * Pros: More OOP, follows SRP by not having `DeleteRemarkCommand#execute()` perform the editing directly.
+ * Cons: Longer command execution, requires more parts to work together.
+
+### Overtime feature
+
+The overtime feature allows HouR users to manage employee overtime hours.
+
+#### Implementation
+
+The overtime command mechanism is facilitated by `OvertimeCommandParser` class which implements the `Parser` interface.
+
+`OvertimeCommandParser#parse()` is exposed in the `Parser` interface as `Parse#parse()`.
+
+`OvertimeCommandParser` implements the following operations:
+
+* `OvertimeCommandParser#parse()` — Parses the input arguments by storing the index and the prefix of its
+respective values as an `ArgumentMultimap`, and creates a new `OvertimeCommand` object with the parsed id and overtime
+hours.
+
+The `OvertimeCommand` object then communicates with the `Model` API by calling the following methods:
+
+* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee`
+object which has been edited by `OvertimeCommand#execute()`.
+
+The method `OvertimeCommand#execute()` returns a new `CommandResult` object, which stores information about the
+completion of the command.
+
+The following sequence diagram below shows how the overtime operation works:
+
+
+
+Given below is an example usage scenario for the command:
+
+**Step 1**: The user launches the application.
+
+**Step 2**: The user executes the `overtime id/EMPLOYEE_ID o/OPERATION a/AMOUNT` command in the CLI.
+* `OPERATION` is either `inc` or `dec`.
+*
+**Step 3**: The given overtime hours will be added to the employee with the provided ID.
+
+**Aspect: Model-Employee Interaction:**
+
+* **Alternative 1 (current choice)**: Utilise `model#setEmployee` to add the edited employee into the model, doing the
+direct editing in `OvertimeCommand#execute()`.
+ * Pros: More code reuse. Maintain immutability within Employee and Model classes.
+ * Cons: Potentially violates SRP.
+
+* **Alternative 2**: Create methods in model specifically to edit the `overtimeHours` attribute of the employee.
+ * Pros: More OOP, follows SRP by not having `OvertimeCommand#execute()` perform the editing directly.
+ * Cons: More code duplication. Longer command execution, requires more parts to work together.
+
+The following activity diagram summarizes what happens when a user executes the overtime command:
+
+
+
+### Report feature
+
+#### Implementation
+
+The proposed reporting mechanism is facilitated by `ReportCommandParser`. It implements the following operations:
+
+* `ReportCommandParser#parse()` — Parses the input employee ID and creates a new `ReportCommand` object with the parsed employee ID.
+
+The `ReportCommand` object then communicates with the `Model` and `ReportStorage` APIs by calling the following methods:
+
+* `Model#getFilteredEmployeeList()` — Gets the existing employee list, which is then looped through to get the employee with the given employee ID.
+
+* `ReportStorage#saveReport(Report)` — Saves the report generated in `ReportCommand#execute()` by `ReportCommand#generateReport(employee)`, which is then stored on the hard disk as a `.txt` file.
+
+The method `ReportCommand#execute()` returns a `CommandResult` object, which stores information about the completion of the command.
+
+The following sequence diagram below shows how the report operation works:
+
+
+
+Given below is an example usage scenario for the command:
+
+**Step 1**: The user launches the application.
+
+**Step 2**: The user executes the `report EMPLOYEE_ID` command in the CLI.
+
+**Step 3**: A report will be generated for the employee with the given ID.
+
+The following activity diagram summarises what happens when a user executes the report command:
+
+
+
+#### Design considerations:
+
+**Aspect: Command-Model Interaction**
+
+* **Alternative 1 (current choice):** Utilise `Model#getFilteredEmployeeList()` to get the existing employee list, which is then looped through to get the employee with the given employee ID.
+ * Pros: Maintain immutability within Employee and Model classes.
+ * Cons: Longer command execution, requiring more parts to work together.
+
+* **Alternative 2:** Create methods in `Model` class specifically to get the employee with the given employee ID.
+ * Pros: Shorter command execution.
+ * Cons: May reduce immutability between Employee and Model classes.
+
+**Aspect: Command-Storage Interaction**
+
+* **Alternative 1 (current choice):** Utilise a dedicated storage class `ReportStorage` with the method `ReportStorage#saveReport(Report)` to save the report.
+ * Pros: Maintain SRP and SLAP within the command class.
+ * Cons: Longer command execution, requiring more parts to work together.
+
+* **Alternative 2:** Create methods in `ReportCommand` class to write and save the report.
+ * Pros: Shorter command execution, one less point of failure by eliminating the `ReportStorage` class.
+ * Cons: Less OOP, may violate SLAP within the command class.
+
+### Reset feature
+
+The reset feature allows HouR to reset employee overtime hours and leaves.
+
+#### Implementation
+
+The reset command mechanism is facilitated by `ResetCommandParser` class which implements the `Parser` interface.
+
+`ResetCommandParser#parse()` is exposed in the `Parser` interface as `Parse#parse()`.
+
+`ResetCommandParser` implements the following operations:
+* `ResetCommandParser#parse()` — Parses the input arguments by storing the index and the prefix of its respective values as an `ArgumentMultimap`,
+and creates a new `ResetCommand` object with the parsed field.
+
+The `ResetCommand` object then communicates with the `Model` API by calling the following methods:
+* `Model#setEmployee(Employee, Employee)` — Sets the employee in the existing employee list to the new `Employee` object which has been edited by `ResetCommand#execute()`.
+* `Model#updateFilteredEmployeeList(Predicate)` — Updates the view of the application to show all employees.
+
+The method `ResetCommand#execute()` returns a new `CommandResult` object, which stores information about the completion of the command.
+
+The following sequence diagram below shows how the reset operation works:
+
+
+
+Given below is an example usage scenario for the command:
+
+**Step 1**: The user launches the application.
+
+**Step 2**: The user executes the `reset f/FIELD` command in the CLI (note that only `overtime` and `leaves` are valid).
+
+**Step 3**: The given field of all employees in the employee book will be reset to their default value.
+
+The following activity diagram summarizes what happens when a user executes the reset command:
+
+
+
+#### Design considerations:
+
+**Aspect: Model-Employee Interaction:**
+
+* **Alternative 1 (current choice):** Utilise `Model#setEmployee` to add the edited employee into the model, doing the direct editing in `ResetCommand#execute()`.
+ * Pros: Maintain immutability within Employee and Model classes.
+ * Cons: Potentially violates SRP.
+
+* **Alternative 2:** Create methods in `Model` class specifically to edit the fields of the employees.
+ * Pros: More OOP, follows SRP by not having `ResetCommand#execute()` perform the editing directly.
+ * Cons: Longer command execution, requiring more parts to work together.
+
+### \[Proposed\] Undo/redo feature
+
+#### Proposed Implementation
+
+The proposed undo/redo mechanism is facilitated by `VersionedAddressBook`. It extends `AddressBook` with an undo/redo history, stored internally as an `addressBookStateList` and `currentStatePointer`. Additionally, it implements the following operations:
+
+* `VersionedAddressBook#commit()` — Saves the current address book state in its history.
+* `VersionedAddressBook#undo()` — Restores the previous address book state from its history.
+* `VersionedAddressBook#redo()` — Restores a previously undone address book state from its history.
+
+These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and `Model#redoAddressBook()` respectively.
+
+Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
+
+Step 1. The user launches the application for the first time. The `VersionedAddressBook` will be initialized with the initial address book state, and the `currentStatePointer` pointing to that single address book state.
+
+
+
+Step 2. The user executes `delete EID1234-5678` command to delete an employee in the address book. The `delete` command calls `Model#commitAddressBook()`, causing the modified state of the address book after the `delete EID1234-5678` command executes to be saved in the `addressBookStateList`, and the `currentStatePointer` is shifted to the newly inserted address book state.
+
+
+
+Step 3. The user executes `add n/David …` to add a new employee. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
-_{more aspects and alternatives to be added}_
+
+:information_source: **Note:** If a command fails its execution, it will not call `Model#commitAddressBook()`, so the address book state will not be saved into the `addressBookStateList`.
+
+
+
+Step 4. The user now decides that adding the employee was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#undoAddressBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous address book state, and restores the address book to that state.
+
+
+
+:information_source: **Note:** If the `currentStatePointer` is at index 0, pointing to the initial AddressBook state, then there are no previous AddressBook states to restore. The `undo` command uses `Model#canUndoAddressBook()` to check if this is the case. If so, it will return an error to the user rather
+than attempting to perform the undo.
+
+
+
+The following sequence diagram shows how the undo operation works:
+
+
+
+:information_source: **Note:** The lifeline for `UndoCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+
+
+
+The `redo` command does the opposite — it calls `Model#redoAddressBook()`, which shifts the `currentStatePointer` once to the right, pointing to the previously undone state, and restores the address book to that state.
+
+:information_source: **Note:** If the `currentStatePointer` is at index `addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone AddressBook states to restore. The `redo` command uses `Model#canRedoAddressBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.
+
+
+
+Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such as `list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
+
+
+
+Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not pointing at the end of the `addressBookStateList`, all address book states after the `currentStatePointer` will be purged. Reason: It no longer makes sense to redo the `add n/David …` command. This is the behavior that most modern desktop applications follow.
+
+
+
+The following activity diagram summarizes what happens when a user executes a new command:
+
+
+
+#### Design considerations:
+
+**Aspect: How undo & redo executes:**
+
+* **Alternative 1 (current choice):** Saves the entire address book.
+ * Pros: Easy to implement.
+ * Cons: May have performance issues in terms of memory usage.
+
+* **Alternative 2:** Individual command knows how to undo/redo by
+ itself.
+ * Pros: Will use less memory (e.g. for `delete`, just save the employee being deleted).
+ * Cons: We must ensure that the implementation of each individual command are correct.
--------------------------------------------------------------------------------------------------------------------
## **Documentation, logging, testing, configuration, dev-ops**
@@ -828,6 +892,8 @@ _{more aspects and alternatives to be added}_
* [Configuration guide](Configuration.md)
* [DevOps guide](DevOps.md)
+
+
--------------------------------------------------------------------------------------------------------------------
## **Appendix: Requirements**
@@ -882,127 +948,351 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
| `*` | long-time user | archive unused data | not distracted by irrelevant data |
-### Use cases
+### Use cases
+
+(For all use cases below, the **System** is the `HouR` and the **Actor** is the `user`, unless specified otherwise)
+
+**Use case: Add an employee**
+
+**MSS**
+
+1. User requests to add a specific employee
+2. HouR adds the employee to the list of employees
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. The employee to be added already exists in the list.
+ * 1a1. HouR shows an error message.
+
+ Use case ends.
+
+
+**Use case: Delete an employee**
+
+**MSS**
+
+1. User requests to list employees
+2. HouR shows a list of employees
+3. User requests to delete a specific employee in the list
+4. HouR deletes the employee
+
+ Use case ends.
+
+**Extensions**
+
+* 2a. The list is empty.
+
+ Use case ends.
+
+* 3a. The given employee ID is invalid.
+
+ * 3a1. HouR shows an error message.
+
+ Use case resumes at step 2.
+
+**Use case: Edit an employee**
+
+**MSS**
+
+1. User requests to list employees
+2. HouR shows a list of employees
+3. User requests to edit a specific employee in the list
+4. HouR edits the employee
+
+ Use case ends.
+
+**Extensions**
+
+* 2a. The list is empty.
+
+ Use case ends.
+
+* 3a. The given index is invalid.
+
+ * 3a1. HouR shows an error message.
+
+ Use case resumes at step 2.
+
+* 3b. Missing field to edit.
+
+ * 3a1. HouR shows an error message.
+
+ Use case resumes at step 2.
+
+**Use case: List employees**
+
+**MSS**
+
+1. User requests to list employees
+2. HouR display a list of every employee that has been added
+
+ Use case ends.
+
+**Use case: Find employees**
+
+**MSS**
+
+1. User requests to find employees with keyword
+2. HouR returns list of employees with keyword
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. User leaves out keyword.
+ * 1a1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1b. No employee matches given keyword.
+ * 1b1. HouR shows an empty list.
+
+ Use case ends.
+
+**Use case: Sort employees**
+
+**MSS**
+
+1. User requests to sort employees by given field and order.
+2. HouR returns the sorted list of employees based on given field in given order.
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. User leaves out at least one of field or order.
+ * 1a1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1b. Field is not usable for sorting.
+ * 1b1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1c. Order is not asc or desc.
+ * 1c1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+**Use case: Add a leave period for an employee**
+
+**MSS**
+
+1. User requests to add a leave period for an employee with a given ID from given start date
+ to given end date.
+2. HouR adds the individual dates between the given start and end dates inclusive
+ as leave dates for the employee with given ID.
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. User leaves out at least one of employee ID, start date, or end date.
+ * 1a1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1b. No employee matches given ID.
+ * 1b1. HouR shows an error message.
+
+ Use case returns back to step 1.
-(For all use cases below, the **System** is the `HouR` and the **Actor** is the `user`, unless specified otherwise)
+* 1c. Dates are of invalid order or format.
+ * 1c1. HouR shows an error message.
-**Use case: Add an employee**
+ Use case returns back to step 1.
+
+* 1d. Leave date to be added already exists.
+ * 1d1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1e. Adding the leave date causes number of leaves
+ for employee with given employee ID to be over 14 days .
+ * 1e1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+**Use case: Delete a leave period for an employee**
**MSS**
-1. User requests to add a specific employee
-2. HouR adds the employee to the list of employees
+1. User requests to delete allocated leaves for an employee with a given ID that falls between
+ given start and end dates.
+2. HouR deletes the allocated leave dates that fall between the given start and end dates inclusive
+ for the employee with given ID.
Use case ends.
**Extensions**
-* 1a. The employee to be added already exists in the list.
- * 1a1. HouR shows an error message.
+* 1a. User leaves out at least one of employee ID, start date, or end date.
+ * 1a1. HouR shows an error message.
- Use case ends.
+ Use case returns back to step 1.
+* 1b. No employee matches given ID.
+ * 1b1. HouR shows an error message.
-**Use case: Delete an employee**
+ Use case returns back to step 1.
+
+* 1c. Dates are of invalid order or format.
+ * 1c1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1d. No allocated leaves found between given start and end dates.
+ * 1d1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+**Use case: Edit an allocated leave date for an employee**
**MSS**
-1. User requests to list employees
-2. HouR shows a list of employees
-3. User requests to delete a specific employee in the list
-4. HouR deletes the employee
+1. User requests to edit a given allocated leave date for an employee with a given ID to the given new leave date.
+2. HouR edits the given allocated leave date to the given new leave date for the employee with given ID.
Use case ends.
**Extensions**
-* 2a. The list is empty.
+* 1a. User leaves out at least one of employee ID, old leave date, or new leave date.
+ * 1a1. HouR shows an error message.
- Use case ends.
+ Use case returns back to step 1.
-* 3a. The given employee id is invalid.
+* 1b. No employee matches given ID.
+ * 1b1. HouR shows an error message.
- * 3a1. HouR shows an error message.
+ Use case returns back to step 1.
- Use case resumes at step 2.
+* 1c. Dates are of invalid format.
+ * 1c1. HouR shows an error message.
-**Use case: Edit an employee**
+ Use case returns back to step 1.
+
+* 1d. Given allocated date to be edited does not exist.
+ * 1d1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1e. Given new date is already allocated.
+ * 1e1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+**Use case: List employees on leave**
**MSS**
-1. User requests to list employees
-2. HouR shows a list of employees
-3. User requests to edit a specific employee in the list
-4. HouR edits the employee
+1. User requests to view a list of all employees on leave on a given date.
+2. HouR filters the displayed employee list to only display employees on leave on the given date.
Use case ends.
**Extensions**
-* 2a. The list is empty.
+* 1a. User leaves out date.
+ * 1a1. HouR shows an error message.
- Use case ends.
+ Use case returns back to step 1.
-* 3a. The given index is invalid.
+* 1b. Dates are in the wrong format.
+ * 1b1. HouR shows an error message.
- * 3a1. HouR shows an error message.
+ Use case returns back to step 1.
- Use case resumes at step 2.
+**Use case: Add a remark for an employee**
-* 3b. Missing field to edit.
+**MSS**
- * 3a1. HouR shows an error message.
+1. User requests to add a given remark to an employee with a given employee ID.
+2. HouR adds the remark to the list of remarks associated with the employee with the given employee ID and
+ shows the list to the user.
- Use case resumes at step 2.
+ Use case ends.
-**Use case: List employees**
+**Extensions**
-**MSS**
+* 1a. User leaves out at least one of employee ID or remark.
+ * 1a1. HouR shows an error message.
-1. User requests to list employees
-2. HouR display a list of every employee that has been added
+ Use case returns back to step 1.
- Use case ends.
+* 1b. No employee matches given employee ID.
+ * 1b1. HouR shows an error message.
-**Use case: Find employees**
+ Use case returns back to step 1.
+
+* 1c. Remark to be added already exists.
+ * 1c1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+**Use case: Delete a remark for an employee**
**MSS**
-1. User requests to find employees with keyword
-2. HouR returns list of employees with keyword
+1. User requests to delete a given remark from an employee with a given employee ID.
+2. HouR deletes the remark from the list of remarks associated with the employee with the given employee ID
+ and shows it to the user.
Use case ends.
**Extensions**
-* 1a. User leaves out keyword.
- * 1a1. HouR shows an error message.
+* 1a. User leaves out at least one of employee ID or remark.
+ * 1a1. HouR shows an error message.
Use case returns back to step 1.
-* 1b. No employee matches given keyword.
- * 1b1. HouR shows an empty list.
+* 1b. No employee matches given employee ID.
+ * 1b1. HouR shows an error message.
- Use case ends.
+ Use case returns back to step 1.
-**Use case: Sort employees**
+* 1c. Remark does not exist in the list of remarks associated with employee with given employee ID.
+ * 1c1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+**Use case: Increase or decrease employee overtime hours**
**MSS**
-1. User requests to sort employees by given attribute
-2. HouR returns the sorted list of employees by given attribute
+1. User requests to increase number of overtime hours taken by employee with given employee ID by a given amount.
+2. HouR increases the number of overtime hours taken by employee with given employee ID by the given amount.
Use case ends.
**Extensions**
-* 1a. User leaves out keyword.
- * 1a1. HouR shows an error message.
+* 1a. User leaves out at least one of employee ID, operation (inc or dec), and amount.
+ * 1a1. HouR shows an error message.
Use case returns back to step 1.
-* 1b. No attribute matches given attribute.
- * 1b1. HouR shows an error message.
+* 1b. No employee matches given employee ID.
+ * 1b1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1c. Operation given is neither inc (for increase) nor dec (for decrease).
+ * 1c1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1d. Amount given is not a positive integer.
+ * 1d1. HouR shows an error message.
+
+ Use case returns back to step 1.
+
+* 1e. Updating the number of leaves causes the number to exceed 72 or fall below 0.
+ * 1e1. HouR shows an error message.
Use case returns back to step 1.
@@ -1027,15 +1317,6 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
Use case returns back to step 1.
-**Use case: Clear employee book**
-
-**MSS**
-
-1. User requests to clear employee book
-2. HouR clears employee book
-
- Use case ends.
-
**Use case: Reset field of all employees**
**MSS**
@@ -1057,6 +1338,24 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
Use case returns back to step 1.
+**Use case: Clear employee book**
+
+**MSS**
+
+1. User requests to clear employee book
+2. HouR clears employee book
+
+ Use case ends.
+
+**Use case: Open help page**
+
+**MSS**
+
+1. User requests to open help page
+2. HouR shows a link that the user can copy and paste on a browser
+
+ Use case ends.
+
**Use case: Exit HouR**
**MSS**
@@ -1066,7 +1365,6 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
Use case ends.
-*{More to be added}*
### Non-Functional Requirements
@@ -1086,8 +1384,14 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
* **Mainstream OS**: Windows, Linux, Unix, OS-X
* **Employee**: A worker in the company
-
-*{More to be added}*
+* **Employee book**: The database of employees
+* **CLI**: Command Line Interface
+* **GUI**: Graphical User Interface
+* **MSS**: Main Success Scenario
+* **PDPA**: Personal Data Protection Act
+* **SRP**: Single Responsibility Principle
+* **API**: Application Programming Interface
+* **JSON**: JavaScript Object Notation
--------------------------------------------------------------------------------------------------------------------
@@ -1106,21 +1410,22 @@ testers are expected to do more *exploratory* testing.
1. Download the jar file and copy into an empty folder
- 1. Double-click the jar file.Expected: Shows the GUI with a set of sample employees. The window size may not be optimum. + 2. Double-click the jar file.
+ Expected: Shows the GUI with a set of sample employees. The window size may not be optimum. -1. Saving window preferences +2. Saving window preferences 1. Resize the window to an optimum size. Move the window to a different location. Close the window. - 1. Re-launch the app by double-clicking the jar file.
+ 2. Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained. -1. Shutdown using the UI +3. Shutdown using the UI 1. Click the `X` button in the top right corner of the window.
Expected: The window closes. -1. Shutdown using the `exit` command +4. Shutdown using the `exit` command 1. Type `exit` in the command box and press Enter.
Expected: The window closes. @@ -1131,91 +1436,46 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all employees using the `list` command. Multiple employees in the list. - 1. Test case: `delete EID1234-5678`
+ 2. Test case: `delete EID1234-5678`
Expected: Employee with employee ID "EID1234-5678" is deleted from the list. Details of the deleted employee shown in the status message. Timestamp in the status bar is updated. - 1. Test case: `delete 0`
+ 3. Test case: `delete 0`
Expected: No employee is deleted. Error details shown in the status message. Status bar remains the same. - 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is an invalid employee ID)
- Expected: Similar to previous. - ### Finding an employee 1. Finding an employee while all employees are being shown 1. Prerequisites: List all employees using the `list` command. Multiple employees in the list. Employee with name "Alex" is in the list. Employee with position "manager" is in the list. Employee with employee ID "EID1234-5678" is in the list. Employee with employee ID "EID0000-0000" is not in the list. Employee with position "notAManager" is not in the list. - 1. Test case: `find Alex`
+ 2. Test case: `find Alex`
Expected: Employee with name "Alex" is shown in the list. The status bar shows the number of employees shown in the list. - 1. Test case: `find abcdef`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find manager`
+ 3. Test case: `find manager`
Expected: All employees with the word "manager" in their position are shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find notAManager`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find EID1234-5678`
+ + 4. Test case: `find EID1234-5678`
Expected: Employee with employee ID "EID1234-5678" is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find EID0000-0000`
+ + 5. Test case: `find EID0000-0000`
Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - 1. Test case: `find`
+ 6. Test case: `find`
Expected: Invalid command format error message is shown in the status bar. -1. Finding an employee when only some employees are being shown. +2. Finding an employee when only some employees are being shown. 1. Prerequisites: List only some employees using the `find manager` command. Multiple employees in the list. Employee with name "Alex" is in the list. Three employees with position "manager" are in the list. Employee with employee ID "EID1234-5678" is in the list. Employee with employee ID "EID0000-0000" is not in the list. Employee with position "notAManager" is not in the list. - 1. Test case: `find Alex`
- Expected: Employee with name "Alex" is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find abcdef`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find manager`
- Expected: All employees with the word "manager" in their position are shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find notAManager`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find EID1234-5678`
- Expected: Employee with employee ID "EID1234-5678" is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find EID0000-0000`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find`
- Expected: Invalid command format error message is shown in the status bar. + 2. Try the test cases in the previous section (Finding an employee while all employees are being shown)
+ Expected: Same as the previous section. -1. Finding an employee in an empty employee book +3. Finding an employee in an empty employee book 1. Prerequisites: Clear the employee book using the `clear` command. - 1. Test case: `find Alex`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find abcdef`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find manager`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find notAManager`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find EID1234-5678`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find EID0000-0000`
- Expected: No employee is shown in the list. The status bar shows the number of employees shown in the list. - - 1. Test case: `find`
- Expected: Invalid command format error message is shown in the status bar. + 2. Enter any valid `find` command similar to previous sections.
+ Expected: No employee is found in the list. ### Generating a report for an employee @@ -1223,40 +1483,28 @@ testers are expected to do more *exploratory* testing. 1. Prerequisites: List all employees using the `list` command. Multiple employees in the list. Employee with employee ID "EID1234-5678" is in the list. Employee with employee ID "EID0000-0000" is not in the list. - 1. Test case: `report EID1234-5678`
+ 2. Test case: `report EID1234-5678`
Expected: The report of employee with employee ID "EID1234-5678" is shown in the status bar. The report is also downloaded as a text file in a directory called "reports" in the same directory as the jar file. - 1. Test case: `report EID0000-0000`
+ 3. Test case: `report EID0000-0000`
Expected: No report is shown in the status bar. Error details about the invalid employee ID shown in the status bar. No report is downloaded. - - 1. Test case: `report`
+ + 4. Test case: `report`
Expected: Invalid command format error message is shown in the status bar. -1. Generating report while only some employees are being shown. +2. Generating report while only some employees are being shown. 1. Prerequisites: List only some employees using the `find manager` command. Multiple employees in the list. Employee with employee ID "EID1234-5678" is in the list. Employee with employee ID "EID0000-0000" is not in the list. - 1. Test case: `report EID1234-5678`
- Expected: The report of employee with employee ID "EID1234-5678" is shown in the status bar. The report is also downloaded as a text file in a directory called "reports" in the same directory as the jar file. - - 1. Test case: `report EID0000-0000`
- Expected: No report is shown in the status bar. Error details about the invalid employee ID shown in the status bar. No report is downloaded. - - 1. Test case: `report`
- Expected: Invalid command format error message is shown in the status bar. + 2. Try the test cases in the previous section (Generating report while all employees are being shown) + Expected: Same as the previous section. -1. Generating report with an empty employee book +3. Generating report with an empty employee book 1. Prerequisites: Clear the employee book using the `clear` command. - 1. Test case: `report EID1234-5678`
- Expected: No report is shown in the status bar. Error details about the invalid employee ID shown in the status bar. No report is downloaded. - - 1. Test case: `report EID0000-0000`
- Expected: No report is shown in the status bar. Error details about the invalid employee ID shown in the status bar. No report is downloaded. - - 1. Test case: `report`
- Expected: Invalid command format error message is shown in the status bar. + 2. Try the test cases in the previous section (Generating report while all employees are being shown) + Expected: Same as the previous section. ### Sorting a list @@ -1275,12 +1523,6 @@ testers are expected to do more *exploratory* testing. 4. Test case: `sort f/name in/ascending` or `sort f/department in/random`
Expected: List is not sorted (order parameter can only be asc or desc). Error details shown in the status message. - 5. Test case: `sort f/name` or `sort in/desc`
- Expected: List is not sorted (missing parameters). Error details shown in the status message. - - 6. Test case: `sort f/name in/` or `sort f/ in/desc`
- Expected: List is not sorted (empty parameters). Error details shown in the status message. - 2. Sorting the list of employees when only some employees are being shown 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. @@ -1288,6 +1530,7 @@ testers are expected to do more *exploratory* testing. 2. Try the test cases in the previous section (Sorting the list of employees while all employees are being shown) Expected: Same as the previous section +_{other invalid inputs are possible}_ ### Adding Leave for an Employee @@ -1304,28 +1547,23 @@ testers are expected to do more *exploratory* testing. Expected: No employee leave is added (ID does not exist). Error details shown in the result display. 4. Test case: `addleave id/EID12345678 from/2023-12-04 to/2023-12-05` or `addleave id/EID1234-5678 from/2023-30-11 to/2023-30-11`
- Expected: No employee leave is added (incorrect field format). Error details shown in the result display. + Expected: No employee leave is added (incorrect field format). Error details shown in the result display. - 5. Test case: `addleave id/ from/2023-12-04 to/2023-12-05` or `addleave id/EID1234-5678 from/ to/2023-12-05` or `addleave id/EID1234-5678 from/2023-12-04 to/`
- Expected: No employee leave is added (empty fields). Error details shown in the result display. + 5. Test case: `addleave id/EID1234-5678 from/2023-11-11 to/2023-11-13`
+ Expected: No employee leave is added (leave date(s) already exists). Error details shown in the result display. - 6. Test case: `addleave from/2023-12-04 to/2023-12-05` or `addleave id/EID1234-5678 to/2023-12-05` or `addleave id/EID1234-5678 from/2023-12-04`
- Expected: No employee leave is added (missing parameters). Error details shown in the result display. - - 7. Test case: `addleave id/EID1234-5678 from/2023-11-11 to/2023-11-13`
- Expected: No employee leave is added (leave date(s) already exists). Error details shown in the result display. - - 8. Test case: `addleave id/EID1234-5678 from/2023-12-05 to/2023-12-04`
- Expected: No employee leave is added (invalid date order). Error details shown in the result display. + 6. Test case: `addleave id/EID1234-5678 from/2023-12-05 to/2023-12-04`
+ Expected: No employee leave is added (invalid date order). Error details shown in the result display. 2. Adding leave while only some employees are being shown 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. - Employee with id "EID1234-5678" has leaves "2023-11-11" and "2023-11-12" and is not in displayed list. + Employee with ID "EID1234-5678" has leaves "2023-11-11" and "2023-11-12" and is not in displayed list. 2. Try the test cases in the previous section (Adding leave while all employees are being shown) - Expected: Same as the previous section + Expected: Same as the previous section +_{other invalid inputs are possible}_ ### Deleting Leave for an Employee @@ -1344,242 +1582,240 @@ testers are expected to do more *exploratory* testing. 4. Test case: `deleteleave id/EID12345678 from/2023-12-04 to/2023-12-05` or `deleteleave id/EID1234-5678 from/2023-30-11 to/2023-30-11`
Expected: No employee leave is deleted (incorrect field format). Error details shown in the result display. - 5. Test case: `deleteleave id/ from/2023-12-04 to/2023-12-05` or `deleteleave id/EID1234-5678 from/ to/2023-12-05` or `deleteleave id/EID1234-5678 from/2023-12-04 to/`
- Expected: No employee leave is deleted (empty fields). Error details shown in the result display. - - 6. Test case: `deleteleave from/2023-12-04 to/2023-12-05` or `deleteleave id/EID1234-5678 to/2023-12-05` or `deleteleave id/EID1234-5678 from/2023-12-04`
- Expected: No employee leave is deleted (missing parameters). Error details shown in the result display. - - 7. Test case: `deleteleave id/EID1234-5678 from/2023-12-05 to/2023-12-04`
+ 5. Test case: `deleteleave id/EID1234-5678 from/2023-12-05 to/2023-12-04`
Expected: No employee leave is deleted (invalid date order). Error details shown in the result display. - 8. Test case: `deleteleave id/EID1234-5678 from/2023-12-04 to/2023-12-05`
+ 6. Test case: `deleteleave id/EID1234-5678 from/2023-12-04 to/2023-12-05`
Expected: No employee leave is deleted (no leaves exist between "2023-12-04" and "2023-12-05"). Error details shown in the result display. 2. Deleting leave while only some employees are being shown 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. - Employee with id "EID1234-5678" has leaves "2023-12-01", "2023-12-02", and "2023-12-03" and is not in displayed list. + Employee with ID "EID1234-5678" has leaves "2023-12-01", "2023-12-02", and "2023-12-03" and is not in displayed list. 2. Try the test cases in the previous section (Deleting leave while all employees are being shown) Expected: Same as the previous section +_{other invalid inputs are possible}_ ### Editing Leave for an Employee 1. Editing leave while all employees are being shown 1. Prerequisites: List all employees using the `list` command. Multiple employees in the list. - Employee with id "EID1234-5678" has leaves "2023-11-01" and "2023-11-02". + Employee with ID "EID1234-5678" has leaves "2023-11-01" and "2023-11-02". - 1. Test case: `editleave id/EID1234-5678 old/2023-11-01 new/2023-11-03`
- Expected: The previous leave date "2023-11-01" of the employee with id "EID1234-5678" will be changed to "2023-11-03". + 2. Test case: `editleave id/EID1234-5678 old/2023-11-01 new/2023-11-03`
+ Expected: The previous leave date "2023-11-01" of the employee with ID "EID1234-5678" will be changed to "2023-11-03". Details of the edited employee shown in the result display. + + 3. Test case: `editleave id/EID0000-0000 old/2023-11-01 new/2023-11-03`
+ Expected: No employee leave is edited (ID does not exist). Error details shown in the result display. - 1. Test case: `editleave id/EID0000-0000 old/2023-11-01 new/2023-11-03`
- Expected: No employee leave is edited (no existing id). Error details shown in the result display. - - 1. Test case: `editleave id/12345678 old/2023-11-01 new/2023-11-03` or `editleave id/EID1234-5678 old/2023-28-11 new/2023-30-11`
+ 4. Test case: `editleave id/12345678 old/2023-11-01 new/2023-11-03` or `editleave id/EID1234-5678 old/2023-28-11 new/2023-30-11`
Expected: No employee leave is edited (incorrect field format). Error details shown in the result display. - 1. Test case: `editleave id/ old/2023-11-01 new/2023-11-03` or `editleave id/EID1234-5678 old/ new/2023-11-03` or `editleave id/EID1234-5678 old/2023-11-01 new/`
- Expected: No employee leave is edited (empty fields). Error details shown in the result display. - - 1. Test case: `editleave old/2023-11-01 new/2023-11-03` or `editleave id/EID1234-5678 new/2023-11-03` or `editleave id/EID1234-5678 old/2023-11-01`
- Expected: No employee leave is edited (missing parameters). Error details shown in the result display. - - 1. Test case: `editleave id/EID1234-5678 old/2023-11-03 new/2023-11-04`
+ 5. Test case: `editleave id/EID1234-5678 old/2023-11-03 new/2023-11-04`
Expected: No employee leave is edited (old leave doesn't exist). Error details shown in the result display. - 1. Test case: `editleave id/EID1234-5678 old/2023-11-01 new/2023-11-02`
+ 6. Test case: `editleave id/EID1234-5678 old/2023-11-01 new/2023-11-02`
Expected: No employee leave is edited (new leave already exists). Error details shown in the result display. -1. Editing leave while only some employees are being shown +2. Editing leave while only some employees are being shown 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. - Employee with id "EID1234-5678" has leaves "2023-11-01" and "2023-11-02" and is not in displayed list. + Employee with ID "EID1234-5678" has leaves "2023-11-01" and "2023-11-02" and is not in displayed list. - 1. Try the test cases in the previous section (Editing leave while all employees are being shown) + 2. Try the test cases in the previous section (Editing leave while all employees are being shown) Expected: Same as the previous section +_{other invalid inputs are possible}_ + ### Listing Employees on Leave on a specified date -1. Listing employees on leave while all employees are being shown +1. Listing employees on leave while all employees are being shown + 1. Prerequisites: List all employees using the `list` command. At least one employee in the list. - Employee with id "EID1234-5678" has leaves "2023-11-01" and "2023-11-02". No employees on leave on "2023-11-11". + Employee with ID "EID1234-5678" has leaves "2023-11-01" and "2023-11-02". No employees on leave on "2023-11-11". 2. Test case: `listleave on/2023-11-01`
- Expected: The employees on leave on the specified date are displayed in the employee list. - Details of the number of employees on leave on the specified date shown in the result display. + Expected: The employees on leave on the specified date are displayed in the employee list. + Details of the number of employees on leave on the specified date shown in the result display. 3. Test case: `listleave on/2023-11-11`
- Expected: No employee displayed (no employees on leave on specified date). - Details of the number of employees on leave on the specified date shown in the result display. + Expected: No employee displayed (no employees on leave on specified date). + Details of the number of employees on leave on the specified date shown in the result display. 4. Test case: `listleave on/11-11-2023`
- Expected: No employee displayed (incorrect field format). Error details shown in the result display. - - 5. Test case: `listleave on/ `
- Expected: No employee displayed (empty field). Error details shown in the result display. - - 6. Test case: `listleave `
- Expected: No employee displayed (missing parameters). Error details shown in the result display. + Expected: No employee displayed (incorrect field format). Error details shown in the result display. 2. Listing employees on leave while only some employees are being shown 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. - Employee with id "EID1234-5678" has leaves "2023-11-01" and "2023-11-02" and is not in displayed list. + Employee with ID "EID1234-5678" has leaves "2023-11-01" and "2023-11-02" and is not in displayed list. 2. Try the test cases in the previous section (Listing employees on leave while all employees are being shown) Expected: Same as the previous section +_{other invalid inputs are possible}_ + ### Adding Remark for an Employee 1. Adding remark while all employees are being shown 1. Prerequisites: List all employees using the `list` command. Multiple employees in the list. - Employee with id "EID1234-5678" has remarks "team player" and "slow on deadlines". + Employee with ID "EID1234-5678" has remarks "team player" and "slow on deadlines". - 1. Test case: `addremark id/EID1234-5678 r/good leader` or `addremark id/EID1234-5678 r/GOOD LEADER`
+ 2. Test case: `addremark id/EID1234-5678 r/good leader` or `addremark id/EID1234-5678 r/GOOD LEADER`
Expected: The remark "good leader" or "GOOD LEADER" will be added to the remark list of the employee with id "EID1234-5678". Details of the edited employee shown in the result display. - 1. Test case: `addremark id/EID0000-0000 r/good leader`
- Expected: No remark is added (no existing id). Error details shown in the result display. - - 1. Test case: `addremark id/12345678 r/good leader`
- Expected: No remark is added (incorrect id format). Error details shown in the result display. - - 1. Test case: `addremark id/ r/good leader` or `addremark id/EID1234-5678 r/`
- Expected: No remark is added (empty fields). Error details shown in the result display. - - 1. Test case: `addremark r/good leader` or `addremark id/EID1234-5678`
- Expected: No remark is added (missing parameters). Error details shown in the result display. + 3. Test case: `addremark id/EID0000-0000 r/good leader`
+ Expected: No remark is added (no existing ID). Error details shown in the result display. - 1. Test case: `addremark id/EID1234-5678 r/team player` or `addremark id/EID1234-5678 r/TEAM PLAYER`
+ 4. Test case: `addremark id/EID1234-5678 r/team player` or `addremark id/EID1234-5678 r/TEAM PLAYER`
Expected: No remark is added (remark already exists). Error details shown in the result display. -1. Adding remark while only some employees are being shown +2. Adding remark while only some employees are being shown 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. - Employee with id "EID1234-5678" has remarks "team player" and "slow on deadlines", and is not in displayed list. + Employee with ID "EID1234-5678" has remarks "team player" and "slow on deadlines", and is not in displayed list. - 1. Try the test cases in the previous section (Adding remark while all employees are being shown) + 2. Try the test cases in the previous section (Adding remark while all employees are being shown) Expected: Same as the previous section +_{other invalid inputs are possible}_ + ### Deleting Remark for an Employee 1. Deleting remark while all employees are being shown 1. Prerequisites: List all employees using the `list` command. Multiple employees in the list. - Employee with id "EID1234-5678" has remarks "team player" and "slow on deadlines". + Employee with ID "EID1234-5678" has remarks "team player" and "slow on deadlines". - 1. Test case: `deleteremark id/EID1234-5678 r/slow on deadlines` or `addremark id/EID1234-5678 r/SLOW ON DEADLINES`
- Expected: The remark "slow on deadlines" will be deleted from the remark list of the employee with id "EID1234-5678". + 2. Test case: `deleteremark id/EID1234-5678 r/slow on deadlines` or `addremark id/EID1234-5678 r/SLOW ON DEADLINES`
+ Expected: The remark "slow on deadlines" will be deleted from the remark list of the employee with ID "EID1234-5678". Details of the edited employee shown in the result display. - 1. Test case: `deleteremark id/EID0000-0000 r/slow on deadlines`
- Expected: No remark is deleted (no existing id). Error details shown in the result display. - - 1. Test case: `deleteremark id/12345678 r/slow on deadlines`
- Expected: No remark is deleted (incorrect id format). Error details shown in the result display. - - 1. Test case: `deleteremark id/ r/slow on deadlines` or `deleteremark id/EID1234-5678 r/`
- Expected: No remark is deleted (empty fields). Error details shown in the result display. - - 1. Test case: `deleteremark r/slow on deadlines` or `deleteremark id/EID1234-5678`
- Expected: No remark is deleted (missing parameters). Error details shown in the result display. + 3. Test case: `deleteremark id/EID0000-0000 r/slow on deadlines`
+ Expected: No remark is deleted (no existing ID). Error details shown in the result display. - 1. Test case: `deleteremark id/EID1234-5678 r/bad worker` or `deleteremark id/EID1234-5678 r/BAD WORKER`
+ 4. Test case: `deleteremark id/EID1234-5678 r/bad worker` or `deleteremark id/EID1234-5678 r/BAD WORKER`
Expected: No remark is deleted (remark doesn't exist). Error details shown in the result display. -1. Deleting remark while only some employees are being shown +2. Deleting remark while only some employees are being shown 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. - Employee with id "EID1234-5678" has remarks "team player" and "slow on deadlines", and is not in displayed list. + Employee with ID "EID1234-5678" has remarks "team player" and "slow on deadlines", and is not in displayed list. - 1. Try the test cases in the previous section (Deleting remark while all employees are being shown) + 2. Try the test cases in the previous section (Deleting remark while all employees are being shown) Expected: Same as the previous section +_{other invalid inputs are possible}_ + ### Resetting Fields for all Employees 1. Resetting fields while all employees are being shown 1. Prerequisites: List all employees using the `list` command. Multiple employees in the list. - 1. Test case: `reset f/overtime` or `reset f/OVERTIME` or `reset f/leaves` or `reset f/LEAVES`
+ 2. Test case: `reset f/overtime` or `reset f/OVERTIME` or `reset f/leaves` or `reset f/LEAVES`
Expected: The overtime hour or leaveList of all employees will be reset to their default values 0 or empty list. - 1. Test case: `reset f/name` or `reset f/salary` or `reset f/blah`
+ 3. Test case: `reset f/name` or `reset f/salary` or `reset f/blah`
Expected: Resetting is not done (not able to reset those fields). Error details shown in the result display. - 1. Test case: `reset f/`
- Expected: Resetting is not done (empty field). Error details shown in the result display. - -1. Resetting field while only some employees are being shown +2. Resetting field while only some employees are being shown 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. - 1. Try the test cases in the previous section (Resetting fields while all employees are being shown) + 2. Try the test cases in the previous section (Resetting fields while all employees are being shown) Expected: Same as the previous section -### Saving data +_{other invalid inputs are possible}_ -1. Dealing with missing/corrupted data files +### Updating overtime hours for an employee - 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_ +1. Updating overtime hours while all employees are being shown -1. _{ more test cases … }_ + 1. Prerequisites: List all employees using the `list` command. Multiple employees in the list. + Employee with ID "EID1234-5678" has overtime hours 0. -## **Appendix: Efforts** + 2. Test case: `overtime id/EID1234-5678 o/inc a/20`
+ Expected: The overtime hours of the employee with ID "EID1234-5678" will increase by 20. + Details of the edited employee shown in the result display. -This section documents the efforts that went into the development of this project, as well as the challenges faced. + 3. Test case: `overtime id/EID0000-0000 o/inc a/20`
+ Expected: No overtime hours is updated (no existing ID). Error details shown in the result display. -### Difficulty Level + 4. Test case: `overtime id/ o/inc a/20` or `overtime id/EID1234-5678 o/ a/20` or `overtime id/EID1234-5678 o/inc`
+ Expected: No overtime hours is updated (empty fields). Error details shown in the result display. -We would rate the difficulty level of this project as **π/5**. +2. Updating overtime hours while only some employees are being shown -This is because the project codebase and architecture were initially quite challenging to understand, and we had to spend a significant amount of time tracing through the code and understanding how the different components of the project interacted with each other. However, once we understood the architecture of the project, it was relatively straightforward to add most of the new features and modify existing features. + 1. Prerequisites: Filter some employees using the `find Marketing` command. Some employees in the list. + Employee with ID "EID1234-5678" has overtime hours 10, and is not in displayed list. -There were a few challenging features, such as the `sort` command, which required us to modify the code at multiple layers of abstraction, and the `report` command, which was one of the few commands that required its own storage class and methods. However, we were able to implement these features successfully after some effort. + 2. Try the test cases in the previous section (Updating overtime hours while all employees are being shown) + Expected: Same as the previous section -Writing our own tests as well as modifying existing tests, while not particularly difficult, was quite time-consuming, and required us to spend a significant amount of time understanding the existing tests and how they worked. +_{other invalid inputs are possible}_ -Finally, writing documentation was a novel experience to us, and necessitated both a deep understanding of the codebase and a good grasp of documentation best practices. Making UML diagrams for the documentation was a particular challenge because of our inexperience with coding in UML. However, after writing the documentation for a few methods, the rest were relatively straightforward to write. +### Saving data -Given the challenges we faced and the novelty of some parts of the project, we would rate the difficulty level of this project as **π/5**. +1. Saving data + + 1. Add a new employee using the `add` command. + + 2. Close the app. + + 3. Launch the app again.
+ Expected: The new employee should still be present. + +2. Dealing with missing data file -### Challenges Faced + 1. Navigate to the folder containing the jar file. The data file should be in **data/hour.json**. + + 2. Delete **hour.json**. -We faced the following challenges during the development of this project: + 3. Launch the app by double-clicking the jar file.
+ Expected: The app should create a new **hour.json** file with sample data in the **data** folder. -* **Understanding the architecture of the project** +3. Dealing with corrupted data file -Initially, we had a hard time understanding the architecture of the project. We were not sure how the different components of the project interacted with each other, and why some classes, such as `ModelManager` were even necessary. However, as we added more modifications and features to the project, we were able to understand the architecture better. + 1. Navigate to the folder containing the jar file. The data file should be in **data/hour.json**. + + 2. Open **hour.json** in a text editor. + + 3. Corrupt the file by deleting some characters. + + 4. Launch the app by double-clicking the jar file.
+ Expected: The app should detect the corrupted file and show an error message in the console. + The app should create a new **hour.json** file with an empty employee book in the **data** folder. -* **Forking workflow** + -Initially, we started with the forking workflow for our project, which was extremely tedious and time-consuming, and led to a lot of merge conflicts. We had to spend a lot of time resolving merge conflicts, and this slowed down our development process. Also, it was difficult to contribute to each other's code, and even minor revisions required a long, inefficient process of syncing the fork, resolving merge conflicts, making the revision, creating a pull request, and merging it. We eventually switched to the branching workflow for v1.3, which was much more efficient and streamlined while maintaining our code quality. +-------------------------------------------------------------------------------------------------------------------- -* **Renaming `person` to `employee`** +## **Appendix: Efforts** -Since our app was focussed on HR management, we decided to rename the `person` class to `employee`. However, this was not as simple as it seemed. We had to rename the class, as well as all the methods and variables that were related to the `person` class, which was a tedious process. This introduced lots of often-mysterious bugs and errors in our code, which we had to spend a lot of time debugging. It also involved making changes to the test data and documentation, which was also a time-consuming process. +This section documents the efforts that went into the development of this project, as well as the challenges faced. -* **Adding and modifying fields in the `employee` class** +### Difficulty Level and Challenges Faced -Adding and modifying fields in the `employee` class was a challenge because we had to ensure that the new fields were compatible with the existing code. We had to ensure that the new fields were properly initialised new `employee` constructors, and that they were properly handled in the model, logic, and storage classes. We also had to ensure that the new fields were properly handled in the parser and the UI. This was a challenge because we had to ensure that the new fields were properly handled in all the different components of the project. +We would rate the difficulty level of this project as **π/5**. -* **Storing reports** +This is because the project codebase and architecture were initially quite challenging to understand, and we had to spend a significant amount of time tracing through the code and understanding how the different components of the project interacted with each other. However, once we understood the architecture of the project, it was relatively straightforward to add most of the new features and modify existing features. -For the `report` command, we had to store the reports in a separate folder. We had to figure out how to create a new folder and store the reports in it within the patterns and constraints of the existing storage classes. This was a challenge because we were not familiar with the storage classes, and we had to figure out how to store the reports in a way that was consistent with the existing storage classes. +The initial use of a forking workflow was extremely tedious and time-consuming, with lots of merge conflicts, slowing down our progress. However, we decided to switch over to a branching workflow, increasing our productivity and efficiency when delivering v1.3 and v1.4. -* **Implementing the `sort` command** +There were a few challenging features, such as the `sort` command, which required us to modify the code at multiple layers of abstraction, and the `report` command, which was one of the few commands that required its own storage class and methods. However, we were able to implement these features successfully after some effort. -For the `sort` command, after exploring and struggling with various approaches from creating separate list views to copying the list, we decided to go ahead with modifying the existing list. This involved adding methods at various layers of abstraction all the way down to the `UniqueEmployeeList` class, which implemented the actual sorting. This was a challenge as it was initially difficult to understand how the different components of the project interacted with each other at each layer of abstraction. This change also broke all of the methods that relied on index for employee selection by making their results unpredictable, and we had to go through all of the methods to change the index to the employee ID. This was a tedious process, and we had to spend a lot of time modifying methods such as `delete` to use the employee ID instead of index, and then debugging them. +Writing our own tests as well as modifying existing tests, while not particularly difficult, was quite time-consuming, and required us to spend a significant amount of time understanding the existing tests and how they worked. -* **Documentation** +Finally, writing documentation was a novel experience to us, and necessitated both a deep understanding of the codebase and a good grasp of documentation best practices. Making UML diagrams for the documentation was a particular challenge because of our inexperience with coding in UML. However, after writing the documentation for a few methods, the rest were relatively straightforward to write. -Being new to writing user and developer guides or creating UML diagrams, we had to spend a significant amount of time looking at existing docs and learning to write our own. We also had to spend a lot of time ensuring that the documentation was consistent with the code and our implementation. This was a challenge because it required an in-depth understanding of the codebase, and so we had to defer most of the technical parts of our documentation towards the end of the project. +Given the challenges we faced and the novelty of some parts of the project, we would rate the difficulty level of this project as **π/5**. ### Effort Required In the project, we invested a moderate level of effort to ensure the successful development and delivery of our product. Here are some of the different aspects of our team efforts: @@ -1597,43 +1833,47 @@ This project has been a very invaluable experience where we got to have a taste One of the things that we are most proud of is the bettering of the UI. Though the change was not very extravagant, the change in colour scheme was a feat in itself since we honestly did not aim to care a lot about our UI. We also managed to add icons beside the employee attributes in each employee card which we believe made it more readable for the users. -Another feature we are proud of is our `report` feature that allows our users to generate reports as txt files for each employee. While it might not contain a lot of information yet, we believe that it was a great starting point considering the time-constraint we had for this project and we plan to extend and further develop this feature, improving the experience for our users. +Another feature we are proud of is our `report` feature that allows our users to generate reports as txt files for each employee. While it might not contain a lot of information yet, we believe that it was a great starting point considering the time-constraint we had for this project, and we plan to extend and further develop this feature, improving the experience for our users. + +Overall, we are proud of our project, and we believe that we have done our best with all the constraints and challenges we faced. We are happy with the result and believe that our product will meet the needs of our target audience. -Overall, we are proud of our project and we believe that we have done our best with all the constraints and challenges we faced. We are happy with the result and believe that our product will meet the needs of our target audience. + + +-------------------------------------------------------------------------------------------------------------------- -## Planned Enhancements +## **Appendix: Planned Enhancements** ### Remark not shown in GUI employee list -Problem: +**Problem:** * In our current implementation, the remark is not displayed on the employee list in GUI. * Users have to use report command to display employee remarks in message box. -Solution: +**Solution:** * We will update the employee card in the GUI to display remarks of the employees upon clicking on it. * This is to ensure the displayed employee card is not cluttered with too much information. ### Deleting a remark requires typing the whole remark -Problem: +**Problem:** * In our current implementation, deleting a remark requires the user to type in the remark exactly as it is typed in when added, i.e. exactly as it is shown in the message box. * This can be tedious, especially for long remarks. -Solution: +**Solution:** * A solution is to address a remark by its index (based on date added) instead of its value, so that `deleteremark id/EMPLOYEE_ID 1` is enough to delete the first remark of employee with - employee id EMPLOYEE_ID. + employee ID EMPLOYEE_ID. ### Adding a leave with a date far in the past and future -Problem: +**Problem:** * In our current implementation, users are able to add a leave for an employee with date that is too far in the past and in the future, such as `1111-11-11` and `2222-12-12`. * While users should be able to add a past and future dates as leaves for record keeping purposes, we see that being able to input a date this extreme is excessive and highly unrealistic. -Solution: +**Solution:** * We will enhance the leave list so that there are three separate lists, one for the current year, one for the previous year, and one for the following year. * Users will only be allowed to add leave dates that fall within the time period of the beginning of the previous year to the end of the following year, and the number of annual leaves allocated will be calculated accordingly. @@ -1641,46 +1881,62 @@ Solution: ### No efficient way to view a specific employee's leave dates -Problem: +**Problem:** * In our current implementation, users can only view which employees are on leave on specific dates using `listleave` command. There is currently no specific command that allows users to view leave dates taken by a specific employee. * The list of an employee's leave date can only be displayed when a user adds, edits, or deletes a leave date of that employee. -Solution: +**Solution:** * A possible solution is to display the leaves taken by an employee when the user executes a report command on the employee. ### Two employees are allowed to have the same phone number or email -Problem: +**Problem:** * In our current implementation, adding an employee with the same phone number or email as another existing employee is allowed. -* This is caused by our decision to only check same employee by comparing by employee id. +* This is caused by our decision to only check same employee by comparing by employee ID. * This might lead to unintended duplicates. Solution: -* We will update the check for the same employee to check not only by employee id but also by phone number and email. +* We will update the check for the same employee to check not only by employee ID but also by phone number and email. ### Unable to view the number of leaves remaining when adding a leave period that exceeds maximum number of leaves -Problem: +**Problem:** * In our current implementation, if a user tries to add a leave for an employee but that exceeds the maximum number of allowed employee leaves, the app only displays an error message telling the user it exceeds the remaining number of leaves. * However, the app does not show the remaining number of leaves, so the fastest method is to use report command to display the current amount of leaves taken by the employee and perform manual subtraction to obtain remaining number of leaves. -Solution: +**Solution:** * We plan to revamp the error messages pertaining to this issue to display as much information as possible to the user, in this case the remaining number of leaves. * In this case, it is to change the error message into this:
`This leave period exceeds the number of leaves remaining for this employee`
`Number of leaves remaining: 1` -### Unclear error message for invalid email address +### Unable to view the number of overtime hours remaining when updating overtime hours that exceeds the range of allowed number of overtime hours Problem: +* In our current implementation, if a user tries to update the number of overtime hours for an employee and exceeds the + maximum number of allowed overtime hours or make it fall below zero, the app only displays an error message + telling the user it exceeds the range of allowed number of overtime hours. +* However, the app does not show the remaining number of overtime hours, so the fastest method is to use report command to display the current amount of + overtime hours taken by the employee and perform manual subtraction to obtain remaining number of overtime hours. + +Solution: +* We plan to revamp the error messages pertaining to this issue to display as much information as possible to the user, + in this case the remaining number of overtime hours. +* In this case, it is to change the error message into this:
+ `Number of overtime hours should not be above 72 or below 0`
+ `Number of overtime hours remaining: 2` + +### Unclear error message for invalid email address + +**Problem:** * In our current implementation, when a user keys in an invalid email address, the error message shown is very long and slightly inconsistent. * This will highly confuse users who have very complex email addresses and keys the wrong email address by mistake. -Solution: +**Solution:** * We intend to keep error messages as short but as unambiguous as possible, so that users are able to identify their misinputs and fix them accordingly. * In this case, it is to shorten the email error message into this:
@@ -1691,9 +1947,9 @@ Solution: `- end with a domain label at least 2 characters long.`
`- have each domain label contain only alphanumeric characters.`
-### Edit command error message is inconsistent with respect to invalid id +### Edit command error message is inconsistent with respect to invalid ID -Problem: +**Problem:** * In our current implementation, when a user inputs an invalid index in an edit command, the error messages differ with different user inputs. * If index is less than one, i.e. 0 and below, the error message indicates an invalid command format due to the parser @@ -1702,9 +1958,22 @@ Problem: command class being the one checking if index is too high. * This inconsistency between error messages on the same issue can be confusing for users. -Solution: +**Solution:** * We plan to let the command class take care of determining whether an index is invalid or not while the parser class only needs to check if index is an integer. * This will establish consistency when a user inputs a wrong index regardless if it's below one or above current number of employees displayed. * It will still keep the invalid command format error message if index input is not an integer. + +### Inconsistent arrangement of leaves in the leave list + +**Problem:** +* In our current implementation, the leaves in the leave list shown in the result display are sorted according to when they were added to the employee. +* Moreover, editing a leave date replaces the previous date with the new date, rather than deleting the previous date and adding the new date to the end of the leave list. +* Such inconsistency can be confusing for users, and the current arrangement might lead to trouble finding specific leave dates in a long list of dates. + +**Solution:** +* We plan to standardise the arrangement of the leave dates, such that they are sorted in chronological order. +* After any command that changes the leave list (e.g. `addleave`, `editleave`), the leave list will be re-sorted, + with the earliest date at the top of the list and the latest date at the end of the list. +* This will reduce any inconsistencies, and make finding specific leave dates easier for users. diff --git a/docs/UserGuide.md b/docs/UserGuide.md index 58b379373e2..e2c69066222 100644 --- a/docs/UserGuide.md +++ b/docs/UserGuide.md @@ -3,7 +3,10 @@ layout: page title: User Guide --- - +
+
+
+
## Welcome to HouR
HouR is a **desktop app for managing employee records, optimized for use via a Command Line Interface** (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, HouR can get your HR management tasks done faster than traditional GUI apps.
@@ -15,24 +18,24 @@ HouR is a **desktop app for managing employee records, optimized for use via a C
- [Using this guide](#using-this-guide)
- [Useful Notations and Glossary](#useful-notations-and-glossary)
- [Quick Start](#quick-start)
-- [Navigating the GUI](#navigating-the-graphical-user-interface--gui-)
+- [Navigating the GUI](#navigating-the-gui)
- [Features](#features)
- [General Commands](#general-commands)
- [Viewing Help](#viewing-help--help): `help`
- [Clearing all employees](#clearing-all-entries--clear): `clear`
- [Exiting the program](#exiting-the-program--exit): `exit`
- [Employee Commands](#employee-commands)
- - [Adding an employee](#adding-an-employee-add): `add`
+ - [Adding an employee](#adding-an-employee--add): `add`
- [Deleting an employee](#deleting-an-employee--delete): `delete`
- [Editing an employee](#editing-an-employee--edit): `edit`
- [Listing all employees](#listing-all-employees--list): `list`
- - [Locating employees](#finding-employees--find): `find`
+ - [Finding employees](#finding-employees--find): `find`
- [Sorting employees](#sorting-all-employees--sort): `sort`
- [Employee Metrics Commands](#employee-metrics-commands)
- - [Adding a leave period](#adding-a-leave-period-of-an-employee-addleave): `addleave`
- - [Deleting a leave period](#deleting-a-leave-period-of-an-employee-deleteleave): `deleteleave`
+ - [Adding a leave period](#adding-a-leave-period-of-an-employee--addleave): `addleave`
+ - [Deleting a leave period](#deleting-a-leave-period-of-an-employee--deleteleave): `deleteleave`
- [Editing a leave date](#editing-a-leave-date-of-an-employee--editleave): `editleave`
- - [Listing employees on leave](#listing-the-employees-on-leave-on-a-specified-date--listleave) `listleave`
+ - [Listing employees on leave](#listing-the-employees-on-leave-on-a-specified-date--listleave): `listleave`
- [Adding remarks](#adding-a-remark-for-an-employee--addremark): `addremark`
- [Deleting remarks](#deleting-a-remark-of-an-employee--deleteremark): `deleteremark`
- [Updating overtime hours](#updating-overtime-hours-of-an-employee--overtime): `overtime`
@@ -48,7 +51,6 @@ HouR is a **desktop app for managing employee records, optimized for use via a C
--------------------------------------------------------------------------------------------------------------------
## Using this guide
-
* If you are new here, visit our [quick start](#quick-start) guide to onboard onto HouR smoothly!
* If you are unsure of how to use HouR, the [Command Summary](#command-summary) is a good place to start.
* If you are a developer and want to help out, do take a look at our [Developer Guide](https://ay2324s1-cs2103t-w12-1.github.io/tp/DeveloperGuide.html).
@@ -67,7 +69,7 @@ The following glossary table provides clarification on commonly-used terms as we
| Symbol | Meaning |
|:----------------:|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| GUI | GUI stands for Graphical User Interface and it represents the visual display of HouR that users can see when the application is run. |
-| GUI component | A subsection of the GUI. For more information on specific GUI components, refer to this [section](#navigating-the-graphical-user-interface--gui-). |
+| GUI component | A subsection of the GUI. For more information on specific GUI components, refer to this [section](#navigating-the-gui). |
| CLI | CLI stands for Command Line Interface and it represents a text-based user interface to interact with the application. |
| Command | An input from the user that tells HouR to perform an action. View HouR's [command summary](#command-summary). |
| Parameter | Parameters are like fields in a form you are required to fill up. They are information needed to be passed together with the command so that it can be executed. More information regarding parameters can be found [here](#parameter-information). |
@@ -88,50 +90,49 @@ The following glossary table provides clarification on commonly-used terms as we
4. Open a command terminal, `cd` into the folder you put the jar file in, and use the `java -jar hour.jar` command to run the application.
+A GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
-  +  -
:exclamation: **Caution to Mac users:**
-Performing these instructions may result in non-deterministic behaviour of data loading in HouR. This was tested on multiple MacOS Systems:
-
-* Right-click `hour.jar` > Open With > JavaLauncher.app
-* First-time users may be prompted with a warning that the file was downloaded from the Internet. Simply click Open in the prompt to continue.
+
Some example commands you can try: - * `help`: Shows help window with link to user guide. + * `help` : Shows help window with link to user guide. * `add n/John Doe pos/Senior Software Enginner id/EID2023-7890 p/81239876 e/johndoe@test.com s/5000` : Adds an employee named `John Doe` to the employee list. * `list` : Lists all employees. - * `edit 1 n/Alex Yeoh`: Edits the name of the 1st employee shown in the current list to `Alex Yeoh`. + * `edit 1 n/Alex Yeoh` : Edits the name of the 1st employee shown in the current list to `Alex Yeoh`. * `find Alex Manager`: Lists all employees with the keywords `Alex` or `Manager`. * `delete EID2023-1234` : Deletes the employee with employee id EID2023-1234 shown in the list. - * `sort f/salary in/asc`: Sorts the employees by their salaries in ascending order. + * `sort f/salary in/asc` : Sorts the employees by their salaries in ascending order. - * `addleave id/EID1234-5678 from/2023-12-26 to/2023-12-28`: Adds leave dates from 26 to 28 December 2023 inclusive for employee with id EID1234-5678. + * `addleave id/EID1234-5678 from/2023-12-26 to/2023-12-28` : Adds leave dates from 26 to 28 December 2023 inclusive for employee with id EID1234-5678. - * `deleteleave id/EID1234-5678 from/2023-12-27 to/2023-12-27`: Deletes leave date 27 December 2023 for employee with id EID1234-5678. + * `deleteleave id/EID1234-5678 from/2023-12-27 to/2023-12-27` : Deletes leave date 27 December 2023 for employee with id EID1234-5678. - * `editleave id/EID1234-5678 old/2023-12-26 new/2023-12-29`: Edits the old leave date on 26 December 2023 of employee with id EID1234-5678 to new leave date on 29 December 2023. + * `editleave id/EID1234-5678 old/2023-12-26 new/2023-12-29` : Edits the old leave date on 26 December 2023 of employee with id EID1234-5678 to new leave date on 29 December 2023. - * `listleave on/2023-12-28`: Lists all employees on leave on 28 December 2023. + * `listleave on/2023-12-28` : Lists all employees on leave on 28 December 2023. - * `addremark id/EID1234-5678 r/good worker`: Adds the remark `good worker` to the employee with id EID1234-6788. + * `addremark id/EID1234-5678 r/good worker` : Adds the remark `good worker` to the employee with id EID1234-6788. - * `deleteremark id/EID1234-5678 r/good worker`: Deletes the remark `good worker` from the employee with id EID1234-5678. + * `deleteremark id/EID1234-5678 r/good worker` : Deletes the remark `good worker` from the employee with id EID1234-5678. - * `overtime id/EID1234-5678 o/inc a/10`: Increases the overtime hours of employee with id EID1234-5678 by 10 hours. + * `overtime id/EID1234-5678 o/inc a/10` : Increases the overtime hours of employee with id EID1234-5678 by 10 hours. - * `report EID1234-5678`: Generates a report with details of the employee with id EID1234-5678. + * `report EID1234-5678` : Generates a report with details of the employee with id EID1234-5678. - * `reset f/overtime`: Resets the overtime hours field of all employees to the default value 0. + * `reset f/overtime` : Resets the overtime hours field of all employees to the default value 0. * `clear` : Deletes all employees. @@ -143,9 +144,9 @@ Performing these instructions may result in non-deterministic behaviour of data -------------------------------------------------------------------------------------------------------------------- -## Navigating the Graphical User Interface (GUI) +## Navigating the GUI -HouR comes with a GUI to allow for nice visual feedback for our users. Here is a quick run-through of the different sections of our GUI, as well as some notes regarding the use of the GUI. +HouR comes with a Graphical User Interface (GUI) to allow for nice visual feedback for our users. Here is a quick run-through of the different sections of our GUI, as well as some notes regarding the use of the GUI. ### Quick Orientation @@ -182,6 +183,8 @@ Below is an overview of HouR's features. - Clear all employees: `clear` - Exit the program: `exit` + +
+ * macOS/Linux: Open the Terminal and navigate to the directory where the script is located. Type `chmod +x [script name]` and press Enter.
Note: (`chmod +x` changes permissions of the script to allow it to be executed) 5. Double-click on the script to launch HouR 6. HouR should launch @@ -663,7 +671,7 @@ If you have any further issues, please raise an issue on our [Github page](https **Q**: How can I check my Java version?
**A**: Open a Command Prompt and type `java -version`. If you do not have Java installed, you can install Java 11 using the Oracle guide [here](https://www.oracle.com/java/technologies/downloads/#java11). Alternatively, you can install the OpenJDK version. -For Mac users, you may wish to follow the instructions listed [here](https://nus-cs2103-ay2324s1.github.io/website/admin/programmingLanguages.html). +For macOS users, you may wish to follow the instructions listed [here](https://nus-cs2103-ay2324s1.github.io/website/admin/programmingLanguages.html). ### Loading Data from Another Computer @@ -755,7 +763,7 @@ If you would like to reset the number of leaves or overtime hours for **a specif ## Parameter information -The table below provides information on the usage of the allowed parameters in HouR. Do note that the examples given are not exhaustive +The table below provides information on the usage of the allowed parameters in HouR. Do note that the examples given are not exhaustive. | Parameter, Description | Case sensitive | Constraints | Valid Examples | Invalid Examples | |---------------------------------------------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|----------------------------------------------------------| diff --git a/docs/diagrams/AddActivityDiagram.puml b/docs/diagrams/AddActivityDiagram.puml index 9401facf190..87c2b824441 100644 --- a/docs/diagrams/AddActivityDiagram.puml +++ b/docs/diagrams/AddActivityDiagram.puml @@ -5,37 +5,18 @@ start :User inputs add command; if () then ([else]) - :Display error message; +:Display error message; else ([Valid command format]) - if () then ([else]) - :Display error message; - else ([Valid and unique employee ID]) - if () then ([else]) - :Display error message; - else ([Valid name]) - if () then ([else]) - :Display error message; - else ([Valid position]) - if () then ([else]) - :Display error message; - else ([Valid email]) - if () then ([else]) - :Display error message; - else ([Valid phone number]) - if () then ([else]) - :Display error message; - else ([Valid salary]) - if () then ([else]) - :Display error message; - else ([Valid department(s) if present]) - :Add employee to employee list; - :Display success message; - endif - endif - endif - endif - endif - endif +if () then ([else]) +:Display error message; +else ([Valid and unique employee ID]) +if () then ([else]) +:Display error message; +else ([Valid employee fields]) + +:Add employee to employee list; +:Display success message; +endif endif endif stop diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml index 48b6cc4333c..c4a64c8b45f 100644 --- a/docs/diagrams/ArchitectureSequenceDiagram.puml +++ b/docs/diagrams/ArchitectureSequenceDiagram.puml @@ -8,13 +8,13 @@ Participant ":Logic" as logic LOGIC_COLOR Participant ":Model" as model MODEL_COLOR Participant ":Storage" as storage STORAGE_COLOR -user -[USER_COLOR]> ui : "delete 1" +user -[USER_COLOR]> ui : "delete EID1234-5678" activate ui UI_COLOR -ui -[UI_COLOR]> logic : execute("delete 1") +ui -[UI_COLOR]> logic : execute("delete EID1234-5678") activate logic LOGIC_COLOR -logic -[LOGIC_COLOR]> model : deletePerson(p) +logic -[LOGIC_COLOR]> model : deleteEmployee(p) activate model MODEL_COLOR model -[MODEL_COLOR]-> logic diff --git a/docs/diagrams/BetterModelClassDiagram.puml b/docs/diagrams/BetterModelClassDiagram.puml index 598474a5c82..7482db717a9 100644 --- a/docs/diagrams/BetterModelClassDiagram.puml +++ b/docs/diagrams/BetterModelClassDiagram.puml @@ -4,18 +4,23 @@ skinparam arrowThickness 1.1 skinparam arrowColor MODEL_COLOR skinparam classBackgroundColor MODEL_COLOR -AddressBook *-right-> "1" UniquePersonList -AddressBook *-right-> "1" UniqueTagList -UniqueTagList -[hidden]down- UniquePersonList -UniqueTagList -[hidden]down- UniquePersonList +AddressBook *-right-> "1" UniqueEmployeeList +AddressBook *-right-> "1" UniqueDepartmentList +UniqueDepartmentList -[hidden]down- UniqueEmployeeList +UniqueDepartmentList -[hidden]down- UniqueEmployeeList -UniqueTagList -right-> "*" Tag -UniquePersonList -right-> Person +UniqueDepartmentList -right-> "*" Department +UniqueEmployeeList -right-> Employee -Person -up-> "*" Tag +Employee -up-> "*" Department -Person *--> Name -Person *--> Phone -Person *--> Email -Person *--> Address +Employee *--> Name +Employee *--> Position +Employee *--> Id +Employee *--> Phone +Employee *--> Email +Employee *--> Salary +Employee *--> LeaveList +Employee *--> OvertimeHours +Employee *--> RemarkList @enduml diff --git a/docs/diagrams/ModelClassDiagram.puml b/docs/diagrams/ModelClassDiagram.puml index 0de5673070d..33af1e41358 100644 --- a/docs/diagrams/ModelClassDiagram.puml +++ b/docs/diagrams/ModelClassDiagram.puml @@ -12,13 +12,18 @@ Class AddressBook Class ModelManager Class UserPrefs -Class UniquePersonList -Class Person -Class Address +Class UniqueEmployeeList +Class Employee +Class Id Class Email Class Name Class Phone -Class Tag +Class Position +Class Salary +Class LeaveList +Class OvertimeHours +Class RemarkList +Class Department Class I #FFFFFF } @@ -35,20 +40,25 @@ ModelManager -left-> "1" AddressBook ModelManager -right-> "1" UserPrefs UserPrefs .up.|> ReadOnlyUserPrefs -AddressBook *--> "1" UniquePersonList -UniquePersonList --> "~* all" Person -Person *--> Name -Person *--> Phone -Person *--> Email -Person *--> Address -Person *--> "*" Tag +AddressBook *--> "1" UniqueEmployeeList +UniqueEmployeeList --> "~* all" Employee +Employee *--> Name +Employee *--> Phone +Employee *--> Email +Employee *--> Id +Employee *--> Position +Employee *--> Salary +Employee *--> LeaveList +Employee *--> OvertimeHours +Employee *--> RemarkList +Employee *--> "*" Department -Person -[hidden]up--> I -UniquePersonList -[hidden]right-> I +Employee -[hidden]up--> I +UniqueEmployeeList -[hidden]right-> I -Name -[hidden]right-> Phone -Phone -[hidden]right-> Address -Address -[hidden]right-> Email +Name -[hidden]right-> Position +Id -[hidden]right-> Phone +Phone -[hidden]right-> Email -ModelManager --> "~* filtered" Person +ModelManager --> "~* filtered" Employee @enduml diff --git a/docs/diagrams/OvertimeActivityDiagram.puml b/docs/diagrams/OvertimeActivityDiagram.puml new file mode 100644 index 00000000000..03d5f47c55e --- /dev/null +++ b/docs/diagrams/OvertimeActivityDiagram.puml @@ -0,0 +1,24 @@ +@startuml +'https://plantuml.com/activity-diagram-beta + +start +:User inputs overtime command; + +if () then ([else]) + :Display error message; +else ([valid command]) + if () then ([else]) + :Display error message; + else ([valid ID]) + if () then ([else]) + :Display error message; + else ([valid operation]) + if () then ([else]) + :Display error message; + else ([valid amount]) + :Update employee's overtime hours; + :Display overtime success message; + endif + endif + +@enduml diff --git a/docs/diagrams/OvertimeSequenceDiagram.puml b/docs/diagrams/OvertimeSequenceDiagram.puml new file mode 100644 index 00000000000..71fb1cda00d --- /dev/null +++ b/docs/diagrams/OvertimeSequenceDiagram.puml @@ -0,0 +1,72 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR +participant ":OvertimeCommandParser" as OvertimeCommandParser LOGIC_COLOR +participant "r:OvertimeCommand" as OvertimeCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":Model" as Model MODEL_COLOR +end box +[-> LogicManager : execute("overtime id/EID1234-5678 o/inc a/2") +activate LogicManager + +LogicManager -> AddressBookParser : parseCommand("overtime id/EID1234-5678 o/inc a/2") +activate AddressBookParser + +create OvertimeCommandParser +AddressBookParser -> OvertimeCommandParser +activate OvertimeCommandParser + +OvertimeCommandParser --> AddressBookParser +deactivate OvertimeCommandParser + +AddressBookParser -> OvertimeCommandParser : parse("overtime id/EID1234-5678 o/inc a/2") +activate OvertimeCommandParser + +create OvertimeCommand +OvertimeCommandParser -> OvertimeCommand +activate OvertimeCommand + +OvertimeCommand --> OvertimeCommandParser : r +deactivate OvertimeCommand + +OvertimeCommandParser --> AddressBookParser : r +deactivate OvertimeCommandParser + +OvertimeCommandParser -[hidden]-> AddressBookParser +destroy OvertimeCommandParser + +AddressBookParser --> LogicManager : r +deactivate AddressBookParser + +LogicManager -> OvertimeCommand : execute() +activate OvertimeCommand + +OvertimeCommand -> Model : setEmployee(employeeToUpdate, updatedEmployee) +activate Model + +Model --> OvertimeCommand + +OvertimeCommand -> Model : updateFilteredEmployeeList() + +Model --> OvertimeCommand +deactivate Model + +create CommandResult +OvertimeCommand -> CommandResult +activate CommandResult + +CommandResult --> OvertimeCommand +deactivate CommandResult + +OvertimeCommand --> LogicManager : result +deactivate OvertimeCommand + +[<--LogicManager +deactivate LogicManager +@enduml diff --git a/docs/diagrams/SortSequenceDiagram.puml b/docs/diagrams/SortSequenceDiagram.puml index ccbfdb4c80e..16e29aed142 100644 --- a/docs/diagrams/SortSequenceDiagram.puml +++ b/docs/diagrams/SortSequenceDiagram.puml @@ -11,8 +11,6 @@ end box box Model MODEL_COLOR_T1 participant ":Model" as Model MODEL_COLOR -participant ":AddressBook" as AddressBook MODEL_COLOR -participant ":UniqueEmployeeList" as UniqueEmployeeList MODEL_COLOR end box [-> LogicManager : execute("sort f/salary in/asc") activate LogicManager @@ -49,27 +47,9 @@ deactivate AddressBookParser LogicManager -> SortCommand : execute() activate SortCommand -SortCommand -> SortCommand : handleSortingOrder(model, "salary", "asc") -activate SortCommand - -SortCommand --> SortCommand -deactivate SortCommand - SortCommand -> Model : updateSortedEmployeeListAscending("salary"); activate Model -Model -> AddressBook : updateSortedEmployeeListAscending("salary") -activate AddressBook - -AddressBook -> UniqueEmployeeList : sortEmployeesAscending("salary"); -activate UniqueEmployeeList - -UniqueEmployeeList --> AddressBook -deactivate UniqueEmployeeList - -AddressBook --> Model -deactivate AddressBook - Model --> SortCommand deactivate Model diff --git a/docs/diagrams/StorageClassDiagram.puml b/docs/diagrams/StorageClassDiagram.puml index a821e06458c..754f6211858 100644 --- a/docs/diagrams/StorageClassDiagram.puml +++ b/docs/diagrams/StorageClassDiagram.puml @@ -18,8 +18,10 @@ package "AddressBook Storage" #F4F6F6{ Class "<>\nAddressBookStorage" as AddressBookStorage
Class JsonAddressBookStorage
Class JsonSerializableAddressBook
-Class JsonAdaptedPerson
-Class JsonAdaptedTag
+Class JsonAdaptedEmployee
+Class JsonAdaptedDepartment
+Class JsonAdaptedLeave
+Class JsonAdaptedRemark
}
}
@@ -37,7 +39,9 @@ Storage -right-|> AddressBookStorage
JsonUserPrefsStorage .up.|> UserPrefsStorage
JsonAddressBookStorage .up.|> AddressBookStorage
JsonAddressBookStorage ..> JsonSerializableAddressBook
-JsonSerializableAddressBook --> "*" JsonAdaptedPerson
-JsonAdaptedPerson --> "*" JsonAdaptedTag
+JsonSerializableAddressBook --> "*" JsonAdaptedEmployee
+JsonAdaptedEmployee --> "*" JsonAdaptedDepartment
+JsonAdaptedEmployee --> "*" JsonAdaptedLeave
+JsonAdaptedEmployee --> "*" JsonAdaptedRemark
@enduml
diff --git a/docs/diagrams/UiClassDiagram.puml b/docs/diagrams/UiClassDiagram.puml
index 95473d5aa19..3ad58e6082d 100644
--- a/docs/diagrams/UiClassDiagram.puml
+++ b/docs/diagrams/UiClassDiagram.puml
@@ -11,8 +11,8 @@ Class UiManager
Class MainWindow
Class HelpWindow
Class ResultDisplay
-Class PersonListPanel
-Class PersonCard
+Class EmployeeListPanel
+Class EmployeeCard
Class StatusBarFooter
Class CommandBox
}
@@ -32,26 +32,26 @@ UiManager .left.|> Ui
UiManager -down-> "1" MainWindow
MainWindow *-down-> "1" CommandBox
MainWindow *-down-> "1" ResultDisplay
-MainWindow *-down-> "1" PersonListPanel
+MainWindow *-down-> "1" EmployeeListPanel
MainWindow *-down-> "1" StatusBarFooter
MainWindow --> "0..1" HelpWindow
-PersonListPanel -down-> "*" PersonCard
+EmployeeListPanel -down-> "*" EmployeeCard
MainWindow -left-|> UiPart
ResultDisplay --|> UiPart
CommandBox --|> UiPart
-PersonListPanel --|> UiPart
-PersonCard --|> UiPart
+EmployeeListPanel --|> UiPart
+EmployeeCard --|> UiPart
StatusBarFooter --|> UiPart
HelpWindow --|> UiPart
-PersonCard ..> Model
+EmployeeCard ..> Model
UiManager -right-> Logic
MainWindow -left-> Logic
-PersonListPanel -[hidden]left- HelpWindow
+EmployeeListPanel -[hidden]left- HelpWindow
HelpWindow -[hidden]left- CommandBox
CommandBox -[hidden]left- ResultDisplay
ResultDisplay -[hidden]left- StatusBarFooter
diff --git a/docs/diagrams/UndoRedoState1.puml b/docs/diagrams/UndoRedoState1.puml
index 5a41e9e1651..5678c11f861 100644
--- a/docs/diagrams/UndoRedoState1.puml
+++ b/docs/diagrams/UndoRedoState1.puml
@@ -4,7 +4,7 @@ skinparam ClassFontColor #000000
skinparam ClassBorderColor #000000
skinparam ClassBackgroundColor #FFFFAA
-title After command "delete 5"
+title After command "delete EID1234-5678"
package States <> {
class State1 as "ab0:AddressBook"
diff --git a/docs/diagrams/UndoRedoState2.puml b/docs/diagrams/UndoRedoState2.puml
index ad32fce1b0b..d0a2a30df39 100644
--- a/docs/diagrams/UndoRedoState2.puml
+++ b/docs/diagrams/UndoRedoState2.puml
@@ -4,7 +4,7 @@ skinparam ClassFontColor #000000
skinparam ClassBorderColor #000000
skinparam ClassBackgroundColor #FFFFAA
-title After command "add n/David"
+title After command "add n/David..."
package States <> {
class State1 as "ab0:AddressBook"
diff --git a/docs/images/AddActivityDiagram.png b/docs/images/AddActivityDiagram.png
index 977b05ee3a0..3842a246d3a 100644
Binary files a/docs/images/AddActivityDiagram.png and b/docs/images/AddActivityDiagram.png differ
diff --git a/docs/images/ArchitectureSequenceDiagram.png b/docs/images/ArchitectureSequenceDiagram.png
index 37ad06a2803..6a202351ed2 100644
Binary files a/docs/images/ArchitectureSequenceDiagram.png and b/docs/images/ArchitectureSequenceDiagram.png differ
diff --git a/docs/images/BetterModelClassDiagram.png b/docs/images/BetterModelClassDiagram.png
index 02a42e35e76..1a19c8f659c 100644
Binary files a/docs/images/BetterModelClassDiagram.png and b/docs/images/BetterModelClassDiagram.png differ
diff --git a/docs/images/ModelClassDiagram.png b/docs/images/ModelClassDiagram.png
index a19fb1b4ac8..97083c88b56 100644
Binary files a/docs/images/ModelClassDiagram.png and b/docs/images/ModelClassDiagram.png differ
diff --git a/docs/images/OvertimeActivityDiagram.png b/docs/images/OvertimeActivityDiagram.png
new file mode 100644
index 00000000000..3563dd80f56
Binary files /dev/null and b/docs/images/OvertimeActivityDiagram.png differ
diff --git a/docs/images/OvertimeSequenceDiagram.png b/docs/images/OvertimeSequenceDiagram.png
new file mode 100644
index 00000000000..ee7fe575afb
Binary files /dev/null and b/docs/images/OvertimeSequenceDiagram.png differ
diff --git a/docs/images/SortSequenceDiagram.png b/docs/images/SortSequenceDiagram.png
index ef9cad04182..72906df92ed 100644
Binary files a/docs/images/SortSequenceDiagram.png and b/docs/images/SortSequenceDiagram.png differ
diff --git a/docs/images/StorageClassDiagram.png b/docs/images/StorageClassDiagram.png
index 18fa4d0d51f..751d4c2c55b 100644
Binary files a/docs/images/StorageClassDiagram.png and b/docs/images/StorageClassDiagram.png differ
diff --git a/docs/images/ug-pics/Ui.png b/docs/images/Ui.png
similarity index 100%
rename from docs/images/ug-pics/Ui.png
rename to docs/images/Ui.png
diff --git a/docs/images/UiClassDiagram.png b/docs/images/UiClassDiagram.png
index 11f06d68671..3f9f0eea192 100644
Binary files a/docs/images/UiClassDiagram.png and b/docs/images/UiClassDiagram.png differ
diff --git a/docs/images/UndoRedoState1.png b/docs/images/UndoRedoState1.png
index 2d3ad09c047..2c9541ce681 100644
Binary files a/docs/images/UndoRedoState1.png and b/docs/images/UndoRedoState1.png differ
diff --git a/docs/images/UndoRedoState2.png b/docs/images/UndoRedoState2.png
index 20853694e03..70a157d2a3e 100644
Binary files a/docs/images/UndoRedoState2.png and b/docs/images/UndoRedoState2.png differ
diff --git a/docs/index.md b/docs/index.md
index 74d7e22460d..5d4310be37d 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -6,7 +6,7 @@ title: HouR
[](https://github.com/AY2324S1-CS2103T-W12-1/tp/actions)
[](https://codecov.io/gh/AY2324S1-CS2103T-W12-1/tp)
-
+
**HouR is a desktop application for managing your employee records.** While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface).
diff --git a/docs/team/inezkok.md b/docs/team/inezkok.md
index bf14d915933..015105f79cf 100644
--- a/docs/team/inezkok.md
+++ b/docs/team/inezkok.md
@@ -7,7 +7,7 @@ title: Inez Kok's Project Portfolio Page
HouR is a desktop HR management application used for managing and organising personnel data.
The user interacts with it using a CLI, and it has a GUI created with JavaFX.
-It is written in Java, and has about 9 kLoC.
+It is written in Java, and has about 12 kLoC.
Given below are my contributions to the project.
@@ -34,7 +34,7 @@ Given below are my contributions to the project.
* Reviewing, approving and merging pull requests on GitHub (some pull requests [#216](https://github.com/AY2324S1-CS2103T-W12-1/tp/pull/216), [#150](https://github.com/AY2324S1-CS2103T-W12-1/tp/pull/150), [#146](https://github.com/AY2324S1-CS2103T-W12-1/tp/pull/146))
* Creating and assigning bugs and tasks to everyone on GitHub Issue Tracker
* Maintaining milestones and deadlines on GitHub
- * Managed releases `v1.2` and `v1.3.2` (2 releases) on GitHub
+ * Managed releases `v1.2`, `v1.3.2` and `v1.4` (3 releases) on GitHub
* Created and maintained Team Project Notes on Google Docs
* **Enhancements to existing features**:
diff --git a/docs/team/lordsaumya.md b/docs/team/lordsaumya.md
index d1575699e29..fb982f2fdb7 100644
--- a/docs/team/lordsaumya.md
+++ b/docs/team/lordsaumya.md
@@ -7,7 +7,7 @@ title: Saumya Shah's Project Portfolio Page
HouR is a desktop HR management application used for managing and organising personnel data.
The user interacts with it using a CLI, and it has a GUI created with JavaFX.
-It is written in Java, and has about 8 kLoC.
+It is written in Java, and has about 12 kLoC.
Given below are my contributions to the project.
@@ -53,6 +53,8 @@ Given below are my contributions to the project.
* Added testing instructions for launch and shutdown.
* Added testing instructions for the `find` and `report` commands.
* Added the challenges faced and the difficulty level of the project.
+ * Reformatted and restructured it for consistency and readability.
+ * Added implementation subheadings and hyperlinks to the table of contents.
* **Community**:
diff --git a/docs/team/miljyy.md b/docs/team/miljyy.md
index bd9b413c53d..a05fef099ce 100644
--- a/docs/team/miljyy.md
+++ b/docs/team/miljyy.md
@@ -45,7 +45,7 @@ Given below are my contributions to the project.
* Check through overall formatting and content of UG
* Developer Guide:
* Added implementation and testing guide for add leave and list leave feature
- * Created UML diagrams to illustrate method implementations
+ * Created UML diagrams to illustrate implementations
* Updated the user stories
* Check through overall formatting and content of DG
:exclamation: **Caution to macOS users:**
+Performing these instructions may result in non-deterministic behaviour of data loading in HouR. This was tested on multiple macOS Systems:
+
1. Right-click `hour.jar` > Open With > JavaLauncher.app +
2. First-time users may be prompted with a warning that the file was downloaded from the Internet. Simply click Open in the prompt to continue.
5. Type a command in the command box and press Enter to execute it. e.g. typing `help` and pressing Enter will open the help window.1. Right-click `hour.jar` > Open With > JavaLauncher.app +
2. First-time users may be prompted with a warning that the file was downloaded from the Internet. Simply click Open in the prompt to continue.
Some example commands you can try: - * `help`: Shows help window with link to user guide. + * `help` : Shows help window with link to user guide. * `add n/John Doe pos/Senior Software Enginner id/EID2023-7890 p/81239876 e/johndoe@test.com s/5000` : Adds an employee named `John Doe` to the employee list. * `list` : Lists all employees. - * `edit 1 n/Alex Yeoh`: Edits the name of the 1st employee shown in the current list to `Alex Yeoh`. + * `edit 1 n/Alex Yeoh` : Edits the name of the 1st employee shown in the current list to `Alex Yeoh`. * `find Alex Manager`: Lists all employees with the keywords `Alex` or `Manager`. * `delete EID2023-1234` : Deletes the employee with employee id EID2023-1234 shown in the list. - * `sort f/salary in/asc`: Sorts the employees by their salaries in ascending order. + * `sort f/salary in/asc` : Sorts the employees by their salaries in ascending order. - * `addleave id/EID1234-5678 from/2023-12-26 to/2023-12-28`: Adds leave dates from 26 to 28 December 2023 inclusive for employee with id EID1234-5678. + * `addleave id/EID1234-5678 from/2023-12-26 to/2023-12-28` : Adds leave dates from 26 to 28 December 2023 inclusive for employee with id EID1234-5678. - * `deleteleave id/EID1234-5678 from/2023-12-27 to/2023-12-27`: Deletes leave date 27 December 2023 for employee with id EID1234-5678. + * `deleteleave id/EID1234-5678 from/2023-12-27 to/2023-12-27` : Deletes leave date 27 December 2023 for employee with id EID1234-5678. - * `editleave id/EID1234-5678 old/2023-12-26 new/2023-12-29`: Edits the old leave date on 26 December 2023 of employee with id EID1234-5678 to new leave date on 29 December 2023. + * `editleave id/EID1234-5678 old/2023-12-26 new/2023-12-29` : Edits the old leave date on 26 December 2023 of employee with id EID1234-5678 to new leave date on 29 December 2023. - * `listleave on/2023-12-28`: Lists all employees on leave on 28 December 2023. + * `listleave on/2023-12-28` : Lists all employees on leave on 28 December 2023. - * `addremark id/EID1234-5678 r/good worker`: Adds the remark `good worker` to the employee with id EID1234-6788. + * `addremark id/EID1234-5678 r/good worker` : Adds the remark `good worker` to the employee with id EID1234-6788. - * `deleteremark id/EID1234-5678 r/good worker`: Deletes the remark `good worker` from the employee with id EID1234-5678. + * `deleteremark id/EID1234-5678 r/good worker` : Deletes the remark `good worker` from the employee with id EID1234-5678. - * `overtime id/EID1234-5678 o/inc a/10`: Increases the overtime hours of employee with id EID1234-5678 by 10 hours. + * `overtime id/EID1234-5678 o/inc a/10` : Increases the overtime hours of employee with id EID1234-5678 by 10 hours. - * `report EID1234-5678`: Generates a report with details of the employee with id EID1234-5678. + * `report EID1234-5678` : Generates a report with details of the employee with id EID1234-5678. - * `reset f/overtime`: Resets the overtime hours field of all employees to the default value 0. + * `reset f/overtime` : Resets the overtime hours field of all employees to the default value 0. * `clear` : Deletes all employees. @@ -143,9 +144,9 @@ Performing these instructions may result in non-deterministic behaviour of data -------------------------------------------------------------------------------------------------------------------- -## Navigating the Graphical User Interface (GUI) +## Navigating the GUI -HouR comes with a GUI to allow for nice visual feedback for our users. Here is a quick run-through of the different sections of our GUI, as well as some notes regarding the use of the GUI. +HouR comes with a Graphical User Interface (GUI) to allow for nice visual feedback for our users. Here is a quick run-through of the different sections of our GUI, as well as some notes regarding the use of the GUI. ### Quick Orientation @@ -182,6 +183,8 @@ Below is an overview of HouR's features. - Clear all employees: `clear` - Exit the program: `exit` + +
**:information_source: Notes about the command format and commands**
@@ -212,6 +215,8 @@ Below is an overview of HouR's features. * If you are using a PDF version of this document, be careful when copying and pasting commands that span multiple lines as space characters surrounding line-breaks may be omitted when copied over to the application.
+
+
## General Commands
This section contains commands that are not related to any specific feature in HouR.
@@ -250,7 +255,7 @@ Format: `exit`
This section contains commands relating to the employee list and/or employees.
-### Adding an employee: `add`
+### Adding an employee : `add`
Adds an employee to the employee list.
@@ -318,7 +323,7 @@ Format: `list`
-### Finding employees: `find`
+### Finding employees : `find`
Finds employees whose name, position, department, phone number, email, or ID contain any of the given keywords.
@@ -364,7 +369,7 @@ Examples:
You can use the following commands to keep track of employee metrics and gauge employee performance.
-### Adding a leave period of an employee: `addleave`
+### Adding a leave period of an employee : `addleave`
Adds the dates between a specified period of time to the leaves taken by the specified employee.
@@ -399,7 +404,7 @@ Examples:
-### Deleting a leave period of an employee: `deleteleave`
+### Deleting a leave period of an employee : `deleteleave`
Deletes the specified leave dates of an employee.
@@ -455,7 +460,7 @@ Conversely, if **NEW_DATE** is the current date, the **leave status** of the emp
Examples:
* `editleave id/EID1234-5678 old/2023-12-26 new/2023-12-28` edits the leave on 26 December 2023 to 28 December 2023
- for employee with id EID1234-5678. The old leave date is replaced by the new leave date in the leave list.
+ for employee with id EID1234-5678. The old leave date is **replaced** by the new leave date in the leave list.
@@ -577,6 +582,9 @@ Format: `report EMPLOYEE_ID`
+@@ -212,6 +215,8 @@ Below is an overview of HouR's features. * If you are using a PDF version of this document, be careful when copying and pasting commands that span multiple lines as space characters surrounding line-breaks may be omitted when copied over to the application.
:bulb: **Tip:**
+The remarks displayed in the report are arranged in the order they were added, i.e. remarks added later will be added to the end of the remark list.
+
Examples:
* `report EID1234-5678` generates and downloads a report for the employee with employee id EID1234-5678.
@@ -648,10 +656,10 @@ DO NOT modify data directly as it might result in the malfunction of the applica
**Method 2**: For users that wish to create a script to launch HouR (Recommended)
1. Create a new text file
2. Copy and paste the following into the text file: `java -jar [JAR file location]/hour.jar`
-3. Save the text file as `hour.bat` (Windows) or `hour.sh` (MacOS/Linux)
+3. Save the text file as `hour.bat` (Windows) or `hour.sh` (macOS/Linux)
4. Change the admin settings of the script to allow it to run as program:
* Windows: Right-click on the script and select **Properties**. Under **General**, check the box that says `Allow this file to run as a program`.
- * MacOS/Linux: Open the Terminal and navigate to the directory where the script is located. Type `chmod +x [script name]` and press Enter.+ * macOS/Linux: Open the Terminal and navigate to the directory where the script is located. Type `chmod +x [script name]` and press Enter.
Note: (`chmod +x` changes permissions of the script to allow it to be executed) 5. Double-click on the script to launch HouR 6. HouR should launch @@ -663,7 +671,7 @@ If you have any further issues, please raise an issue on our [Github page](https **Q**: How can I check my Java version?
**A**: Open a Command Prompt and type `java -version`. If you do not have Java installed, you can install Java 11 using the Oracle guide [here](https://www.oracle.com/java/technologies/downloads/#java11). Alternatively, you can install the OpenJDK version. -For Mac users, you may wish to follow the instructions listed [here](https://nus-cs2103-ay2324s1.github.io/website/admin/programmingLanguages.html). +For macOS users, you may wish to follow the instructions listed [here](https://nus-cs2103-ay2324s1.github.io/website/admin/programmingLanguages.html). ### Loading Data from Another Computer @@ -755,7 +763,7 @@ If you would like to reset the number of leaves or overtime hours for **a specif ## Parameter information -The table below provides information on the usage of the allowed parameters in HouR. Do note that the examples given are not exhaustive +The table below provides information on the usage of the allowed parameters in HouR. Do note that the examples given are not exhaustive. | Parameter, Description | Case sensitive | Constraints | Valid Examples | Invalid Examples | |---------------------------------------------------------------|----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|----------------------------------------------------------| diff --git a/docs/diagrams/AddActivityDiagram.puml b/docs/diagrams/AddActivityDiagram.puml index 9401facf190..87c2b824441 100644 --- a/docs/diagrams/AddActivityDiagram.puml +++ b/docs/diagrams/AddActivityDiagram.puml @@ -5,37 +5,18 @@ start :User inputs add command; if () then ([else]) - :Display error message; +:Display error message; else ([Valid command format]) - if () then ([else]) - :Display error message; - else ([Valid and unique employee ID]) - if () then ([else]) - :Display error message; - else ([Valid name]) - if () then ([else]) - :Display error message; - else ([Valid position]) - if () then ([else]) - :Display error message; - else ([Valid email]) - if () then ([else]) - :Display error message; - else ([Valid phone number]) - if () then ([else]) - :Display error message; - else ([Valid salary]) - if () then ([else]) - :Display error message; - else ([Valid department(s) if present]) - :Add employee to employee list; - :Display success message; - endif - endif - endif - endif - endif - endif +if () then ([else]) +:Display error message; +else ([Valid and unique employee ID]) +if () then ([else]) +:Display error message; +else ([Valid employee fields]) + +:Add employee to employee list; +:Display success message; +endif endif endif stop diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml index 48b6cc4333c..c4a64c8b45f 100644 --- a/docs/diagrams/ArchitectureSequenceDiagram.puml +++ b/docs/diagrams/ArchitectureSequenceDiagram.puml @@ -8,13 +8,13 @@ Participant ":Logic" as logic LOGIC_COLOR Participant ":Model" as model MODEL_COLOR Participant ":Storage" as storage STORAGE_COLOR -user -[USER_COLOR]> ui : "delete 1" +user -[USER_COLOR]> ui : "delete EID1234-5678" activate ui UI_COLOR -ui -[UI_COLOR]> logic : execute("delete 1") +ui -[UI_COLOR]> logic : execute("delete EID1234-5678") activate logic LOGIC_COLOR -logic -[LOGIC_COLOR]> model : deletePerson(p) +logic -[LOGIC_COLOR]> model : deleteEmployee(p) activate model MODEL_COLOR model -[MODEL_COLOR]-> logic diff --git a/docs/diagrams/BetterModelClassDiagram.puml b/docs/diagrams/BetterModelClassDiagram.puml index 598474a5c82..7482db717a9 100644 --- a/docs/diagrams/BetterModelClassDiagram.puml +++ b/docs/diagrams/BetterModelClassDiagram.puml @@ -4,18 +4,23 @@ skinparam arrowThickness 1.1 skinparam arrowColor MODEL_COLOR skinparam classBackgroundColor MODEL_COLOR -AddressBook *-right-> "1" UniquePersonList -AddressBook *-right-> "1" UniqueTagList -UniqueTagList -[hidden]down- UniquePersonList -UniqueTagList -[hidden]down- UniquePersonList +AddressBook *-right-> "1" UniqueEmployeeList +AddressBook *-right-> "1" UniqueDepartmentList +UniqueDepartmentList -[hidden]down- UniqueEmployeeList +UniqueDepartmentList -[hidden]down- UniqueEmployeeList -UniqueTagList -right-> "*" Tag -UniquePersonList -right-> Person +UniqueDepartmentList -right-> "*" Department +UniqueEmployeeList -right-> Employee -Person -up-> "*" Tag +Employee -up-> "*" Department -Person *--> Name -Person *--> Phone -Person *--> Email -Person *--> Address +Employee *--> Name +Employee *--> Position +Employee *--> Id +Employee *--> Phone +Employee *--> Email +Employee *--> Salary +Employee *--> LeaveList +Employee *--> OvertimeHours +Employee *--> RemarkList @enduml diff --git a/docs/diagrams/ModelClassDiagram.puml b/docs/diagrams/ModelClassDiagram.puml index 0de5673070d..33af1e41358 100644 --- a/docs/diagrams/ModelClassDiagram.puml +++ b/docs/diagrams/ModelClassDiagram.puml @@ -12,13 +12,18 @@ Class AddressBook Class ModelManager Class UserPrefs -Class UniquePersonList -Class Person -Class Address +Class UniqueEmployeeList +Class Employee +Class Id Class Email Class Name Class Phone -Class Tag +Class Position +Class Salary +Class LeaveList +Class OvertimeHours +Class RemarkList +Class Department Class I #FFFFFF } @@ -35,20 +40,25 @@ ModelManager -left-> "1" AddressBook ModelManager -right-> "1" UserPrefs UserPrefs .up.|> ReadOnlyUserPrefs -AddressBook *--> "1" UniquePersonList -UniquePersonList --> "~* all" Person -Person *--> Name -Person *--> Phone -Person *--> Email -Person *--> Address -Person *--> "*" Tag +AddressBook *--> "1" UniqueEmployeeList +UniqueEmployeeList --> "~* all" Employee +Employee *--> Name +Employee *--> Phone +Employee *--> Email +Employee *--> Id +Employee *--> Position +Employee *--> Salary +Employee *--> LeaveList +Employee *--> OvertimeHours +Employee *--> RemarkList +Employee *--> "*" Department -Person -[hidden]up--> I -UniquePersonList -[hidden]right-> I +Employee -[hidden]up--> I +UniqueEmployeeList -[hidden]right-> I -Name -[hidden]right-> Phone -Phone -[hidden]right-> Address -Address -[hidden]right-> Email +Name -[hidden]right-> Position +Id -[hidden]right-> Phone +Phone -[hidden]right-> Email -ModelManager --> "~* filtered" Person +ModelManager --> "~* filtered" Employee @enduml diff --git a/docs/diagrams/OvertimeActivityDiagram.puml b/docs/diagrams/OvertimeActivityDiagram.puml new file mode 100644 index 00000000000..03d5f47c55e --- /dev/null +++ b/docs/diagrams/OvertimeActivityDiagram.puml @@ -0,0 +1,24 @@ +@startuml +'https://plantuml.com/activity-diagram-beta + +start +:User inputs overtime command; + +if () then ([else]) + :Display error message; +else ([valid command]) + if () then ([else]) + :Display error message; + else ([valid ID]) + if () then ([else]) + :Display error message; + else ([valid operation]) + if () then ([else]) + :Display error message; + else ([valid amount]) + :Update employee's overtime hours; + :Display overtime success message; + endif + endif + +@enduml diff --git a/docs/diagrams/OvertimeSequenceDiagram.puml b/docs/diagrams/OvertimeSequenceDiagram.puml new file mode 100644 index 00000000000..71fb1cda00d --- /dev/null +++ b/docs/diagrams/OvertimeSequenceDiagram.puml @@ -0,0 +1,72 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR +participant ":OvertimeCommandParser" as OvertimeCommandParser LOGIC_COLOR +participant "r:OvertimeCommand" as OvertimeCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":Model" as Model MODEL_COLOR +end box +[-> LogicManager : execute("overtime id/EID1234-5678 o/inc a/2") +activate LogicManager + +LogicManager -> AddressBookParser : parseCommand("overtime id/EID1234-5678 o/inc a/2") +activate AddressBookParser + +create OvertimeCommandParser +AddressBookParser -> OvertimeCommandParser +activate OvertimeCommandParser + +OvertimeCommandParser --> AddressBookParser +deactivate OvertimeCommandParser + +AddressBookParser -> OvertimeCommandParser : parse("overtime id/EID1234-5678 o/inc a/2") +activate OvertimeCommandParser + +create OvertimeCommand +OvertimeCommandParser -> OvertimeCommand +activate OvertimeCommand + +OvertimeCommand --> OvertimeCommandParser : r +deactivate OvertimeCommand + +OvertimeCommandParser --> AddressBookParser : r +deactivate OvertimeCommandParser + +OvertimeCommandParser -[hidden]-> AddressBookParser +destroy OvertimeCommandParser + +AddressBookParser --> LogicManager : r +deactivate AddressBookParser + +LogicManager -> OvertimeCommand : execute() +activate OvertimeCommand + +OvertimeCommand -> Model : setEmployee(employeeToUpdate, updatedEmployee) +activate Model + +Model --> OvertimeCommand + +OvertimeCommand -> Model : updateFilteredEmployeeList() + +Model --> OvertimeCommand +deactivate Model + +create CommandResult +OvertimeCommand -> CommandResult +activate CommandResult + +CommandResult --> OvertimeCommand +deactivate CommandResult + +OvertimeCommand --> LogicManager : result +deactivate OvertimeCommand + +[<--LogicManager +deactivate LogicManager +@enduml diff --git a/docs/diagrams/SortSequenceDiagram.puml b/docs/diagrams/SortSequenceDiagram.puml index ccbfdb4c80e..16e29aed142 100644 --- a/docs/diagrams/SortSequenceDiagram.puml +++ b/docs/diagrams/SortSequenceDiagram.puml @@ -11,8 +11,6 @@ end box box Model MODEL_COLOR_T1 participant ":Model" as Model MODEL_COLOR -participant ":AddressBook" as AddressBook MODEL_COLOR -participant ":UniqueEmployeeList" as UniqueEmployeeList MODEL_COLOR end box [-> LogicManager : execute("sort f/salary in/asc") activate LogicManager @@ -49,27 +47,9 @@ deactivate AddressBookParser LogicManager -> SortCommand : execute() activate SortCommand -SortCommand -> SortCommand : handleSortingOrder(model, "salary", "asc") -activate SortCommand - -SortCommand --> SortCommand -deactivate SortCommand - SortCommand -> Model : updateSortedEmployeeListAscending("salary"); activate Model -Model -> AddressBook : updateSortedEmployeeListAscending("salary") -activate AddressBook - -AddressBook -> UniqueEmployeeList : sortEmployeesAscending("salary"); -activate UniqueEmployeeList - -UniqueEmployeeList --> AddressBook -deactivate UniqueEmployeeList - -AddressBook --> Model -deactivate AddressBook - Model --> SortCommand deactivate Model diff --git a/docs/diagrams/StorageClassDiagram.puml b/docs/diagrams/StorageClassDiagram.puml index a821e06458c..754f6211858 100644 --- a/docs/diagrams/StorageClassDiagram.puml +++ b/docs/diagrams/StorageClassDiagram.puml @@ -18,8 +18,10 @@ package "AddressBook Storage" #F4F6F6{ Class "<