-
-As visible, an incorrect input by the user can result in the following types of errors depending on the type of mistake:
-- **Command word is incorrect**: informs the user that command word is unowkown.
-- **Missing required field arguments**: informs the user of invalid command format.
-- **Invalid field arguments**: highlights to the user that invalid field arguments were provided.
-- **`Patient`/`Doctor` with corresponding attributes already exists in the system**: informs the user that `Patient`/`Doctor` already exists in the system.
-
-
-#### Incorrect user input handling process for the `Appointment` class
-The activity diagram below demonstrates this incorrect input handling process of a command that operates on the `Appointment` class.
-Specifically, we look at the process of adding an `Appointment` to MediCLI i.e. `addappt` command, potential mistakes that the user might make, and how they are handled by MediCLI.
-
-
-
-As visible, an incorrect input by the user can result in the following types of errors depending on the type of mistake:
-- **Command word is incorrect**: informs the user that command word is unowkown
-- **Missing required field arguments**: informs the user of invalid command format
-- **Invalid field arguments**: highlights to the user that invalid field arguments were provided
-- **`Patient`/`Doctor` involved in the `Appointment` does not exist in MediCLI**: informs the user that `Patient`/`Doctor` involved are not registered
-- **Provided date & time of the `Appointment` is in the past**: informs the user that appointments cannot be scheduled in the past.
-- **`Appointment` with corresponding attributes already exists in MediCLI**: informs the user that `Appointment` already exists
-
-
-
-### Add a `Patient` or `Doctor`
+#### Add Functionality
Note: Add `patient` and `doctor` has been grouped together as they are very similar in implementation.
This reduces repetition of information and increases clarity.
Adds a new `Patient` or `Doctor` entry by indicating their `NRIC`, `Name`, `DoB`, and `Phone`.
This command is implemented through the `AddPatientCommand` for patient and `AddDoctorCommand` for doctor class which both extend the `Command` class.
-The activity diagram below demonstrates the error handling process in more detail.
-
-
-
-The sequence diagram below demonstrates the command execution steps for `execute` method in `AddpatientCommand`.
-
-
-
-This is the sequence of command execution for `execute` in `AddPatientCommand`, however `AddDoctorCommand` and `AddAppointmentCommand` follow similar design patterns within the execute command.
Add command execution sequence:
* Step 1. The `execute` method of the `AddPatientCommand` is called.
* Step 2. The method calls the `hasPerson` method of `Model` to check if there are any duplicate patients.
- * If there is a duplicate person, the method throws `CommandException` and calls the `log` method of `logger` to log the incident.
+ * If there is a duplicate person, the method throws `CommandException` and calls the `log` method of `logger` to log the incident.
* Step 3. The `addPerson` method of `Model` is then called and the control is passed back to the `execute` method.
* Step 4. The `log` method of `logger` is then called to log the successful command execution.
* Step 5. A new `CommandResult` object with the success message is then created and returned by `execute`.
-#### Design considerations:
-
-**Aspect: How editing a Person works:**
-
-* **Alternative 1 (current choice):** Removes the `originalPerson` and adds the `editedPerson`.
- * Pros: Retains the sorted order of Persons by `Name` in the person list.
- * Cons: May have performance issues in terms of time complexity since it requires 2 operations (`deletePerson()` and `addPerson`).
-
-* **Alternative 2:** Directly update the fields in the `originalPerson`
- * Pros: Better performance, since this only requires searching through the person list once.
- * Cons: The order of person list will be lost, since `Name` of a `Person` may be edited.
-
+This is the sequence of command execution for `execute` in `AddPatientCommand`, however `AddDoctorCommand` and `AddAppointmentCommand` follow similar design patterns within the execute command.
+
-### Edit `doctor` or `patient`
+#### Edit Functionality
Edits a `doctor` or `patient` entry by indicating their `Index`.
This command is implemented through the `EditCommand` class which extends the `Command` class.
-The activity diagram below demonstrates the error handling process in more detail.
-
-
-
-The sequence diagram below demonstrates the command execution steps for `execute` method in `EditCommand`.
-
-
-
This is the sequence of command execution for `execute` in `EditCommand`, however `EditAppointmentCommand` follow a similar design pattern within the `execute` command.
* Step 1. The `execute` method of the `EditCommand` is called.
* Step 2. The method calls the `getFilteredPersonList` method of `Model` and returns the list.
* Step 3. The command checks whether the index of the command is valid by comparing the value returned by the `getZeroBased` method of `index` to the size of the list.
- * If the index is invalid, the command throws `CommandException`.
+ * If the index is invalid, the command throws `CommandException`.
* Step 4. The `createEditedPerson` method is called and returns a new edited person.
* Step 5. The method calls the `hasPerson` method of `Model` to check if there are any duplicate persons.
- * If there are duplicates, the command throws `CommandException`.
+ * If there are duplicates, the command throws `CommandException`.
* Step 6. The `setPerson` method of `Model` is called and control is then passed back to the `execute` method.
* Step 7. The `updateFilteredPersonList` method of `Model` is called to update the list.
* Step 8. A new `CommandResult` with the success message is then created and returned by `execute`.
+The sequence diagram below demonstrates the command execution steps for `execute` method in `EditCommand`.
+
+
+
+#### Querying Functionality
+This section describes the general sequence for commands that query entities. MediCLI has 5 different commands that serve this function: `find`, `patient`, `doctor`, `apptforpatient` and `apptfordoctor`.
+Although this section describes only the `patient` command, each of the other commands, while lined with different predicates and have different requirements for their parameters, possesses similar implementation. Hence, the flow of method calls between classes are generally similar, and all 5 commands that query entities are described here together in one section.
+
+* Step 1. The `execute()` method is called in an instance of `QueryPatientCommand`.
+* Step 2. The instance of `QueryPatientCommand` calls the `updateFilteredPersonList()` method with the `PatientContainsKeywordsPredicate` in an instance of the `Model` class, which filters out entries and returns only patients that match the keywords entered. Note that the other commands listed here will have their respective `predicate` requirements and implementations.
+* Step 3. Control is passed to an instance of the `Logger` class, which calls the method `log()` to log a "Success" message.
+* Step 4. The instance of `QueryPatientCommand` calls the constructor method of the `CommandResult` class, which returns the final result.
+* Step 5. Control is returned to the caller with the final result.
+
+The sequence diagram below describes the interaction between the various components during the `execute` method of the `patient` command, which uses the `QueryPatientCommand` on the backend.
+
+
+
Why is this implemented this way?
-1. Making both `Doctor` and `Patient` class extend the `Person` class makes it easier to execute edit operations.
-2. `Doctor` and `Patient` all exhibit similar qualities, and thus can inherit from the `Person` superclass.
-3. Eliminates the need for separate edit commands for doctor and patient.
-4. Since appointments are constructed with unique `Person` `Nric` fields, it does not make sense to have an appointment that does not have valid or outdated doctor or patient entries.
-5. As such, the solution that is inbuilt to editing a `Person`, comes with the added functionality on the backend to augment all related `Appointment` entries as well.
-6. This results in an updated `Appointments` panel, and saves the user from the hassle of needing to manually edit outdated `Appointment` entries one by one.
+1. All query command closely resembles the structure of the `find` command. Each of the commands here have either stricter (i.e have stricter parameter requirements e.g `apptforpatient` and `apptfordoctor`) or looser (i.e searching for more fields e.g `patient` and `doctor`) predicates, but all generally have the same flow of control between the `Command`, `Logger` and `Model` classes.
+2. Conceptually, each of the 5 commands listed here are searching for different entities, and are hence split into separate commands despite having very similar structures.
-### Delete `doctor` or `patient`
+Alternative implementations considered
+1. The behaviour of `patient` and `doctor`, `apptforpatient` and `apptfordoctor` have similar requirements in terms of parameters, with the main difference being either `patient` or `doctor` typed classes. We might consider combining each pair into one command, and using flags to distinguish the desired class (e.g a -doctor or -patient flag to indicate we wish to search for only `doctor` and `patient` entries respectively) so as to avoid the need to create additional commands. However, we felt that at the time of implementation, separating the commands would be a cleaner strategy, and combining methods might overcomplicate the implementation.
+2. Even if we did proceed with combining, the combined command was to be overloaded with flags, we foresaw that the creation of distinct commands to fit the flags parsed were unavoidable. As such, it was prudent to start with the implementation of the distinct commands first, and leave the possibility of combining as a later increment.
+
+#### Delete Functionality
Deletes a `doctor` or `patient` entry by indicating their `Index`.
This command is implemented through the `DeleteCommand` class which extends the `Command` class.
@@ -319,7 +292,7 @@ This command is implemented through the `DeleteCommand` class which extends the
* Step 2. The `getFilteredPersonList` method of `Model` is called and finds its length.
* Step 3. The `getZeroBased` method of `Index` is called to convert the provided index to its zero-based equivalent.
* Step 4. The provided index is checked against the length of the current list of people.
- * If the provided index is out of bounds, a `CommandException` is thrown.
+ * If the provided index is out of bounds, a `CommandException` is thrown.
* Step 4. The `deletePerson` method of `Model` is called to remove the designated person from the list of people.
* Step 5. An instance of `CommandResult` is created with a success message for the execution of `DeleteCommand`.
* Step 6. The instance of `CommandResult` is returned.
@@ -328,131 +301,35 @@ The sequence diagram below closely describes the interaction between the various
+### Incorrect user input handling process
+In this section, we will use the _add_ commands for `patients`/`doctors` and `appointments` to demonstrate how MediCLI handles incorrect inputs from the user.
-Why is this implemented this way?
-1. Making both `Doctor` and `Patient` class extend the `Person` class makes it easier to execute delete operations.
-2. `Doctor` and `Patient` all exhibit similar qualities, and thus can inherit from the `Person` superclass.
-3. Eliminates the need for separate delete commands for doctor and patient.
-4. Since appointments are constructed with unique `Person` `Nric` fields, it does not make sense to have an appointment that does not have valid doctor or patient entries.
-5. As such, the solution that is inbuilt to deleting a `Person`, comes with the added functionality on the backend to delete all related `Appointment` entries as well.
-6. This results in a cleaner `Appointments` panel, and saves the user from the hassle of needing to delete unwanted `Appointment` entries one by one.
-
-
-### Add a `Appointment`
-
-Adds a new `Appointment` entry by indicating the `patientNric`, `doctorNric`, and an `appointmentDateTime`.
-The values stored in each of these attributes are self-explanatory. A key thing to note is that a `Patients` /`Doctor` with the NRIC number must already exist in the records, and the date & time must be in the future.
-
-This command is implemented through the `AddAppointmentCommand` class which extend the `Command` class.
-
-* Step 1. User enters the keyword and attributes necessary for adding an appointment as indicated above.
-* Step 2. The `AddressBookParser` will call `parseCommand` on the user's input string and return an instance of `addAppointmentCommandParser`.
-* Step 3. The `parse` command in `addPatientCommandParser` calls `ParserUtil` to create instances of objects for each of the fields.
- * If there are any missing fields, a `CommandException` is thrown.
- * If input arguments does not match constraints for the fields, a `IllegalArgumentException` is thrown.
-* Step 4. The `parse` command in `addAppointmentCommandParser` return an instance of `addAppointmentCommand`.
-* Step 5. The `LogicManager` calls the `execute` method in `addAppointmentCommand`.
-* Step 6. The `execute` method in `addAppointmentCommand` performs the following checks:
- * If a `Doctor`/`Patient` with the Nric in question not exist or the date & time is not >= current date & time, a `InvalidAppointmentException` is thrown
- * If an appointment between the `Doctor` and `Patient` (with corresponding NRICs) on the specified date & time already exists, then a `DuplicateAppointmentException` is thrown.
-* Step 7: If both the checks above pass, the `execute` method executes and calls `addAppointment` in model to add the new appointment into the system.
-* Step 8: Success message gets printed onto the results display to notify user.
-
-The activity diagram below demonstrates this error handling process in more detail.
-
-
-### Edit `Appointment`
-Edits an `Appointment` entry by indicating their `Index`.
-This command is implemented through the `EditAppointmentCommand` class which extends the `Command` class.
-
-* Step 1. User enters an `edi`tappt` command.
-* Step 2. The `AddressBookParser` will call `parseCommand` on the user's input string and return an instance of `editAppointmentCommandParser`.
-* Step 3. The `parse` command in `editAppointmentCommandParser` calls `ParserUtil` to create instances of objects for each of the fields.
- * If there are any missing fields, a `CommandException` is thrown.
- * If input arguments does not match contraints for the fields, a `IllegalArgumentException` is thrown.
- * If the provided `index` is invalid, a `CommandException` is thrown.
-
-The activity diagram below demonstrates this error handling process in more detail.
-
-
-
-* Step 4. The `parse` command in `editAppointmentCommandParser` returns an instance of `editAppointmentCommand`.
-* Step 5. The `LogicManager` calls the `execute` method in `editAppointmentCommand`.
-* Step 6. The `execute` method in `editAppointmentCommand` executes and calls `setAppointment` in model to set an updated appointment into the system.
-* Step 7. Success message gets printed onto the results display to notify user.
-
-The sequence diagram below closely describes the interaction between the various components during the execution of the `EditAppointmentCommand`.
-
-
-
-Why is this implemented this way?
-1. The `Appointment` class has very similar functionalities to that of the `Person` class, in which both classes deal with edit operations.
-2. Furthermore on the UI, the `Appointment` column runs parallel to the `Person` column, as such, the behaviours (UX) of operating on the `Person` panel should have a similar feel and experience when dealing with `Appointment` objects.
-3. This parallelism is also reflected in the backend code, and hence is very similar to how editing a `Person` is implemented - this is mostly seen through the naming conventions of the classes related to `EditPerson`, such as `EditAppointment`
-4. This results in a more familiar experience for both users and developers alike as there is familiarity and some level of consistency when dealing with `Person` and `Appointment` classes.
-
-Alternative implementation for consideration
-1. Since both classes exhibit similarities in both code structure and behaviour, we might consider creating a generic class distinguished between `Person` and `Appointment` via enums to handle edits.
-2. This will centralise the behaviours, and reduce the amount of code needed to perform the edit function.
-3. A further extension is to do so with all other overlapping functionalities, such as `add` or `delete`, however we leave that possibility for future discussion and refinement.
-
-### Delete `Appointment`
-Deletes an `Appointment` entry by indicating their `Index`.
-This command is implemented through the `DeleteAppointmentCommand` class which extend the `Command` class.
-
-* Step 1. User enters an `deleteappt` command.
-* Step 2. The `AddressBookParser` will call `parseCommand` on the user's input string and return an instance of `deleteAppointmentCommandParser`.
-* Step 3. The `parse` command in `deleteAppointmentCommandParser` calls `ParserUtil` to create instances of objects for each of the fields.
- * If there are any missing fields, a `CommandException` is thrown.
- * If input arguments does not match contraints for the fields, a `IllegalArgumentException` is thrown.
- * If the provided `index` is invalid, a `CommandException` is thrown.
-
-The activity diagram below demonstrates this error handling process in more detail.
-
-
-
-* Step 4. The `parse` command in `deleteAppointmentCommandParser` return an instance of `deleteAppointmentCommand`.
-* Step 5. The `LogicManager` calls the `execute` method in `deleteAppointmentCommand`.
-* Step 6. The `execute` method in `deleteAppointmentCommand` executes and calls `deleteAppointment` in model to remove appointment from the system.
-* Step 7. Success message gets printed onto the results display to notify user.
-
-The sequence diagram below closely describes the interaction between the various components during the execution of the `DeleteAppointmentCommand`.
-
-
-
-Why is this implemented this way?
-1. The `Appointment` class has very similar functionalities to that of the `Person` class, in which both classes deal with deletion operations.
-2. Furthermore on the UI, the `Appointment` column runs parallel to the `Person` column, as such, the behaviours (UX) of operating on the `Person` panel should have a similar feel and experience when dealing with `Appointment` objects.
-3. This parallelism is also reflected in the backend code, and hence is very similar to how deleting a `Person` is implemented - this is mostly seen through the naming conventions of the classes related to `DeletePerson`, such as `DeleteAppointment`
-4. This results in a more familiar experience for both users and developers alike as there is familiarity and some level of consistency when dealing with `Person` and `Appointment` classes.
-
-Alternative implementation for consideration
-1. Since both classes exhibit similarities in both code structure and behaviour, we might consider creating a generic class distinguished between `Person` and `Appointment` via enums to handle deletions.
-2. This will centralise the behaviours, and reduce the amount of code needed to perform the delete function.
-3. A further extension is to do so with all other overlapping functionalities, such as `add` or `edit`, however we leave that possibility for future discussion and refinement.
-
-### Querying Entities in MediCLI `patient`, `doctor`, `appointment`
-This section describes the general sequence for commands that query entities. MediCLI has 5 different commands that serve this function: `find`, `patient`, `doctor`, `apptforpatient` and `apptfordoctor`.
-Although this section describes only the `patient` command, each of the other commands, while lined with different predicates and have different requirements for their parameters, possesses similar implementation. Hence, the flow of method calls between classes are generally similar, and all 5 commands that query entities are described here together in one section.
+#### Incorrect input handling process for commands that involve operations on the `Person` class
+The activity diagram below demonstrates this incorrect input handling process of a command that operates on the `Person` class.
+Specifically, we look at the process of adding a `Person` to MediCLI i.e. `addpatient` or `adddoctor` commands, potential mistakes that the user might make, and how they are handled by MediCLI.
-* Step 1. The `execute()` method is called in an instance of `QueryPatientCommand`.
-* Step 2. The instance of `QueryPatientCommand` calls the `updateFilteredPersonList()` method with the `PatientContainsKeywordsPredicate` in an instance of the `Model` class, which filters out entries and returns only patients that match the keywords entered. Note that the other commands listed here will have their respective `predicate` requirements and implementations.
-* Step 3. Control is passed to an instance of the `Logger` class, which calls the method `log()` to log a "Success" message.
-* Step 4. The instance of `QueryPatientCommand` calls the constructor method of the `CommandResult` class, which returns the final result.
-* Step 5. Control is returned to the caller with the final result.
+
-The sequence diagram below describes the interaction between the various components during the `execute` method of the `patient` command, which uses the `QueryPatientCommand` on the backend.
+As visible, an incorrect input by the user can result in the following types of errors depending on the type of mistake:
+- **Command word is incorrect**: informs the user that command word is unowkown.
+- **Missing required field arguments**: informs the user of invalid command format.
+- **Invalid field arguments**: highlights to the user that invalid field arguments were provided.
+- **`Patient`/`Doctor` with corresponding attributes already exists in the system**: informs the user that `Patient`/`Doctor` already exists in the system.
-
-Why is this implemented this way?
-1. All query command closely resembles the structure of the `find` command. Each of the commands here have either stricter (i.e have stricter parameter requirements e.g `apptforpatient` and `apptfordoctor`) or looser (i.e searching for more fields e.g `patient` and `doctor`) predicates, but all generally have the same flow of control between the `Command`, `Logger` and `Model` classes.
-2. Conceptually, each of the 5 commands listed here are searching for different entities, and are hence split into separate commands despite having very similar structures.
+#### Incorrect user input handling process for the `Appointment` class
+The activity diagram below demonstrates this incorrect input handling process of a command that operates on the `Appointment` class.
+Specifically, we look at the process of adding an `Appointment` to MediCLI i.e. `addappt` command, potential mistakes that the user might make, and how they are handled by MediCLI.
-Alternative implementations considered
-1. The behaviour of `patient` and `doctor`, `apptforpatient` and `apptfordoctor` have similar requirements in terms of parameters, with the main difference being either `patient` or `doctor` typed classes. We might consider combining each pair into one command, and using flags to distinguish the desired class (e.g a -doctor or -patient flag to indicate we wish to search for only `doctor` and `patient` entries respectively) so as to avoid the need to create additional commands. However, we felt that at the time of implementation, separating the commands would be a cleaner strategy, and combining methods might overcomplicate the implementation.
-2. Even if we did proceed with combining, the combined command was to be overloaded with flags, we foresaw that the creation of distinct commands to fit the flags parsed were unavoidable. As such, it was prudent to start with the implementation of the distinct commands first, and leave the possibility of combining as a later increment.
+
+As visible, an incorrect input by the user can result in the following types of errors depending on the type of mistake:
+- **Command word is incorrect**: informs the user that command word is unowkown
+- **Missing required field arguments**: informs the user of invalid command format
+- **Invalid field arguments**: highlights to the user that invalid field arguments were provided
+- **`Patient`/`Doctor` involved in the `Appointment` does not exist in MediCLI**: informs the user that `Patient`/`Doctor` involved are not registered
+- **Provided date & time of the `Appointment` is in the past**: informs the user that appointments cannot be scheduled in the past.
+- **`Appointment` with corresponding attributes already exists in MediCLI**: informs the user that `Appointment` already exists
### \[Proposed\] Undo/redo feature
@@ -581,90 +458,6 @@ The following activity diagram summarizes what happens when a user executes a ne
* Cons: We must ensure that the implementation of each individual command are correct.
-## Planned Enhancements
-
-The MediCLI development team (consisting of 5 members) acknowledges the presense of known feature flaws in our system.
-Thus, we have planned the following 10 enhancements to be added in the near future.
-Please find them organised into their respective categories.
-
-### Appointment Functionality Enhancements
-
-1
. Adding an end time to appointments - -Currently, the MediCLI system only stores the date and start time of an appointment. -However, we recognise that in a fast-paced environment like a hospital, it'd be beneficial to also be able to indicate an end time for appointments. -This is so that the doctor can be safely booked by another patient without worrying about potential clashes in appointment timings. -* Updated Command Format - `addappt sdt/STARTDATETIME [edt/ENDDATETIME] dn/DOCTORNRIC pn/PATIENTNRIC` -* Example Input - `addappt sdt/2024-05-20 10:00 edt/2024-05-20 11:00 dn/S1234567A pn/S1234567B` - -2
. More robust appointment timing validation. - -Currently, the MediCLI system allows two appointments with the same doctor/patient and date-time to be simultaneously stored in the system. -However, it is clearly impossible for a patient or doctor to attend two different appointments at the same time. -Thus, we plan to implement a more robust appointment validation system to ensure that appointments with clashing or unrealistic timings can not be entered. - -3
. Marking old appointments as completed. - -Even though the MediCLI system does not allow appointments to be made in the future, it nonetheless retains entry of completed appointments. -However, there is currently no visual distinction between future, completed, and missed appointments. This can be rather confusing for the hospital clerks. -Thus, we plan to add a label (just like the patient/doctor labels) in the top right corner of each appointment card to help better distinguish them. -* New Command Format - `markappt index s/STATUS` (`STATUS` can be any one of {`completed`, `missed`}) -* Example Input - `markappt 1 s/completed` -* Example Input - `markappt 2 s/missed` - -### Parameter Checking Enhancements - -4
. Accommodate names with symbols and/or special characters. - -The name parameter is currently restricted to just alphabetical characters and white-space. -However, we recognise the existence of names that contain symbols and other special characters. -In the future, we plan to implement a more accommodating constraint that allows UTF-8 characters instead. -This means that names of other languages will be accepted as well. - -5
. Allow foreign patients/doctors to be added to the system. - -The current constraints for the NRIC and phone number parameters reflect the Singaporean format. -However, we recognise that for foreign users, this can be rather limiting. -Thus, in the future, we plan on introducing more refined parameter checking that allows international NRIC and phone number formats. - -6
. Ensure each person being added to the system is unique. - -While the current MediCLI system already checks to ensure every person added is unique, it is only done by comparing the NRIC of the person. -However, this should not be the only checking condition. Two entries with the same name, date of birth, and/or phone number should also be flagged as non-unique. -Thus, we will devise a more holistic assessment criterion to ensure no duplicates are allowed. - -### User Interface Enhancements - -7
. Refine the user interface when the window size is minimised. - -The current MediCLI system is not particularly flexible when it comes to window sizing. -Users on smaller screens may encounter the issue of scrolling being disabled or labels being truncated if a long name is entered. -In the future, we plan to make the UI more adaptive and friendly to smaller screens. - -8
Standardise displayed information. - -For certain fields, the MediCLI system simply displays the text exactly as entered by the user. -However, this can introduce inconsistencies in capitalisation (especially with the NRIC field) when displayed in the user interface. -We plan on standardising these fields by automatically capitalising the users' input. - -### Feature Enhancements - -9
. More advanced search options - -Currently, the `find`, `patient`, and `doctor` commands return all entries whose details contain any of the given keywords. -However, this implementation is not particularly effective if the user would like to search for a person that matches all the provided keywords exactly -(e.g. when searching for a person by full name). In the future, we plan to add more advanced search options to allow for easy querying of information. -* Updated Command Format - `find t/TYPE KEYWORD`, `patient t/TYPE KEYWORD`, `doctor t/TYPE KEYWORD` (`TYPE` can be any one of {`full`, `partial`}). -* Example Input - `find t/full John Doe` -* Example Input - `doctor t/partial Smith Li` - -10
. More detailed error messages. - -Some of the current error messages are not the most informative -(e.g. If two patient NRICs are provided when creating an appointment, the system only prompts `This appointment is invalid due to invalid inputs.`). -To decrease the learning curve for our system, we plan to replace all ambiguous error messages with more informative versions, e.g. `Please make sure the NRIC provided belongs to a person of the correct type as indicated by the prefix.`. - - -------------------------------------------------------------------------------------------------------------------- ## **Documentation, logging, testing, configuration, dev-ops** @@ -1232,7 +1025,8 @@ Invalid Inputs: Expected Error: * None -------------------------------------------------- +-------------------------------------------------------------------------------------------------------------------- + ## **Appendix: Effort** ### Difficulty level: @@ -1267,3 +1061,88 @@ Some achievements we are particulary proud of are: - UI improvements: We are quite happy with the way `Appointments` and `Patients`/`Doctors` are integrated into the same window to allow for easy visualisation with minimal use of the mouse. We are also quite proud of the new clean and minimalist interface which we think reflects a hospital setting quite well. - Variety of commands: We also are happy with the suite of commands that we offer to users. We focused on the most high-impact commands and ensured that our product offers all CRUD capabilities such that it may actually be used in a functional setting for a small clinic/hospital. - Comprehensive testing: While we do not claim to be bug-free, we did a comprehensive amount of testing including testing our product ourselves manually, through automated tests, and even asking other teams to perform their own UAT on our product to identify pain-points/bugs/feature flaws (that we went on to address). + +-------------------------------------------------------------------------------------------------------------------- + +## **Appendix: Planned Enhancements** + +The MediCLI development team (consisting of 5 members) acknowledges the presense of known feature flaws in our system. +Thus, we have planned the following 10 enhancements to be added in the near future. +Please find them organised into their respective categories. + +### Appointment Functionality Enhancements + +1. Adding an end time to appointments + +Currently, the MediCLI system only stores the date and start time of an appointment. +However, we recognise that in a fast-paced environment like a hospital, it'd be beneficial to also be able to indicate an end time for appointments. +This is so that the doctor can be safely booked by another patient without worrying about potential clashes in appointment timings. +* Updated Command Format - `addappt sdt/STARTDATETIME [edt/ENDDATETIME] dn/DOCTORNRIC pn/PATIENTNRIC` +* Example Input - `addappt sdt/2024-05-20 10:00 edt/2024-05-20 11:00 dn/S1234567A pn/S1234567B` + +2. More robust appointment timing validation. + +Currently, the MediCLI system allows two appointments with the same doctor/patient and date-time to be simultaneously stored in the system. +However, it is clearly impossible for a patient or doctor to attend two different appointments at the same time. +Thus, we plan to implement a more robust appointment validation system to ensure that appointments with clashing or unrealistic timings can not be entered. + +3. Marking old appointments as completed. + +Even though the MediCLI system does not allow appointments to be made in the future, it nonetheless retains entry of completed appointments. +However, there is currently no visual distinction between future, completed, and missed appointments. This can be rather confusing for the hospital clerks. +Thus, we plan to add a label (just like the patient/doctor labels) in the top right corner of each appointment card to help better distinguish them. +* New Command Format - `markappt index s/STATUS` (`STATUS` can be any one of {`completed`, `missed`}) +* Example Input - `markappt 1 s/completed` +* Example Input - `markappt 2 s/missed` + +### Parameter Checking Enhancements + +4. Accommodate names with symbols and/or special characters. + +The name parameter is currently restricted to just alphabetical characters and white-space. +However, we recognise the existence of names that contain symbols and other special characters. +In the future, we plan to implement a more accommodating constraint that allows UTF-8 characters instead. +This means that names of other languages will be accepted as well. + +5. Allow foreign patients/doctors to be added to the system. + +The current constraints for the NRIC and phone number parameters reflect the Singaporean format. +However, we recognise that for foreign users, this can be rather limiting. +Thus, in the future, we plan on introducing more refined parameter checking that allows international NRIC and phone number formats. + +6. Ensure each person being added to the system is unique. + +While the current MediCLI system already checks to ensure every person added is unique, it is only done by comparing the NRIC of the person. +However, this should not be the only checking condition. Two entries with the same name, date of birth, and/or phone number should also be flagged as non-unique. +Thus, we will devise a more holistic assessment criterion to ensure no duplicates are allowed. + +### User Interface Enhancements + +7. Refine the user interface when the window size is minimised. + +The current MediCLI system is not particularly flexible when it comes to window sizing. +Users on smaller screens may encounter the issue of scrolling being disabled or labels being truncated if a long name is entered. +In the future, we plan to make the UI more adaptive and friendly to smaller screens. + +8Standardise displayed information. + +For certain fields, the MediCLI system simply displays the text exactly as entered by the user. +However, this can introduce inconsistencies in capitalisation (especially with the NRIC field) when displayed in the user interface. +We plan on standardising these fields by automatically capitalising the users' input. + +### Feature Enhancements + +9. More advanced search options + +Currently, the `find`, `patient`, and `doctor` commands return all entries whose details contain any of the given keywords. +However, this implementation is not particularly effective if the user would like to search for a person that matches all the provided keywords exactly +(e.g. when searching for a person by full name). In the future, we plan to add more advanced search options to allow for easy querying of information. +* Updated Command Format - `find t/TYPE KEYWORD`, `patient t/TYPE KEYWORD`, `doctor t/TYPE KEYWORD` (`TYPE` can be any one of {`full`, `partial`}). +* Example Input - `find t/full John Doe` +* Example Input - `doctor t/partial Smith Li` + +10. More detailed error messages. + +Some of the current error messages are not the most informative +(e.g. If two patient NRICs are provided when creating an appointment, the system only prompts `This appointment is invalid due to invalid inputs.`). +To decrease the learning curve for our system, we plan to replace all ambiguous error messages with more informative versions, e.g. `Please make sure the NRIC provided belongs to a person of the correct type as indicated by the prefix.`. \ No newline at end of file diff --git a/docs/images/AddAppoiintmentActivityDiagram.png b/docs/images/AddAppointmentActivityDiagram.png similarity index 100% rename from docs/images/AddAppoiintmentActivityDiagram.png rename to docs/images/AddAppointmentActivityDiagram.png