diff --git a/.project b/.project new file mode 100644 index 00000000000..078b3f52b94 --- /dev/null +++ b/.project @@ -0,0 +1,28 @@ + + + tp + Project tp created by Buildship. + + + + + org.eclipse.buildship.core.gradleprojectbuilder + + + + + + org.eclipse.buildship.core.gradleprojectnature + + + + 1634871159586 + + 30 + + org.eclipse.core.resources.regexFilterMatcher + node_modules|.git|__CREATED_BY_JAVA_LANGUAGE_SERVER__ + + + + diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 00000000000..04cd6188656 --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,3 @@ +{ + "java.configuration.updateBuildConfiguration": "automatic" +} diff --git a/LICENSE b/LICENSE index 39b3478982c..c42f359e055 100644 --- a/LICENSE +++ b/LICENSE @@ -2,11 +2,11 @@ MIT License Copyright (c) 2016 Software Engineering Education - FOSS Resources -Permission is hereby granted, free of charge, to any person obtaining a copy +Permission is hereby granted, free of charge, to any patient obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -copies of the Software, and to permit persons to whom the Software is +copies of the Software, and to permit patients to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all diff --git a/README.md b/README.md index 13f5c77403f..9fbddbbc8cd 100644 --- a/README.md +++ b/README.md @@ -1,14 +1,23 @@ -[![CI Status](https://github.com/se-edu/addressbook-level3/workflows/Java%20CI/badge.svg)](https://github.com/se-edu/addressbook-level3/actions) +[![CI Status](https://github.com/AY2122S1-CS2103-W14-1/tp/actions/workflows/gradle.yml/badge.svg)](https://github.com/AY2122S1-CS2103-W14-1/tp/actions/workflows/gradle.yml) +## Doc'it ![Ui](docs/images/Ui.png) -* This is **a sample project for Software Engineering (SE) students**.
- Example usages: - * as a starting point of a course project (as opposed to writing everything from scratch) - * as a case study -* The project simulates an ongoing software project for a desktop application (called _AddressBook_) used for managing contact details. - * It is **written in OOP fashion**. It provides a **reasonably well-written** code base **bigger** (around 6 KLoC) than what students usually write in beginner-level SE modules, without being overwhelmingly big. - * It comes with a **reasonable level of user and developer documentation**. -* It is named `AddressBook Level 3` (`AB3` for short) because it was initially created as a part of a series of `AddressBook` projects (`Level 1`, `Level 2`, `Level 3` ...). -* For the detailed documentation of this project, see the **[Address Book Product Website](https://se-education.org/addressbook-level3)**. + +Today, small family clinics often record patient information using paper application forms. Such recording of patient information results in the clinic having a messy and inefficient patient record information; the family clinic will have to flip through files and documents in order to find the patient. Doc’it aims to provide a centralised platform for authorised staff from small family clinics to view, update and onboard patients. With Doc’it, small family clinics are able to reduce man hours from managing paper documents, and translate these ‘saved’ hours into providing better frontline service to patients, focusing on what they do best. + +* Doc'it is a Patient Record manager for staff from small family clinics to keep track of patients, patient appointments and their respective details. +* It is meant to be used regularly, and requires the user to consistently update on a routine basis. +* Doc'it is: + * written in OOP fashion. + * built off from the ```AddressBook-Level3``` project created by the [SE-EDU initiative](https://se-education.org/addressbook-level3) + +## Site Map +* [User Guide](docs/UserGuide.md) +* [Developer Guide](docs/DeveloperGuide.md) +* [About Us](docs/AboutUs.md) + +## Acknowledgements +* This project is based on the ```AddressBook-Level3``` (`AB3` for short) project created by the [SE-EDU initiative](https://se-education.org) +* For the detailed documentation of `AB3`, see the **[Address Book Product Website](https://se-education.org/addressbook-level3)**. * This project is a **part of the se-education.org** initiative. If you would like to contribute code to this project, see [se-education.org](https://se-education.org#https://se-education.org/#contributing) for more info. diff --git a/build.gradle b/build.gradle index be2d2905dde..c483b3a6ee3 100644 --- a/build.gradle +++ b/build.gradle @@ -6,7 +6,7 @@ plugins { id 'jacoco' } -mainClassName = 'seedu.address.Main' +mainClassName = 'seedu.docit.Main' sourceCompatibility = JavaVersion.VERSION_11 targetCompatibility = JavaVersion.VERSION_11 @@ -42,7 +42,7 @@ task coverage(type: JacocoReport) { dependencies { String jUnitVersion = '5.4.0' - String javaFxVersion = '11' + String javaFxVersion = '17' implementation group: 'org.openjfx', name: 'javafx-base', version: javaFxVersion, classifier: 'win' implementation group: 'org.openjfx', name: 'javafx-base', version: javaFxVersion, classifier: 'mac' @@ -66,7 +66,11 @@ dependencies { } shadowJar { - archiveName = 'addressbook.jar' + archiveName = 'docit.jar' +} + +run { + enableAssertions = true } defaultTasks 'clean', 'test' diff --git a/docs/AboutUs.md b/docs/AboutUs.md index 1c9514e966a..76e16ae4b78 100644 --- a/docs/AboutUs.md +++ b/docs/AboutUs.md @@ -9,51 +9,50 @@ You can reach us at the email `seer[at]comp.nus.edu.sg` ## Project team -### John Doe +### Rishabh Anand - + -[[homepage](http://www.comp.nus.edu.sg/~damithch)] -[[github](https://github.com/johndoe)] -[[portfolio](team/johndoe.md)] +[[github](http://github.com/rish-16)] +[[portfolio](team/rish-16.md)] -* Role: Project Advisor +* Role: Developer +* Responsibilities: Integration, Backend -### Jane Doe +### Gabriel Goh - + -[[github](http://github.com/johndoe)] -[[portfolio](team/johndoe.md)] +[[github](http://github.com/gycgabriel)] +[[portfolio](team/gycgabriel.md)] -* Role: Team Lead -* Responsibilities: UI +* Role: Developer +* Responsibilities: Scheduling and Tracking -### Johnny Doe +### Yu Xin - + -[[github](http://github.com/johndoe)] [[portfolio](team/johndoe.md)] +[[github](https://github.com/huyuxin0429)] +[[portfolio](team/huyuxin0429.md)] * Role: Developer -* Responsibilities: Data +* Responsibilities: Testing -### Jean Doe +### Didymus + - - -[[github](http://github.com/johndoe)] -[[portfolio](team/johndoe.md)] +[[github](https://github.com/didymental)] +[[portfolio](team/didymental.md)] * Role: Developer -* Responsibilities: Dev Ops + Threading - -### James Doe +* Responsibilities: Documentation, Deliverables and deadlines - +### Joshen + -[[github](http://github.com/johndoe)] -[[portfolio](team/johndoe.md)] +[[github](https://github.com/joshenx)] +[[portfolio](team/joshenx.md)] * Role: Developer -* Responsibilities: UI +* Responsibilities: UI, Coding Standard diff --git a/docs/DevOps.md b/docs/DevOps.md index ca59d92f2cb..9f0881fa294 100644 --- a/docs/DevOps.md +++ b/docs/DevOps.md @@ -44,7 +44,7 @@ As part of CI, this project uses Codecov to generate coverage reports. Here are 1. Sign up with Codecov using your GitHub account [here](https://codecov.io/signup). 1. Once you are inside Codecov web app, add your fork to CodeCov. -1. Get the Markdown code for the Codecov badge provided in `Settings > Badges` and update the `docs/index.md` of your repo with it so that the badge [![codecov](https://codecov.io/gh/se-edu/addressbook-level3/branch/master/graph/badge.svg)](https://codecov.io/gh/se-edu/addressbook-level3) in that page reflects the coverage of your project. +1. Get the Markdown code for the Codecov badge provided in `Settings > Badges` and update the `docs/index.md` of your repo with it so that the badge [![codecov](https://codecov.io/gh/AY2122S1-CS2103-W14-1/tp/branch/master/graph/badge.svg)](https://codecov.io/gh/AY2122S1-CS2103-W14-1/tp) in that page reflects the coverage of your project. ### Repository-wide checks @@ -73,7 +73,7 @@ Any warnings or errors will be printed out to the console. Here are the steps to create a new release. -1. Update the version number in [`MainApp.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/MainApp.java). +1. Update the version number in [`MainApp.java`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/java/seedu/docit/MainApp.java). 1. Generate a fat JAR file using Gradle (i.e., `gradlew shadowJar`). 1. Tag the repo with the version number. e.g. `v0.1` 1. [Create a new release using GitHub](https://help.github.com/articles/creating-releases/). Upload the JAR file you created. diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index 46eae8ee565..59b93a3000f 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -2,28 +2,68 @@ layout: page title: Developer Guide --- -* Table of Contents -{:toc} --------------------------------------------------------------------------------------------------------------------- +## Table of Contents +- [Acknowledgements](#acknowledgements) +- [Setting up, getting started](#setting-up-getting-started) +- [Design](#design) + - [Architecture](#architecture) + - [UI component](#ui-component) + - [Logic component](#logic-component) + - [Model component](#model-component) + - [Storage component](#storage-component) + - [Common classes](#common-classes) +- [Implementation](#implementation) + - [Medical History](#medical-history) + - [Add Medical Entry feature](#add-medical-entry-feature) + - [Delete Medical Entry feature](#delete-medical-entry-feature) + - [Appointment composed of a Valid Patient when added, loaded and stored](#appointment-composed-of-a-valid-patient-when-added-loaded-and-stored) + - [How Appointment is implemented](#how-appointment-is-implemented) + - [Add a new Appointment](#add-a-new-appointment) + - [Load Appointments on App Launch](#load-appointments-on-app-launch) + - [Save Appointments after every command](#save-appointments-after-every-command) + - [Delete Patient that has made an Appointment](#delete-patient-that-has-made-an-appointment) + - [Archiving an Appointment](#archiving-an-appointment) + - [Auto-Archiving Feature](#auto-archiving-feature) + - [Recording a Patient's Prescription feature](#recording-a-patients-prescription-feature) + - [How Prescription is implemented](#how-prescription-is-implemented) + - [Reason for implementation of Prescription](#reason-for-implementation-of-prescription) + - [Prescription commands](#prescription-commands) + - [Add Prescription command](#add-prescription-command) + - [Delete Prescription command sequence](#delete-prescription-command-sequence) + - [General Prescription command sequence](#general-prescription-command-sequence) +- [Documentation, logging, testing, configuration, dev-ops](#documentation-logging-testing-configuration-dev-ops) +- [Appendix: Requirements](#appendix-requirements) + - [Product scope](#product-scope) + - [User stories](#user-stories) + - [Use cases](#use-cases) + - [Non-Functional Requirements](#non-functional-requirements) + - [Glossary](#glossary) +- [Appendix: Instructions for manual testing](#appendix-instructions-for-manual-testing) + - [Launch and shutdown](#launch-and-shutdown) + - [Deleting a patient](#deleting-a-patient) + - [Saving data](#saving-data) + +--- ## **Acknowledgements** -* {list here sources of all reused/adapted ideas, code, documentation, and third-party libraries -- include links to the original source as well} +* Libraries used: [JavaFX](https://openjfx.io/), [Jackson](https://github.com/FasterXML/jackson), [JUnit5](https://github.com/junit-team/junit5) --------------------------------------------------------------------------------------------------------------------- +--- ## **Setting up, getting started** Refer to the guide [_Setting up and getting started_](SettingUp.md). --------------------------------------------------------------------------------------------------------------------- +--- ## **Design**
-:bulb: **Tip:** The `.puml` files used to create diagrams in this document can be found in the [diagrams](https://github.com/se-edu/addressbook-level3/tree/master/docs/diagrams/) folder. Refer to the [_PlantUML Tutorial_ at se-edu/guides](https://se-education.org/guides/tutorials/plantUml.html) to learn how to create and edit diagrams. + +:bulb: **Tip:** The `.puml` files used to create diagrams in this document can be found in the [diagrams](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/docs/diagrams/) folder. Refer to the [_PlantUML Tutorial_ at se-edu/guides](https://se-education.org/guides/tutorials/plantUml.html) to learn how to create and edit diagrams.
### Architecture @@ -36,7 +76,7 @@ Given below is a quick overview of main components and how they interact with ea **Main components of the architecture** -**`Main`** has two classes called [`Main`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/Main.java) and [`MainApp`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/MainApp.java). It is responsible for, +**`Main`** has two classes called [`Main`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/java/seedu/docit/Main.java) and [`MainApp`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/java/seedu/docit/MainApp.java). It is responsible for, * At app launch: Initializes the components in the correct sequence, and connects them up with each other. * At shut down: Shuts down the components and invokes cleanup methods where necessary. @@ -49,7 +89,6 @@ The rest of the App consists of four components. * [**`Model`**](#model-component): Holds the data of the App in memory. * [**`Storage`**](#storage-component): Reads data from, and writes data to, the hard disk. - **How the architecture components interact with each other** The *Sequence Diagram* below shows how the components interact with each other for the scenario where the user issues the command `delete 1`. @@ -59,7 +98,7 @@ The *Sequence Diagram* below shows how the components interact with each other f Each of the four main components (also shown in the diagram above), * defines its *API* in an `interface` with the same name as the Component. -* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point. +* implements its functionality using a concrete `{Component Name}Manager` class (which follows the corresponding API `interface` mentioned in the previous point.) For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below. @@ -69,187 +108,524 @@ The sections below give more details of each component. ### UI component -The **API** of this component is specified in [`Ui.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java) +The **API** of this component is specified in [`Ui.java`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/java/seedu/docit/ui/Ui.java) ![Structure of the UI Component](images/UiClassDiagram.png) -The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the visible GUI. +The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `PatientListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the visible GUI. -The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/resources/view/MainWindow.fxml) +The `UI` component uses the JavaFx UI framework. The layout of these UI parts are defined in matching `.fxml` files that are in the `src/main/resources/view` folder. For example, the layout of the [`MainWindow`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/java/seedu/docit/ui/MainWindow.java) is specified in [`MainWindow.fxml`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/resources/view/MainWindow.fxml) The `UI` component, * executes user commands using the `Logic` component. * listens for changes to `Model` data so that the UI can be updated with the modified data. * keeps a reference to the `Logic` component, because the `UI` relies on the `Logic` to execute commands. -* depends on some classes in the `Model` component, as it displays `Person` object residing in the `Model`. +* depends on some classes in the `Model` component, as it displays `Patient` object residing in the `Model`. + +**Displaying Patient and Appointment Panels** + +The main UI parts of the `MainWindow` to display Patient and Appointment information are `PatientListPanel` and +`AppointmentListPanel`, each holding a number of `PatientCard`'s and `AppointmentCard`'s. + + +![Example of PatientCard](images/PatientCard.png) + +In the `PatientCard` part, we can see all the details that we store of the Patient. + +![Example of AppointmentCard](images/AppointmentCard.png) + +In the `AppointmentCard` part, appointments occurring today have a highlighted '**TODAY**' indicator to help clinic staff +easily identify appointments occurring today. Non-essential patient details are also omitted. + +We can also toggle between the **Archive** and **Upcoming** tabs to view Appointments that are upcoming or have been +archived. This is also the reason why `MainWindow` component holds two `AppointmentListPanel`'s - One for +upcoming appointments, and the other for archived appointments. + +A multi-panel display is used because the user should be able to look for an Appointment's patient details without +swapping back and forth between the Patient list and Appointments list. The tab display is used as archived appointments are likely +to be referred to less than upcoming ones. The decision to separate the two into two tabs reduces visual clutter significantly +and allows the user to view the more important information immediately. ### Logic component -**API** : [`Logic.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/logic/Logic.java) +**API** : [`Logic.java`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/java/seedu/docit/logic/Logic.java) Here's a (partial) class diagram of the `Logic` component: How the `Logic` component works: + 1. When `Logic` is called upon to execute a command, it uses the `AddressBookParser` class to parse the user command. -1. This results in a `Command` object (more precisely, an object of one of its subclasses e.g., `AddCommand`) which is executed by the `LogicManager`. -1. The command can communicate with the `Model` when it is executed (e.g. to add a person). -1. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`. + - `AddressBookParser` categorises the command according to its format (using RegEx) and hands it off + to either one of `BasicAddressBookParser`, `PatientBookParser`, or `AppointmentBookParser`. +2. The chosen parser then parses the command and returns a `Command` object (more precisely, an object of one of its subclasses e.g., `AddPatientCommand`) which is executed by the `LogicManager`. +3. The command can communicate with the `Model` when it is executed (e.g. to add a patient). +4. The result of the command execution is encapsulated as a `CommandResult` object which is returned back from `Logic`. + +The Sequence Diagram below illustrates the interactions within the `Logic` component for the `execute("pt delete 1")` API call. The illustration has been split into two parts: (1) Parse User Input, (2) Execute command. -The Sequence Diagram below illustrates the interactions within the `Logic` component for the `execute("delete 1")` API call. +**Parse User Input** -![Interactions Inside the Logic Component for the `delete 1` Command](images/DeleteSequenceDiagram.png) +![Interactions Inside the Logic Component for the `pt delete 1` Command](diagrams/DeletePatientFeatureSequenceDiagram1.png) -
:information_source: **Note:** The lifeline for `DeleteCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram. +
:information_source: **Note:** The lifeline for `PatientBookParser` and `DeletePatientCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+**Execute command** + +![Interactions Inside the Logic Component for the `pt delete 1` Command](diagrams/DeletePatientFeatureSequenceDiagram.png) + + Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command: - +[comment]: +![Interactions between Command and Parser](diagrams/ParserClasses.png) How the parsing works: -* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as a `Command` object. -* All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser` interface so that they can be treated similarly where possible e.g, during testing. -### Model component -**API** : [`Model.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/model/Model.java) +* When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddPatientCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddPatientCommand`) which the `AddressBookParser` returns back as a `Command` object. +* All `XYZCommandParser` classes (e.g., `AddPatientCommandParser`, `DeletePatientCommandParser`, ...) inherit from one of the three parser interfaces: `BasicParser`, `PatientParser`, or `AppointmentParser` so that they + be treated appropriately based on the type of command issued. + +* The three types of parsers (`BasicParser`, `PatientParser`, `AppointmentParser`) inherit directly from the `Parser` interface so that they can be treated similarly where possible e.g, during testing. + +**Breakdown of Commands**
+In the original AB3, all commands extend the `Command` abstract class. +`Doc'it` supports three types of commands – general, patient-related, and appointment-related. As such, we introduce three abstract classes `BasicCommand`, `PatientCommand`, and `AppointmentCommand` in place of `Command`. + +> As the names suggest, `BasicCommand` deals with whole application-related operations, `PatientCommand` deals with patient-related CRUD operations, and `AppointmentCommand` deal with appointment-related CRUD operations. + +The following is a list of commands that extend the three abstract classes: + +- `BasicCommand` + - `ExitCommand` + - `ClearCommand` + - `HelpCommand` +- `PatientCommand` + - `AddPatientCommand` + - `EditPatientCommand` + - `DeletePatientCommand` + - `ListPatientCommand` + - `FindPatientCommand` + - `AddMedicalEntryCommandParser` + - `DeleteMedicalEntryCommandParser` +- `AppointmentCommand` + - `AddAppointmentCommand` + - `ArchiveAppointmentCommand` + - `EditAppointmentCommand` + - `DeleteAppointmentCommand` + - `ListAppointmentsCommand` + - `SortAppointmentsCommand` + - `AddPrescriptionCommand` + - `DeletePrescriptionCommand` + +> This taxonomy of commands is further reflected on the Parser's side as well. + +**Parser**
+The `Parser` interface is broken into three sub-interfaces: `BasicParser`, `PatientParser`, and `AppointmentParser`, for the parsers related to application-related commands, patient-related commands, and +appointment-related commands respectively. For all commands under `PatientParser` and `AppointmentParser` (ones that require +any form of extra user input), we have a specific parser that tokenises the command: + +- `PatientCommandParser` + - `AddPatientCommandParser` + - `EditPatientCommandParser` + - `DeletePatientCommandParser` + - `FindPatientCommandParser` + - `AddMedicalEntryCommandParser` + - `DeleteMedicalEntryCommandParser` +- `AppointmentParser` + - `AddAppointmentCommandParser` + - `EditAppointmentCommandParser` + - `DeleteAppointmentCommandParser` + - `AddPrescriptionCommandParser` + - `DeletePrescriptionCommandParser` - +### Model component +**API** : [`Model.java`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/java/seedu/docit/model/Model.java) + The `Model` component, -* stores the address book data i.e., all `Person` objects (which are contained in a `UniquePersonList` object). -* stores the currently 'selected' `Person` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change. +* stores the address book data and appointment book data (both upcoming and archived) i.e., all `Patient`, `Appointment` objects (which are contained in `UniquePatientList` and `UniqueAppointmentList` objects). +* stores the currently 'selected' `Patient` objects (e.g., results of a search query) as a separate _filtered_ list which is exposed to outsiders as an unmodifiable `ObservableList` that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change. * stores a `UserPref` object that represents the user’s preferences. This is exposed to the outside as a `ReadOnlyUserPref` objects. * does not depend on any of the other three components (as the `Model` represents data entities of the domain, they should make sense on their own without depending on other components) -
:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Tag` list in the `AddressBook`, which `Person` references. This allows `AddressBook` to only require one `Tag` object per unique tag, instead of each `Person` needing their own `Tag` objects.
+
:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. - +
- ### Storage component -**API** : [`Storage.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/storage/Storage.java) +**API** : [`Storage.java`](https://github.com/AY2122S1-CS2103-W14-1/tp/tree/master/src/main/java/seedu/docit/storage/Storage.java) - + The `Storage` component, -* can save both address book data and user preference data in json format, and read them back into corresponding objects. -* inherits from both `AddressBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed). + +* can save address book data, appointment book data, and user preference data in json format, and read them back into corresponding objects. +* inherits from `AddressBookStorage`, `AppointmentBookStorage` and `ArchivedAppointmentBookStorage` and `UserPrefStorage`, which means it can be treated as either one (if only the functionality of only one is needed). * depends on some classes in the `Model` component (because the `Storage` component's job is to save/retrieve objects that belong to the `Model`) ### Common classes Classes used by multiple components are in the `seedu.addressbook.commons` package. --------------------------------------------------------------------------------------------------------------------- +--- ## **Implementation** This section describes some noteworthy details on how certain features are implemented. -### \[Proposed\] Undo/redo feature +### Medical History -#### Proposed Implementation +**Class Implementation details** -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: +- The `MedicalHistory` class composes an `EntryList>` class. +- The `EntryList` class references the `Entry` through an `ArrayList`. +- The `Entry` class is an abstract class that is either a `Some` or an `Empty` class. +- Each `Patient` class composes exactly one `MedicalHistory` class. +- `MedicalEntry` is an inner static class of `MedicalHistory` +- Each `MedicalEntry` has a `description` data attribute and a `dateOfRecord` data attribute. The `description` data is supplied by the user. The `dateOfRecord` is automatically generated based on the date the medical entry was recorded. -* `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. +Below is a class diagram illustrating the relationship between `Patient` and `MedicalHistory`. Note: other details within the `Model` component are omitted. -These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and `Model#redoAddressBook()` respectively. +![Class diagram of MedicalHistory](diagrams/MedicalHistoryClassDiagram.png) -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. +**Design Considerations** -![UndoRedoState0](images/UndoRedoState0.png) +| Alternative Considered | Current implementation | Rationale for current implementation | +| ---------- | ------------------------ | ------------------------ | +| Using a list of medical entries as an attribute of a `Patient` class | Multiple or zero `MedicalEntry` objects can be stored by a single `MedicalHistory`. Each `Patient` class has exactly one `MedicalHistory` reference. | ```Patient``` and ```MedicalHistory``` share a whole-part relationship: when a ```Patient``` object is destroyed, the corresponding ```MedicalHistory``` object is also destroyed. If the `Patient` does not have any medical records, this means that the `MedicalHistory` is empty, which is reflected by a single `EMPTY_MEDICAL_HISTORY` (instantiation of a `MedicalHistory` object with an `EntryList>` containing exactly one `Entry` that is an `Empty`). Hence, there is a 1...1 multiplicity relationship between ```Patient``` and ```MedicalHistory```, as one patient can have exactly one medical history. Following OOP Principles, it is more apt to encapsulate medical history records (or medical entries) as a `MedicalHistory` class than using a collection of medical entries, e.g. `List`. | +| Using `null` to reflect an empty `MedicalHistory` for patients that do not have any recorded medical history | An empty `MedicalHistory` object is instantiated (`EMPTY_MEDICAL_HISTORY`), and this object is referenced in every `Patient` object that does not have any medical history records. | It is not a mistake for a patient to have zero medical history records. If we were to use `null` to reflect an empty medical history, there would be many scenarios where by running a blanket command on a patient, `NullPointerException` would be thrown at runtime if we do not check for `null`. Hence, as part of our defensive programming efforts, we created a single `EMPTY_MEDICAL_HISTORY` object that is an instantiation of a `MedicalHistory` object with an `EntryList>` containing exactly one `Entry` that is an `Empty`. This allows us to bypass `NullPointerException` due to the additional null safety built in and exploit polymorphism.| +| Using the `Optional` interface to reflect an `Entry` | `Entry` class is implemented to reflect an `Entry` that is either `Some` or `Empty`, such that all `null` or `empty` inputs into the factory `of` method generate an `Entry.Empty`, and every other input generates an `Entry.Some` | When the `Optional::of` takes in `null`, a runtime exception is thrown. But `null` is a valid input. While `Optional` provides an `ofNullable` method, we wanted to take an active defensive programming approach. We thus constructed the `Entry` class, whereby there is only one factory `of` method, where `null` inputs are taken care of. | +| Using the `List` interface to reflect a list of entries | `EntryList` class is implemented to reflect an `EntryList` that contains the `Entry` | We want to limit the methods available for an `EntryList` to only `add`, `delete`, `size`, `get`, `toStream`. Each `Entry` and their position within the `EntryList` should not be modifiable. After all, at our current stage of production, we do not want the `MedicalEntry` to have a different order from their time of input. Iterator functions of the `List` interface allow for modification of contents of an `Entry` at a specified position in the `List`, which violates this invariant. As part of defensive programming, we thus chose to create an `EntryList` class that exposes only the immutable functions of a `List`.| +| Having `MedicalEntry` as a separate class from `MedicalHistory` | `MedicalEntry` is an inner static class of `MedicalHistory` | A `MedicalEntry` can only exist if there is a `MedicalHistory`. There should be no instantiation of a `MedicalEntry` without a `MedicalHistory` instantiated. We also do not want `MedicalEntry` to implement any interface that `MedicalHistory` does not. Thus, we opted to have `MedicalEntry` as an inner class of `MedicalHistory`. | -Step 2. The user executes `delete 5` command to delete the 5th person in the address book. The `delete` command calls `Model#commitAddressBook()`, causing the modified state of the address book after the `delete 5` command executes to be saved in the `addressBookStateList`, and the `currentStatePointer` is shifted to the newly inserted address book state. +#### Add Medical Entry feature -![UndoRedoState1](images/UndoRedoState1.png) +**Overview** -Step 3. The user executes `add n/David …​` to add a new person. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`. +The Add Medical Entry feature allows users to add medical entries into the `MedicalHistory` of a `Patient`. Each new `MedicalEntry` must have the data field `description`, which is the description of the medical record (e.g. `diabetes`). -![UndoRedoState2](images/UndoRedoState2.png) +Below is a class diagram of the components involved in the Add Medical Entry feature. -
: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`. +![Class diagram of Add Medical Entry Feature](diagrams/AddMedicalEntryFeatureClassDiagram.png) -
+**Implementation details of feature** + +The Add Medical Entry feature is implemented via the `AddMedicalEntryCommand`, which is supported by the `AddMedicalEntryCommandParser`. The `AddMedicalEntryCommandParser` implements the `PatientParser` interface. +1. `LogicManager` receives the user input which is parsed by the `AddressBookParser`. +2. The `AddressBookParser` invokes the `PatientBookParser` based on the regex pattern of the user input, splitting the user input into `commandWord` and `arguments`. +3. The `PatientBookParser` invokes the `AddMedicalEntryCommandParser` based on the `commandWord`, calling the method `parsePatientCommand` with `arguments` as the method argument. +4. `AddMedicalEntryCommandParser` takes in the argument string and invokes an `ArgumentMultiMap`, which tokenizes the `arguments`. +5. If the required `preamble` and `PREFIX_MEDICAL` is present, the `AddMedicalEntryCommandParser` will invoke the `AddMedicalEntryCommand` after calling the `parseMedicalHistory` method provided by `ParserUtil`, which returns a `MedicalHistory` based on the `description` data field. The `preamble` identifies the `Index` of the `Patient` to add the medical entry to, while the string after `PREFIX_MEDICAL` specifies the `description` data field required for adding a new `MedicalEntry`. +6. `LogicManager` calls the `execute` method of the `AddMedicalEntryCommand`, which calls the `addMedicalHistory` of the `Patient` specified by the `Index`. +7. The `AddMedicalEntryCommand` will then call the methods `setPatient`, `updateAppointmentBook`, `updateFilteredPatientList` and `updateFilteredAppointmentList` provided by the `Model`, editing the patient's medical history information. +8. The `AddMedicalEntryCommand` returns a `CommandResult`, which will be returned to the `LogicManager`. -Step 4. The user now decides that adding the person 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. +Below is a sequence diagram illustrating the interactions between the `Logic` and `Model` components when the user inputs `pt ma 1 m/diabetes` command. Note that the full command string has been abbreviated to `...`. The illustration has been split into two parts: (1) Parse User Input, (2) Execute command. -![UndoRedoState3](images/UndoRedoState3.png) +**Parse User Input** -
: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. +![Sequence diagram of Add Medical Entry Feature](diagrams/AddMedicalEntrySequenceFeatureDiagram1.png) +
:information_source: **Note:** The lifeline for `PatientBookParser` and `AddMedicalEntryCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-The following sequence diagram shows how the undo operation works: +**Execute a:AddMedicalEntryCommand** -![UndoSequenceDiagram](images/UndoSequenceDiagram.png) +![Sequence diagram of Add Medical Entry Feature](diagrams/AddMedicalEntryFeatureSequenceDiagram.png) -
: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 following activity diagram summarises what happens within `AddMedicalEntryCommandParser` when the user executes an Add Medical Entry command. -
+![Activity diagram of Add Medical Entry Feature](diagrams/AddMedicalEntryFeatureActivityDiagram.png) + +**Design considerations** + +| Alternative Considered | Current implementation | Rationale for current implementation | +| ---------- | ------------------------ | ------------------------ | +| Implementing a `MedicalHistoryBookParser` to invoke the `AddMedicalEntryCommandParser` | Having `PatientBookParser` invoke `AddMedicalEntryCommandParser` | Since `MedicalHistory` is an attribute of `Patient`, it makes sense to use the `PatientBookParser`. It also takes more effort to implement a new `Parser` that requires an entirely new command word prefix to add a `MedicalEntry`. | + + +#### Delete Medical Entry feature + +**Overview** -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. +The Delete Medical Entry feature allows users to delete medical entries from the `MedicalHistory` of a `Patient`. -
: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. +Below is a class diagram of the components involved in the Delete Medical Entry feature. +![Class diagram of Delete Medical Entry Feature](diagrams/DeleteMedicalEntryFeatureClassDiagram.png) + +**Implementation details of feature** + +The Delete Medical Entry feature is implemented via the `DeleteMedicalEntryCommand`, which is supported by the `DeleteMedicalEntryCommandParser`. The `DeleteMedicalEntryCommandParser` implements the `PatientParser` interface. +1. `LogicManager` receives the user input which is parsed by the `AddressBookParser`. +2. The `AddressBookParser` invokes the `PatientBookParser` based on the regex pattern of the user input, splitting the user input into `commandWord` and `arguments`. +3. The `PatientBookParser` invokes the `DeleteMedicalEntryCommandParser` based on the `commandWord`, calling the method `parsePatientCommand` with `arguments` as the method argument. +4. `DeleteMedicalEntryCommandParser` takes in the argument string and invokes an `ArgumentMultiMap`, which tokenizes the `arguments`. +5. If the required `patientIndex` and `medicalIndex` is present, the `DeleteMedicalEntryCommandParser` will invoke the `DeleteMedicalEntryCommand` after calling the `parseIndex` method provided by `ParserUtil`, which returns an `Index` to specify the `patient` and the `medicalEntry` to be deleted. +6. `LogicManager` calls the `execute` method of the `DeleteMedicalEntryCommand`, which calls the `deleteMedicalHistory` of the `Patient` specified by the `Index`. +7. The `DeleteMedicalEntryCommand` will then call the methods `setPatient`, `updateAppointmentBook`, `updateFilteredPatientList` and `updateFilteredAppointmentList` provided by the `Model`, editing the patient's medical history information. +8. The `DeleteMedicalEntryCommand` returns a `CommandResult`, which will be returned to the `LogicManager`. + +Below is a sequence diagram illustrating the interactions between the `Logic` and `Model` components when the user inputs `pt md 1 i/1` command. Note that the full command string has been abbreviated to `...`. The illustration has been split into two parts: (1) Parse User Input, (2) Execute command. + +**Parse User Input** + +![Sequence diagram of Delete Medical Entry Feature](diagrams/DeleteMedicalEntryFeatureSequenceDiagram1.png) + +
:information_source: **Note:** The lifeline for `PatientBookParser` and `DeleteMedicalEntryCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-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. +**Execute d:DeleteMedicalEntryCommand** + +![Sequence diagram of Delete Medical Entry Feature](diagrams/DeleteMedicalEntryFeatureSequenceDiagram.png) + +The following activity diagram summarises what happens within `DeleteMedicalEntryCommandParser` when the user executes a DeleteMedicalEntry command. + +![Activity diagram of Delete Medical Entry Feature](diagrams/DeleteMedicalEntryFeatureActivityDiagram.png) + +**Design Considerations** + +| Alternative Considered | Current implementation | Rationale for current implementation | +| ---------- | ------------------------ | ------------------------ | +| Implementing a `MedicalHistoryBookParser` to invoke the `DeleteMedicalEntryCommandParser` | Having `PatientBookParser` invoke `DeleteMedicalEntryCommandParser` | Since `MedicalHistory` is an attribute of `Patient`, it makes sense to use the `PatientBookParser`. It also takes more effort to implement a new `Parser` that requires an entirely new command word prefix to delete a `MedicalEntry`. | + + + +### Appointment composed of a Valid Patient when added, loaded and stored + +#### How Appointment is implemented + +![AppointmentClassDiagram](images/AppointmentClassDiagram.png) + +Each `Appointment` in memory contains a reference to a valid `Patient` object. To ensure this valid reference is maintained while the app is running and between different running instances, `Appointment` is stored in JSON with the index of the `Patient` in the corresponding `AddressBook`. + +Major changes involved to implement this feature: +* Add a new appointment +* Load appointments on app launch +* Save appointments after every command +* Delete a patient that has made an appointment + +#### Add a new Appointment + +**Overview** + +`AddAppointmentCommand#execute()` gets patient at the given index in the address book to create a new appointment referencing that patient. + +**Detailed Implementation** + +The user executes `apmt add i/1 d/2021-10-19 1800` to add an appointment to the first patient of the address book. The `apmt add` command calls `Model#getFilteredPatientList()`to receive a list of patients and gets the Patient object at the inputted index. A new Appointment of that patient is instantiated, and the `AddAppointmentCommand` calls `Model#addAppointment()` to add this appointment to the appointment book. A `CommandResult` is instantiated and returned. + +![AddAppointmentSequenceDiagram](images/AddAppointmentSequenceDiagram.png) + + +**Design considerations** + +**Aspect: How Appointments are instantiated** + +| Design Choice | Justification | Pros | Cons | +| ---------- | ------------------------ | ------------------------ | ------------------------ | +| **Appointment is composed of a Patient (current choice)** | Appointment can only be instantiated with a Patient, and without Patients, Appointments cannot exist. Hence, for an appointment to be instantiated, it requires a reference to the related Patient object. |
  • Enforces 1 multiplicity requiring one Appointment to be associated with exactly one Patient.
  • Easy to find the patient of the appointment.
  • | Need to locate corresponding Patient before Appointment can be instantiated. Thus, `AddressBook` must be loaded to memory before `AppointmentBook`. | +| Patient and Appointment have an association such that Patient has a link to Appointment and Appointment only requires date and time to instantiate. | - | Able to load `AppointmentBook` without loaded `AddressBook`. |
  • Appointments may not be unique objects as there may be patients with multiple appointments at the same date and time at the same clinic that can be served by different doctors.
  • Difficult to find Patient of each Appointment when Appointment is extracted from Patients and listed because Appointment has no Patient field.
  • | + + +#### Load Appointments on App Launch + +**Overview** + +* The app first loads address book, then passes the address book as argument to `Storage#readAppointmentBook()`. +* `Storage#readAppointmentBook()` gets the corresponding patient from the patient index in `JSONAdaptedAppointments` and instantiates appointments. + +**Detailed Implementation** -![UndoRedoState4](images/UndoRedoState4.png) +The user launches the application. `MainApp` runs `MainApp#initModelManager` to initialize the model. First, the address book of patients is loaded to memory in `StorageManager#readAddressBook()`. Referencing the order of patients in this loaded address book, `StorageManager#readAppointmentBook()` loads the appointment book. Under `Storage`, the JSON file is loaded to `JsonAdaptedAppointment` object and its `JsonAdaptedAppointment#toModelType()` is executed. `JsonAdaptedAppointment#toModelType()` runs `AddressBook#getPatientOfIndex()` to get the patient of the appointment at the index loaded from the JSON file. The Appointment object is then instantiated. -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. +![LoadAppointmentSequenceDiagram](images/LoadAppointmentSequenceDiagram.png) -![UndoRedoState5](images/UndoRedoState5.png) +#### Save Appointments after every command -The following activity diagram summarizes what happens when a user executes a new command: +**Overview** - +* The app runs `LogicManager#saveAppointmentBook()`. +* `LogicManager#saveAppointmentBook()` gets the index of the patient referenced by the appointment, that is to be stored as `JSONAdaptedAppointments` in JSON file. -#### Design considerations: +**Detailed Implementation** -**Aspect: How undo & redo executes:** +After every command that the user makes, appointments are saved. In `LogicManager#executes`, after every command is executed, `LogicManager` calls `StorageManager#saveAppointmentBook`, passing in the appointment book and address book from `Model` as arguments. In converting model-type Appointments to `JSONAdaptedAppointment`, `AddressBook#getIndexOfPatient()` is called to get the corresponding index of the patient for storage. -* **Alternative 1 (current choice):** Saves the entire address book. - * Pros: Easy to implement. - * Cons: May have performance issues in terms of memory usage. +![SaveAppointmentSequenceDiagram](images/SaveAppointmentSequenceDiagram1.png) -* **Alternative 2:** Individual command knows how to undo/redo by - itself. - * Pros: Will use less memory (e.g. for `delete`, just save the person being deleted). - * Cons: We must ensure that the implementation of each individual command are correct. +The diagram below is a more in-dcannnepth look at how `JSONAdaptedAppointment` is instantiated. -_{more aspects and alternatives to be added}_ +![SaveAppointmentSequenceDiagram](images/SaveAppointmentSequenceDiagram2.png) -### \[Proposed\] Data archiving -_{Explain here how the data archiving feature will be implemented}_ +**Design considerations** +**Aspect: How Appointments are loaded and saved** --------------------------------------------------------------------------------------------------------------------- +| Design Choice | Justification | Pros | Cons | +| ---------- | ------------------------ | ------------------------ | ------------------------ | +| **Save `Appointment` as the index of corresponding patient in `AddressBook` and datetime. (current choice)** | The order of `AddressBook` does not change when saving or loading `AppointmentBook`. The order of `AddressBook` is saved each time `AppointmentBook` is saved. |
  • Index of patient requires less code then implementing a unique ID and fits with our theme of using indices in commands.
  • Index of patient is guaranteed to be a unique identifier.
  • | Order of the `AddressBook` is important. If the order of patients is changed in the json file, the appointments will become incorrect. | +| Implement a hash or Universally Unique Identifier (UUID) to for each Patient and Appointment object. Save `Appointment` with Patient UUID and save `Patient` with Appointment UUID. | - | Changing the order of appointments and patients in saved JSON file will not change affect loading of data. |
  • Requires more code to implement a unique hash or UUID and find the corresponding Patient and Appointment by traversing the `AddressBook` and `AppointmentBook` respectively.
  • Takes more computational work when loading compared to finding the `Patient` at an index at O(1) time.
  • | + + +#### Delete Patient that has made an Appointment + +**Overview** + +Delete all `Appointments` containing that `Patient` object when `Patient` object is deleted. + + +**Detailed Implementation** + +The user executes `pt delete 1` to delete the first patient in the address book. The patient is deleted and the corresponding appointments and archive appointments with that patient are deleted. The `pt delete` command calls `AddressBook#deleteAppointmentsWithPatient()` to delete all appointments to that patient before deleting the patient. + +![DeletePatientActivityDiagram](images/DeletePatientActivityDiagram.png) + +**Design considerations** + +**Aspect: When a patient that has appointment is deleted** + +| Design Choice | Justification | Pros | Cons | +| ---------- | ------------------------ | ------------------------ | ------------------------ | +| **Delete all appointments that the patient has (current choice)** | `Appointments` is a class that is instantiated with a `Patient` object. When that corresponding `Patient` object is deleted, the `Patient`s appointment objects should be deleted as well so there will be no reference to deleted `Patient` objects. |
  • Ensures `Patient` object is deleted completely from the system, and no objects holds references to deleted `Patient` objects.
  • No `Appointment` objects will reference an invalid `Patient` object.
  • |
  • Accidental deleting of a `Patient` will delete all corresponding `Appointments` which may cause extra hassle to enter in all the `Appointment` details again.
  • No past appointment data of deleted `Patients` can be kept because their `Appointment` objects are deleted to garbage collect and truly delete `Patient` objects.
  • | +| **Delete patient without deleting the patient's appointments** | - | Past appointment data of `Patient` object can be kept as archives in the system. `Patient` object is not truly deleted and can be restored if needed. |
  • Requires more code to implement an indicator if `Patient` of an `Appointment` has been deleted to safeguard against Upcoming `Appointments` made for deleted `Patients`.
  • Deleted `Patient` object will need to be saved and loaded from JSON which would require corresponding storage classes such as `DeletedPatientBook` to be created.
  • | + + + +#### Archiving an Appointment + +**Overview** + +A user is able to archive an appointment when the appointment is _expired_, i.e. the patient has either missed his/her appointment +or already attended the scheduled appointment. In this case, the appointment should be archived, so that clinic staff +are able to view what medicine was prescribed to the patient during previous appointments. + +**Implementation Details** + +![Sequence diagram of Archive Command](diagrams/ArchiveCommandSequenceDiagram.png) + + +Users may archive specific appointments manually to remove visual clutter. This is done through the `ArchiveAppointmentCommand`. + +The above sequence diagram displays how the archive command works. The parsing mechanism has been abstracted out from the above diagram as it +has been covered in previous diagrams. An example input can be viewed in our [User guide](UserGuide.md). It first retrieves the Appointment to archive from the +appointment index parsed through the user input, removes the appointment from upcoming appointments, and adds it to archived appointments. + +Archiving is facilitated by the `ArchivedAppointmentBook`. As opposed to the regular `AppointmentBook`, it does not allow +users to directly modify the data of appointments as archived data should not be edited. Hence, the following operations +have the `private` access modifier: + +- `ArchivedAppointmentBook#setAppointment(Appointment target, Appointment editedAppointment)` - edits the `target` Appointment + to be replaced with `editedAppointment`. +- `ArchivedAppointmentBook#removeAppointment(Appointment key)` - removes the target Appointment `key`. + +The reason these methods exist in the class is so to support the methods `ArchivedAppointmentBook#updatePatient(Patient target, Patient editedPatient)` +and `ArchivedAppointmentBook#removePatient(Patient target)`, which are called to accurately reflect any updates/removals of patient +details. + +![Class diagram of Archive Storage](diagrams/ArchivedStorageClassDiagram.png) + +In the `Storage` component, the addition of `ArchivedAppointmentBook` also necessitates the implementation of a separate storage system +for archived appointments. This forms under `ArchivedAppointmentBookStorage`, alongside `AddressBookStorage` and `AppointmentBookStorage`. +The .json file for archived appointments is named 'archivedappointmentbook.json'. + +**Design Considerations** + +| Alternative Considered | Current implementation | Rationale for current implementation | +| ---------- | ------------------------ | ------------------------ | +| Implementing archived appointments as a second `UniqueAppointmentList` attribute under the `AppointmentBook` class | Have a separate class `ArchivedAppointmentBook` | Having a separate class `ArchivedAppointmentBook` separates the two types of appointments better to facilitate data management. It ties in better with our Storage framework, and archivedappointmentbook.json files can be easily used by the user, instead of having to split one appointmentbook.json files into two segments. | + + +#### Auto-Archiving Feature + +The archiving implementation involves scanning through all appointments in a day and comparing it to +the current date and time of the user system. If the current date and time is 24 hours ahead of the scheduled +appointment time (24-hour buffer), i.e. by our definition, _expired_, the appointment is automatically archived. This auto-archiving implementation is handled +by the `ModelManager` class in two ways. + +![Sequence diagram of Auto-Archive Feature](diagrams/AutoArchiveSequenceDiagram.png) + +1. Upon initialisation of the application, the application automatically archives expired appointments (24-hours past their + scheduled time). This is called through `ModelManager#archivePastAppointments()`. + + +2. A `ScheduledExecutorService` object schedules the task `AutoArchiveApmts` which implements the `Runnable` interface. + Every day at the `ModelManager.UPDATE_HOUR`th hour, the `Runnable` object executes the `ModelManager#archivePastAppointments()` + method. + + +In the case where there are many scheduled appointments, this saves the user trouble of archiving past appointments when +they are already over. + +### Recording a Patient's Prescription feature + +During appointments, the doctor can provide prescription of drugs for patients. +Recording this information together with appointment information helps clinic staff to keep track of prescriptions given to a patient. +Past prescriptions can also be viewed with past appointments. + +#### How Prescription is implemented +Prescription derives from the original Tags class from AB3 and is modified with extra fields and checks. +* Each `Prescription` class contains fields recording Medicine, Volume and Duration. +* Each `Appointment` class contains 0 or more `Prescription` objects. + +![Class diagram of Prescription](diagrams/PrescriptionClassDiagram.png) + +The implementation of the Prescription class is done with a ```Prescription``` class. The ```Prescription``` class keep records of the medicine given, volume of medicine, and the duration which the medicine is taken. +```Prescription``` objects are composed under ```Appointment``` objects, and will be deleted along with the parent ```Appointment``` object. +Within each ```Appointment``` class, a collection of these ```Prescription``` objects are stored. + +The following commands are available from the ```Appointment``` class to interact with ```Prescription``` objects. + +* ```addPrescription(Prescription prescription)```- adds a new prescription for that appointment. +* ```deletePrescription(String medicineName)```- removes an existing prescription based on the name of the medicine. + +#### Reason for implementation of Prescription + +```Prescription``` and ```Appointment``` forms a whole-part relationship and hence ```Prescription``` is suitable to be stored as a field of ```Appointment```. +```Prescription``` will also be deleted when appointment is deleted due to this whole-part relationship. As an ```Appointment``` can have multiple ```Prescription``` objects, the multiplicity is many to one. + + +#### Prescription commands +The flow of how a command for prescription is processed is shown in the diagram below. +![Activity diagram of Prescription commands](diagrams/PrescriptionActivityDiagram.png) + +##### Add Prescription command +The command structure for add prescription command follows the sequence diagram below. +![Sequence diagram diagram of Add Prescription commands](diagrams/AddPrescriptionCommandSequenceDiagram.png) + +##### Delete Prescription command sequence +The command structure for delete prescription command follows the sequence diagram below. +![Sequence diagram diagram of Delete Prescription commands](diagrams/DeletePrescriptionCommandSequenceDiagram.png) + +##### General Prescription command sequence +When `execute()` is called upon the prescriptionCommand object, the prescriptionCommand object checks if the appointment to be targeted +exists by calling the getAppointmentBook() function of the model, which returns a list of available appointments. Once verified that +the appointment to be targeted exists, the respective add/delete prescription command is called in the `Model` object. The `Model` object +then checks for the validity of the prescription command by checking for existence of the same prescription in the targeted appointment. +Once the check has been done, the prescription in question is added/removed and a CommandResult is returned. + +--- ## **Documentation, logging, testing, configuration, dev-ops** -* [Documentation guide](Documentation.md) -* [Testing guide](Testing.md) -* [Logging guide](Logging.md) -* [Configuration guide](Configuration.md) -* [DevOps guide](DevOps.md) +* [Documentation guide](https://ay2122s1-cs2103-w14-1.github.io/tp/Documentation.html) +* [Testing guide](https://ay2122s1-cs2103-w14-1.github.io/tp/Testing.html) +* [Logging guide](https://ay2122s1-cs2103-w14-1.github.io/tp/Logging.html) +* [Configuration guide](https://ay2122s1-cs2103-w14-1.github.io/tp/Configuration.html) +* [DevOps guide](https://ay2122s1-cs2103-w14-1.github.io/tp/DevOps.html) --------------------------------------------------------------------------------------------------------------------- +--- ## **Appendix: Requirements** @@ -257,121 +633,504 @@ _{Explain here how the data archiving feature will be implemented}_ **Target user profile**: -* has a need to manage a significant number of contacts -* prefer desktop apps over other types -* can type fast -* prefers typing to mouse interactions -* is reasonably comfortable using CLI apps +* Authorised staff from small family clinics (both receptionist and doctors) +* Clinic staff from clinics that lack access to cloud and are undeveloped compared to hospitals +* Clinic staff from young clinics that do not have technological capabilities +* Prefer a type-first experience, and can type fast -**Value proposition**: manage contacts faster than a typical mouse/GUI driven app +**Value proposition**: +* Provide a centralised platform for clinic staff to manage patient records, reducing man hours from managing paper documents +Today, small family clinics often record patient information using paper application forms. +Such recording of patient information results in the clinic having a messy and inefficient patient record information; +the family clinic will have to flip through files and documents in order to find the patient. Doc’it aims to provide a +centralised platform for authorised staff from small family clinics to view, update and onboard patients. +With Doc’it, small family clinics are able to reduce man hours from managing paper documents, +and translate these ‘saved’ hours into providing better frontline service to patients, focusing on what they do best. ### User stories Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*` -| Priority | As a …​ | I want to …​ | So that I can…​ | -| -------- | ------------------------------------------ | ------------------------------ | ---------------------------------------------------------------------- | -| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the App | -| `* * *` | user | add a new person | | -| `* * *` | user | delete a person | remove entries that I no longer need | -| `* * *` | user | find a person by name | locate details of persons without having to go through the entire list | -| `* *` | user | hide private contact details | minimize chance of someone else seeing them by accident | -| `*` | user with many persons in the address book | sort persons by name | locate a person easily | + +| Priority | As a … | I want to … | So that I can… | +| ---------- | ------------------------ | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | +| `* * *` | clinic staff | create new patient details | add data of new patients in our clinic | +| `* * *` | clinic staff | add medical history to patient details | have a background on the patient | +| `* * *` | clinic staff | view patient details | better prescribe medication and treatments to my out-patients | +| `* * *` | clinic staff | delete patient details | manage patients’ need for privacy when patients no longer visit the clinic | +| `* * *` | clinic staff | view the prescriptions currently prescribed to my patients | provide correct prescriptions to them | +| `* * *` | clinic staff | create new appointments from patients | track upcoming appointments | +| `* * *` | clinic staff | view appointments from patients | know at-a-glance what are the upcoming appointments and the patients involved | +| `* * *` | clinic staff | delete appointments from patients | re-organise appointments when either side cancels their appointments | +| `* * *` | clinic staff | have appointments moved to appointment history | separate what are the upcoming appointments from past appointments | +| `* * *` | clinic staff | view past appointments | track their medical history | +| `* *` | clinic staff | edit appointments from patients | ensure appointment records are up-to-date | +| `* *` | clinic staff | modify patient details | ensure that any changes in their information are up-to-date | +| `* *` | clinic staff | edit prescriptions | ensure my patients’ current prescriptions are up-to-date | +| `* *` | clinic staff | view the duration of prescriptions | decide whether they should be given additional prescriptions | +| `* *` | clinic staff | move prescriptions to prescription history when patients have finished that prescription | | +| `* *` | clinic staff | view the prescription history of patients | know what drugs my patients have taken before | +| `* *` | clinic staff | cannot edit past prescriptions | prevent erroneous edits | +| `* *` | clinic staff | verify that the patient has paid for his appointment | record that the patient has paid the bills | +| `* *` | clinic staff | input the bill and price of the patient appointment | record the amount that the patient has paid | +| `* *` | clinic staff | prevent editing past appointments | ensure past records cannot be incorrectly modified | +| `* *` | clinic staff | filter patients by name | pull up patient records easily when requested | +| `* *` | clinic staff | filter patients by the date of their appointment | know the list of patients per appointment day | +| `* *` | clinic staff | filter patients by their prescriptions | gauge the demand of prescription_drug needed by the clinic | +| `* *` | new clinic staff | go through a tutorial at the beginning | familiarise myself with how the app works and what it can do | +| `* *` | new clinic staff | type a command to get all available commands and how they work | easily refer to the commands I can make | +| `* *` | clinic staff | purge all current data | delete any experimental records | +| `* *` | long term clinic staff | use shortened command aliases | speed up my work | +| `* *` | clinic staff | easily make changes to the patient records without too many commands | my work can be done faster | +| `* *` | clinic staff | view information on an appealing GUI | view information that is neatly organised | +| `* *` | clinic staff | share a single patient database with other clinic staff | ensure all changes are synced | *{More to be added}* ### Use cases -(For all use cases below, the **System** is the `AddressBook` and the **Actor** is the `user`, unless specified otherwise) +(For all use cases below, the **System** is the ``Doc'it`` and the **Actor** is the `user`, unless specified otherwise) + +**Use case: UC01 - List all patients** + +**MSS** + +1. User requests to list patients. +2. `Doc'it` displays all patients. + + Use case ends. + +**Extensions** + +* 1a. The list is empty. + + Use case ends. + +**Use case: UC02 - Add a patient** + +**MSS** + +1. User requests to add a patient. +2. `Doc'it` adds the patient with necessary information. + + Use case ends. + +**Extensions** + +* 1a. Necessary details of patient are absent (name, address, phone number). + + * 1a1. `Doc'it` shows an error message. -**Use case: Delete a person** + Use case resumes at step 1. +* 1b. Patient details conflict with existing patient list. + + * 1b1. `Doc'it` shows an error message. + + Use case resumes at step 1. + +**Use case: UC03 - Delete a patient** **MSS** -1. User requests to list persons -2. AddressBook shows a list of persons -3. User requests to delete a specific person in the list -4. AddressBook deletes the person +1. `Doc'it` shows a list of patients. +2. User requests to delete a specific patient in the list. +3. `Doc'it` deletes the patient. - Use case ends. + Use case ends. **Extensions** * 2a. The list is empty. Use case ends. +* 2b. The given index is invalid. + + * 2b1. `Doc'it` shows an error message. + + Use case resumes at step 2. + + +**Use case: UC04 - List all appointments** + +**MSS** + +1. User requests to list appointments. +2. `Doc'it` displays all appointments. + + Use case ends. + +**Extensions** + +* 1a. The list is empty. + + Use case ends. + +**Use case: UC05 - Add an appointment** + +**MSS** + +1. `Doc'it` displays all patients. +2. User adds an appointment, matching the appointment to the specific patient. +3. `Doc'it` adds the appointment and associates it to the patient. + + Use case ends. + +**Extensions** -* 3a. The given index is invalid. +* 2a. The date of the appointment AND/OR the specified patient are invalid. - * 3a1. AddressBook shows an error message. + * 2a1. `Doc'it` shows an error message. Use case resumes at step 2. -*{More to be added}* +**Use case: UC06 - Edit an appointment** -### Non-Functional Requirements +**MSS** -1. Should work on any _mainstream OS_ as long as it has Java `11` or above installed. -2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage. -3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse. +1. `Doc'it` displays all patients and appointments. +2. User edits an appointment, specifying new appointment details to replace old appointment details. +3. `Doc'it` edits the appointment details. -*{More to be added}* + Use case ends. -### Glossary +**Extensions** -* **Mainstream OS**: Windows, Linux, Unix, OS-X -* **Private contact detail**: A contact detail that is not meant to be shared with others +* 2a. The date of the appointment AND/OR the specified patient are invalid. --------------------------------------------------------------------------------------------------------------------- + * 2a1. `Doc'it` shows an error message. -## **Appendix: Instructions for manual testing** + Use case resumes at step 2. -Given below are instructions to test the app manually. +**Use case: UC07 - Delete an appointment** -
    :information_source: **Note:** These instructions only provide a starting point for testers to work on; -testers are expected to do more *exploratory* testing. +**MSS** -
    +1. `Doc'it` displays all appointments. +2. User requests to delete a specific appointment in the list. +3. `Doc'it` deletes the appointment and removes the appointment association from the originally associated patient. -### Launch and shutdown + Use case ends. -1. Initial launch +**Extensions** - 1. Download the jar file and copy into an empty folder +* 2a. The list is empty. - 1. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum. + Use case ends. +* 2a. The given index is invalid. -1. Saving window preferences + * 2a1. `Doc'it` shows an error message. - 1. Resize the window to an optimum size. Move the window to a different location. Close the window. + Use case resumes at step 2. - 1. Re-launch the app by double-clicking the jar file.
    - Expected: The most recent window size and location is retained. +**Use case: UC08 - Archive an appointment** -1. _{ more test cases …​ }_ +**MSS** -### Deleting a person +1. `Doc'it` displays all appointments. +2. User requests to archive all appointments that are past its date. +3. `Doc'it` archives all appointments that are past its date. -1. Deleting a person while all persons are being shown + Use case ends. - 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list. +**Extensions** - 1. Test case: `delete 1`
    - Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated. +* 2a. There are no appointments in the Appointment panel. - 1. Test case: `delete 0`
    - Expected: No person is deleted. Error details shown in the status message. Status bar remains the same. + Use case ends. +* 2b. No appointments are past its date. - 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
    - Expected: Similar to previous. + Use case ends. -1. _{ more test cases …​ }_ +**Use case: UC09 - Add a prescription** -### Saving data +**MSS** -1. Dealing with missing/corrupted data files +1. User requests to list appointments. +2. `Doc'it` displays all appointments. +3. User adds a prescription, matching the prescription to the specific appointment by index. +4. Doc'it adds the prescription and associates it to the appointment. + + Use case ends. + +**Extensions** + +3a. The index of the appointment is invalid. +* 3a1. Doc'it shows an error message. + Use case resumes at step 3. +* 3b. The input field of medicine name, volume or duration is invalid. + * 3a1. Doc'it shows an error message. + Use case resumes at step 3. + +**Use case: UC010 - Delete a prescription** + +**MSS** - 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_ +1. User requests to list appointments. +2. `Doc'it` displays all appointments. +3. User deletes a prescription, matching the prescription to the specific appointment by index and medicine name. +4. Doc'it deletes the prescription -1. _{ more test cases …​ }_ + + +**Extensions** +* 3a. The index of the appointment is invalid. + * 3a1. Doc'it shows an error message. + Use case resumes at step 3. +* 3b. The input field of medicine name is invalid. + * 3a1. Doc'it shows an error message. + Use case resumes at step 3. + + +**Use case: UC11 - Add a Medical Entry to Patient** + +**MSS** + +1. `Doc'it` displays all patients. +2. User requests to add a medical entry to a specified patient. +3. `Doc'it` adds the medical entry and records the date of entry. + + Use case ends. + +**Extension** +* 2a. The given index is invalid. + * 2a1. `Doc'it` shows an error message. + Use case resumes at step 1. + +**Use case: UC12 - Delete a Medical Entry from a Patient** + +**MSS** + +1. `Doc'it` displays all patients. +2. User requests to delete a specified medical entry from a specified patient. +3. `Doc'it` deletes the specified medical entry from the patient. + + Use case ends. + +**Extensions** + +* 2a. The given index specifying the medical entry is invalid. + + * 2a1. `Doc'it` shows an error message. + + Use case resumes at step 1. + +* 2b. The given index specifying the patient is invalid. + + * 2b1. `Doc'it` shows an error message. + + Use case resumes at step 1. + +* 2c. The patient specified has an empty medical history. + + * 2c1. `Doc'it` shows an error message. + + Use case resumes at step 1. + + +**Use case: UC13 - Find patient** + +**MSS** + +1. `Doc'it` displays all patients. +2. User requests to find patients whose names or medical histories match the given set of keywords. +3. `Doc'it` lists a filtered list of patients that satisfy the keywords given by the user. + + Use case ends. + + +**Use case: UC14 - Exit program** + +**MSS** + +1. User requests to exit the program. +2. `Doc'it` saves and writes all files. +3. `Doc'it` exits and closes. + + Use case ends. + +**Extensions** + +* 2a. `Doc'it` is unable to save file. + + * 2a1. `Doc'it` shows an error message. + + Use case resumes at step 1. + +### Non-Functional Requirements + +1. Should work on any _mainstream OS_ as long as it has Java `11` or above installed. +2. Should be able to hold up to 1000 patients without noticeable sluggishness in performance for typical usage. +3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse. +4. Should not require an external installer or launcher. +5. Data should be stored locally in an easily-editable text file. +6. Should not depend on any cloud-based remote server. +7. Data should not be stored in an external Database Management System (DBMS) or data warehouse. +8. Clinic staff inexperienced in using computers should be able to easily use Doc'it. +9. The GUI should work well and not result in resolution-related inconveniences to the user for screen resolutions 1920x1080 and higher, and screen scale at 100% and 125%. +10. The GUI should be usable, defined as the ability to carry out all functions, even if resolution is not optimal, for resolutions 1280x720 and higher and screen scale at 150%. + +### Glossary + +| Term | Definition | +|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------| +| Mainstream OS | Windows, Linux, Unix, OS-X | +| Appointment | A scheduled consult between a patient and the clinic's doctor at an exact date and time. The doctor may or may not prescribe medication. | +| Archive | Storage for data that is non-urgent, e.g. appointment records that are past their date. | +| Patient Record | A record of a patient's name, phone number, address, email and medical history. | +| Prescription | The issued medication/treatment for a patient along with a duration and volume. | +| Expired Appointment | An appointment that is 24-hours past its scheduled time. | +| Medical History | A patient's set of recorded medical complications from the past. | +| Medical Entry | A specific past health complication of a patient. There can be multiple medical entries within a patient's medical history. + +--- + +## **Appendix: Instructions for manual testing** + +Given below are instructions to test the app manually. + +
    :information_source: **Note:** These instructions only provide a starting point for testers to work on; +testers are expected to do more *exploratory* testing. +
    + +### Launch and shutdown + +1. Initial launch + + 1. Download the jar file and copy into an empty folder + 2. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum. + +### Deleting a patient + +1. Deleting a patient while all patients are being shown + + 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list. + 2. Test case: `pt delete 1`
    + Expected: First patient is deleted from the list. Details of the deleted patient shown in the status message. + 3. Test case: `pt delete 0`
    + Expected: No patient is deleted. Error details shown in the status message. + 4. Other incorrect patient delete commands to try: `pt delete`, `delete 1`, `pt delete x`, `...` (where x is larger than the list size)
    + Expected: Similar to previous. + +2. Deleting a patient that has an appointment + + 1. Prerequisites: Add an appointment to that patient at index 1 e.g. `apmt add i/1 d/2022-12-31 1200` + 2. Test case: `delete 1`
    + Expected: First patient is deleted from Patient Panel. Patient's appointments in Appointment panel is deleted as well. + +### Adding a patient +1. Adding a patient + + 1. Test case: `pt add n/John Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 m/diabetes`.
    + Expected: Patient is added to the end of the list. Details of the added patient shown in the status message. + 2. Test case: `pt add p/98765432 e/johnd@example.com`.
    + Expected: No patient is added. Error details shown in the status message. + 3. Other incorrect patient add commands to try: `pt add`, `add 1`, `pt add m/diabetes`, `...` + Expected: Similar to previous. + +### Editing a patient +1. Editing a patient + 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list. + 2. Test case: `pt edit 1 n/Joshen Lim`
    + Expected: Name of first patient is edited. Details of the edited patient shown in the status message. + 3. Test case: `pt edit 1 n/`
    + Expected: No edit is executed. Error details shown in the status message. + 4. Other incorrect patient add commands to try: `pt edit`, `edit 1 n/Joshen Lim`, `pt edit x`, `...` (where x is larger than the list size)
    + Expected: Similar to previous. + +### Adding a Medical Entry to a Patient's Medical History +1. Adding a medical Entry + 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list. + 2. Test case: `pt ma 1 m/diabetes`
    + Expected: Medical History of first patient has the new medical entry added to the back of the list. The medical entry should have the corresponding date recorded. Details of the patient shown in the status message. + 3. Test case: `pt ma 1 i/`
    + Expected: No medical entry is added. Error details shown in the status message. + 4. Other incorrect patient add commands to try: `pt ma`, `ma 1 m/high blood pressure`, `pt ma x m/lovesick`, `...` (where x is larger than the list size)
    + Expected: Similar to previous. + +### Deleting a Medical Entry from a Patient's Medical History +1. Deleting a medical entry from a patient's non-empty medical history + 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list. + 2. Test case: `pt md 1 i/1`
    + Expected: Medical Entry of the specified index within the Medical History of first patient is deleted. If there are other entries within the Medical History, the list of entries will re-index from 1. If there are no other entries within the Medical History, "No medical history recorded." is shown on the Patient Card. Details of the patient shown in the status message. + 3. Test case: `pt md 1 i/`
    + Expected: No medical entry is deleted. Error details shown in the status message. + 4. Other incorrect patient add commands to try: `pt md`, `md 1 i/1`, `pt md x i/1`, `pt md 1 i/x`, `...` (where x is larger than the list size)
    + Expected: Similar to previous. + +2. Deleting a medical entry from a patient's with an empty medical history + 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list. + 2. Test case: `pt md 1 i/1`
    + Expected: Nothing is changed. Status message reflects that there is "No medical history record to delete from the patient". + 3. Test case: `pt md 1 i/`
    + Expected: Nothing is changed. Error details shown in the status message. + 4. Other incorrect patient add commands to try: `pt md`, `md 1 i/1`, `pt md x i/1`, `pt md 1 i/x`, `...` (where x is larger than the list size)
    + Expected: Similar to previous. + +### Saving data + +1. Dealing with missing/corrupted data files + 1. If JSON files are missing, `Doc'it` will start with a sample AddressBook and AppointmentBook with sample Patients and sample Appointments respectively. + 2. If JSON files are corrupted, `Doc;it` will start with a blank address book and blank appointment book. + 2. Save appointment + 1. Prerequisite: Create an appointment e.g. `apmt add i/1 d/2022-12-31 1200` + 2. Test case: Close and reopen the application
    + Expected: Appointments reference the same patients as previous session before it was closed. + +### Adding an appointment + +Prerequisites: Use sample addressbook or the same list of patients from index 1 to 2. +1. Test case: `apmt add i/1 d/2999-12-31 2359`
    + Expected: New appointment added in Upcoming tab of Appointments panel for Patient 1 on 31 Dec 2999 2359. +2. Test case: Conduct test case 1, then enter `apmt add i/2 d/2999-12-31 2359`
    + Expected: New appointment added in Upcoming tab of Appointments panel for Patient 2 on 31 Dec 2999 2359 even if test case 1 appointment exists. +3. Test case: `apmt add i/1 d/2000-1-1 0000`
    + Expected: New appointment added in Archived tab of Appointments panel for Patient 1 on 1 Jan 2000 0000. +4. Test case: Conduct test case 3, then enter `apmt add i/2 d/2000-1-1 0000`
    + Expected: New appointment added in Archived tab of Appointments panel for Patient 2 on 1 Jan 2000 0000 even if test case 3 appointment exists. +5. Test case: `apmt add i/1 d/2039-2-29 1200`
    + Expected: No new appointment is created because 2039 is not a leap year and Feb 2039 only has 28 days. Error message shown. + +Editing an appointment test cases are similar to adding an appointment except for an additional appointment index to be specified before Patient Index and Datetime. + +### Deleting an appointment + +1. Deleting an appointment while all appointments are being shown + + 1. Prerequisites: List all appointments in the Upcoming tab using the `apmt list` command. At least one appointment in list. + 2. Test case: `apmt delete 1`
    + Expected: First appointment is deleted from the list. Details of the deleted appointment shown in the status message. + 3. Test case: `apmt delete 0`
    + Expected: No appointment is deleted. Error details shown in the status message. + 4. Other incorrect delete commands to try: `apmt delete`, `apmt delete x`, `...` (where x is larger than the list size)
    + Expected: Similar to previous. + + +### Adding a prescription +Prerequisites: All test cases below must be independent and fulfills these assumptions: +All appointments listed using the `apmt list` command. 5 appointments shown in the list. All appointments have no prescriptions. +1. Test case: `apmt pa 1 n/Penicillin v/400 ml d/2 times a week`
    + Expected: First appointment now contains a prescription label `penicillin | 400ml | 2 times a week`. +2. Test case: enter `apmt pa 1 n/Penicillin v/400 ml d/2 times a week` twice
    + Expected: No new prescription is created. Error message `Operation would result in duplicate prescriptions` is shown. +3. Test case: `apmt pa 1 n/PenicillinPenicillinPenicillin v/400 ml d/2 times a week`
    + Expected: No new prescription is created. Error message `Medicine name can only be 20 characters long.` is shown. +4. Test case: `apmt pa 1 n/Penicillin v/400000000000000000000 ml d/2 times a week`
    + Expected: No new prescription is created. Error message `Volume can only be 20 characters long.` is shown. +5. Test case: `apmt pa 1 n/Penicillin v/400 ml d/99999999999999999999999999999999 times a week `
    + Expected: No new prescription is created. Error message `Duration can only be 40 characters long.` is shown. +6. Test case: `apmt pa 0 n/Penicillin v/400 ml d/2 times a week `
    + Expected: No new prescription is created. Error message `Index is not a non-zero unsigned integer.` is shown. +7. Test case: `apmt pa 6 n/Penicillin v/400 ml d/2 times a week `
    + Expected: No new prescription is created. Error message `The appointment index provided is invalid.` is shown. + +### Deleting a prescription +Prerequisites: All test cases below must be independent and fulfills these assumptions: +All appointments listed using the `apmt list` command. Multiple appointments shown in the list. +First appointment has a single prescription `penicillin | 400ml | 2 times a week`. All other appointments have no prescriptions. +1. Test case: `apmt pd 1 n/Penicillin`
    + Expected: First appointment now do not contain any prescriptions. +2. Test case: enter `apmt pa 0 n/Penicillin` twice
    + Expected: No new prescription is created. Error message `Index is not a non-zero unsigned integer.` is shown. +3. Test case: `apmt pa 1 n/Panadol`
    + Expected: No new prescription is created. Error message `Medicine name not found in prescription list.` is shown. diff --git a/docs/SettingUp.md b/docs/SettingUp.md index 275445bd551..9ddcd45d18a 100644 --- a/docs/SettingUp.md +++ b/docs/SettingUp.md @@ -23,7 +23,7 @@ If you plan to use Intellij IDEA (highly recommended): 1. **Import the project as a Gradle project**: Follow the guide [_[se-edu/guides] IDEA: Importing a Gradle project_](https://se-education.org/guides/tutorials/intellijImportGradleProject.html) to import the project into IDEA.
    :exclamation: Note: Importing a Gradle project is slightly different from importing a normal Java project. 1. **Verify the setup**: - 1. Run the `seedu.address.Main` and try a few commands. + 1. Run the `seedu.docit.Main` and try a few commands. 1. [Run the tests](Testing.md) to ensure they all pass. -------------------------------------------------------------------------------------------------------------------- diff --git a/docs/Testing.md b/docs/Testing.md index 8a99e82438a..e3d24a62b0b 100644 --- a/docs/Testing.md +++ b/docs/Testing.md @@ -29,8 +29,8 @@ There are two ways to run tests. This project has three types of tests: 1. *Unit tests* targeting the lowest level methods/classes.
    - e.g. `seedu.address.commons.StringUtilTest` + e.g. `seedu.docit.commons.StringUtilTest` 1. *Integration tests* that are checking the integration of multiple code units (those code units are assumed to be working).
    - e.g. `seedu.address.storage.StorageManagerTest` + e.g. `seedu.docit.storage.StorageManagerTest` 1. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
    - e.g. `seedu.address.logic.LogicManagerTest` + e.g. `seedu.docit.logic.LogicManagerTest` diff --git a/docs/UserGuide.md b/docs/UserGuide.md index 3716f3ca8a4..6a38cd6d297 100644 --- a/docs/UserGuide.md +++ b/docs/UserGuide.md @@ -3,40 +3,125 @@ layout: page title: User Guide --- -AddressBook Level 3 (AB3) is a **desktop app for managing contacts, 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, AB3 can get your contact management tasks done faster than traditional GUI apps. - -* Table of Contents -{:toc} +![Doc'it icon](images/DocitHeader.png) + +`Doc'it` provides a centralised platform for authorised staff from small family clinics to view, update, and onboard +patient records, solving the inefficient paper records and files used today. With `Doc'it`, small family clinics can +reduce man-hours in managing paper files, translating this saved time into better front-line care services. + +#### Table of Contents + +1. [Quick Start](#quick-start) +2. [Overview of Features](#overview-of-features) + 1. [Basic Commands](#general-commands) + - [Clear all records](#clear-all-records-doc-clear) + - [Help](#help-doc-help) + - [Exit the program](#exit-the-program-doc-exit) + 2. [Patient-related Commands](#patient-commands) + - [Add a patient](#add-a-patient-pt-add) + - [List all patients](#list-all-patients-pt-list) + - [Edit a patient](#edit-a-patient-pt-edit) + - [Delete a patient](#delete-a-patient-pt-delete) + - [Add to medical history](#add-a-medical-history-pt-ma) + - [Delete to medical history](#delete-a-medical-history-pt-md) + - [Find patient\(s\)](#find-a-patient-with-keywords-pt-find-keywords) + 3. [Appointment-related Commands](#appointment-commands) + - [Add an appointment](#add-an-appointment-apmt-add) + - [List all appointments](#list-all-appointments-apmt-list) + - [List all archived appointments](#list-all-archived-appointments-apmt-alist) + - [Edit an appointment](#edit-an-appointment-apmt-edit) + - [Delete an appointment](#delete-an-appointment-apmt-delete) + - [Archive an appointment](#archive-an-appointment-apmt-archive) + - [Sort all appointments](#sort-all-appointments-apmt-sort) + - [Add prescription](#add-prescription-apmt-pa) + - [Delete prescription](#delete-prescription-apmt-pd) +4. [FAQ](#faq) +5. [Command Summary](#command-summary) +6. [Glossary](#glossary) -------------------------------------------------------------------------------------------------------------------- ## Quick start - 1. Ensure you have Java `11` or above installed in your Computer. -1. Download the latest `addressbook.jar` from [here](https://github.com/se-edu/addressbook-level3/releases). +2. Download the latest `docit.jar` from [here](https://github.com/AY2122S1-CS2103-W14-1/tp/releases). -1. Copy the file to the folder you want to use as the _home folder_ for your AddressBook. +3. Copy the file to the folder you want to use as the _home folder_ for your `Doc'it`. -1. Double-click the file to start the app. The GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
    +4. Double-click the file to start the app. The GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
    +
    ![Ui](images/Ui.png) -1. Type the command in the command box and press Enter to execute it. e.g. typing **`help`** and pressing Enter will open the help window.
    +5. Type the command in the command box and press Enter to execute it. e.g. typing **`doc help`** and pressing Enter will open the help window.
    Some example commands you can try: - * **`list`** : Lists all contacts. + * **`pt list`** : Lists all patients. - * **`add`**`n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` : Adds a contact named `John Doe` to the Address Book. + * **`doc exit`** : Exits the app. - * **`delete`**`3` : Deletes the 3rd contact shown in the current list. +6. Refer to the **Features** section below for details of each command. +this on +7. Doc'it is built specifically for small clinic staff based in Singapore. Hence, the date and time run in Singapore time. - * **`clear`** : Deletes all contacts. +-------------------------------------------------------------------------------------------------------------------- - * **`exit`** : Exits the app. +## Overview of Features -1. Refer to the [Features](#features) below for details of each command. +
    + +This section provides a brief overview of `Doc'it`. The intention is for users to gain a better +understanding of basic functionalities of `Doc'it`, before diving into specific commands. + +
    + +1. **Basic functionality** + 1. Clear all records + 2. Get Help + 3. Exit app +2. **Managing Patient Records** + 1. Create a new Patient Record + 2. View details of Patient Record + 3. Delete Patient Record + 4. Edit Patient Record + 5. Add Medical History from a Patient Record + 6. Delete Medical History of a Patient Record + 7. Find filtered patient records based on keywords +3. **Managing Patient Appointments** + 1. Create a new appointment + 2. View appointment + 3. Delete appointment + 4. Archive appointment + 5. List appointments + 6. Sort appointments (in order of urgency) + 7. Managing appointment prescriptions + 1. Add prescription + 2. Remove prescription + +##Navigating Doc'it +This section details the various components of Doc'it interface and how you could go about navigating Doc'it. + + ![Navigability](images/Navigability.png) + +### Patient View +![Navigability](images/PatientView.png) +In this view, you can view all Patients. Each Patient has a name, phone number, address, email and a Medical History. + +All patient-related commands will have change parts of the Patient View. + +### Appointment View +![Navigability](images/AppointmentView.png) +In this view, you can view all Appointments. Each Appointment has the patient, date and time. + +The AppointmentView comprises of two types of Appointments: Upcoming and Archive. Upcoming appointments are scheduled appointments, while Archived appointments are previous appointments that have been archived. You can switch between the two with the `apmt list` and `apmt alist` command. Alternatively, you could also click on the corresponding tab. + +### Command Result Status Display +![Navigability](images/CommandResultStatusDisplay.png) +In this component, you can view the messages and feedback from Doc'it after every command. + +### Command Box +![Navigability](images/CommandBox.png) +This is the component where you will input your commands. After inputting your commands, you may click the `Enter` key on your keyboard. Alternatively, you can click the `Send` button displayed here. --------------------------------------------------------------------------------------------------------------------- ## Features @@ -48,145 +133,442 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo e.g. in `add n/NAME`, `NAME` is a parameter which can be used as `add n/John Doe`. * Items in square brackets are optional.
    - e.g `n/NAME [t/TAG]` can be used as `n/John Doe t/friend` or as `n/John Doe`. + e.g. `n/NAME [m/MEDICAL_HISTORY]` can be used as `n/John Doe m/cancer` or as `n/John Doe`. -* Items with `…`​ after them can be used multiple times including zero times.
    - e.g. `[t/TAG]…​` can be used as ` ` (i.e. 0 times), `t/friend`, `t/friend t/family` etc. +* Items with `…` after them can be used multiple times including zero times.
    + e.g. `[m/MEDICAL_HISTORY]… ` can be used as ` ` (i.e. 0 times), `m/Diabetes`, `m/Scoliosis m/High Blood Pressure` etc. * Parameters can be in any order.
    e.g. if the command specifies `n/NAME p/PHONE_NUMBER`, `p/PHONE_NUMBER n/NAME` is also acceptable. -* If a parameter is expected only once in the command but you specified it multiple times, only the last occurrence of the parameter will be taken.
    +* If a parameter is expected only once in the command, but you specified it multiple times, only the last occurrence of the parameter will be taken.
    e.g. if you specify `p/12341234 p/56785678`, only `p/56785678` will be taken. * Extraneous parameters for commands that do not take in parameters (such as `help`, `list`, `exit` and `clear`) will be ignored.
    e.g. if the command specifies `help 123`, it will be interpreted as `help`. +* `INDEX` must a positive integer of the given item in the panel. + +* `DATETIME` must be in the format `yyyy-mm-dd HHmm` for all commands, with time using 24-Hour notation.
    + e.g. `2021-10-28 1530` indicates 28 Oct 2021 at 3.30pm +
    -### Viewing help : `help` +-------------------------------------------------------------------------------------------------------------------- -Shows a message explaning how to access the help page. +## Basic Commands +This section covers basic application-related commands. All of these commands have `doc` in front of them. -![help message](images/helpMessage.png) +### Clear all records: `doc clear` -Format: `help` +Clears all patient records and appointment records (upcoming and archived). This is an irreversible operation. +Format: `doc clear` -### Adding a person: `add` +--- -Adds a person to the address book. +### Help: `doc help` -Format: `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…​` +Shows the user manual for `Doc'it` explaining how to access the help page. -
    :bulb: **Tip:** -A person can have any number of tags (including 0) -
    +Format: `doc help` -Examples: -* `add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` -* `add n/Betsy Crowe t/friend e/betsycrowe@example.com a/Newgate Prison p/1234567 t/criminal` +![DocHelp](images/DocHelp.png) -### Listing all persons : `list` +--- -Shows a list of all persons in the address book. +### Exit the program: `doc exit` -Format: `list` +Exits the program. -### Editing a person : `edit` +Format: `doc exit` -Edits an existing person in the address book. +--- -Format: `edit INDEX [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [t/TAG]…​` +## Patient Commands +Patient is the primary entity in `Doc'it`. This section documents how to perform create, update, read and delete operations on patient +records. -* Edits the person at the specified `INDEX`. The index refers to the index number shown in the displayed person list. The index **must be a positive integer** 1, 2, 3, …​ -* At least one of the optional fields must be provided. -* Existing values will be updated to the input values. -* When editing tags, the existing tags of the person will be removed i.e adding of tags is not cumulative. -* You can remove all the person’s tags by typing `t/` without - specifying any tags after it. +>:information_source: All patient-related commands have the keyword `pt` in front of them. -Examples: -* `edit 1 p/91234567 e/johndoe@example.com` Edits the phone number and email address of the 1st person to be `91234567` and `johndoe@example.com` respectively. -* `edit 2 n/Betsy Crower t/` Edits the name of the 2nd person to be `Betsy Crower` and clears all existing tags. +### Add a patient: `pt add` -### Locating persons by name: `find` +Creates a new patient record. -Finds persons whose names contain any of the given keywords. +**Format:** `pt add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [m/MEDICAL_HISTORY]...` -Format: `find KEYWORD [MORE_KEYWORDS]` +- `MEDICAL_HISTORY` is optional; if `MEDICAL_HISTORY` is not given, an empty string of text will be used. +- `MEDICAL_HISTORY` can be added multiple times within a single `pt add` command, as indicated by the ```...``` used. -* The search is case-insensitive. e.g `hans` will match `Hans` -* The order of the keywords does not matter. e.g. `Hans Bo` will match `Bo Hans` -* Only the name is searched. -* Only full words will be matched e.g. `Han` will not match `Hans` -* Persons matching at least one keyword will be returned (i.e. `OR` search). - e.g. `Hans Bo` will return `Hans Gruber`, `Bo Yang` +**Examples:** +- `pt add n/Joshen Lim p/99998888 e/joshen@gmail.com a/123 Clementi Road SG293821` -Examples: -* `find John` returns `john` and `John Doe` -* `find alex david` returns `Alex Yeoh`, `David Li`
    - ![result for 'find alex david'](images/findAlexDavidResult.png) +**Expected Outcome:** +``` +New patient added: +Joshen Lim; Phone: 99988888; Email: joshen@gmail.com; Address: 123 Clementi Road SG293821 +``` -### Deleting a person : `delete` +**GUI Display:** +![PtAdd](images/PtAdd.png) -Deletes the specified person from the address book. -Format: `delete INDEX` +--- -* Deletes the person at the specified `INDEX`. -* The index refers to the index number shown in the displayed person list. -* The index **must be a positive integer** 1, 2, 3, …​ +### List all patients: `pt list` -Examples: -* `list` followed by `delete 2` deletes the 2nd person in the address book. -* `find Betsy` followed by `delete 1` deletes the 1st person in the results of the `find` command. +Shows a list of all patients in the record system. -### Clearing all entries : `clear` +Format: `pt list` -Clears all entries from the address book. +**Expected Outcome:** +``` +Listed all patients +``` -Format: `clear` +**GUI Display:** +![Patient Card](images/PatientCard.png) +--- -### Exiting the program : `exit` +### Edit a patient: `pt edit` -Exits the program. +Edits the details of a specified patient. -Format: `exit` +**Format:** `pt edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [m/MEDICAL_HISTORY]` +- All fields are optional but if stated, must not be null or empty +- `INDEX` is compulsory when making an edit to patient details -### Saving the data +**Examples:** +- `pt edit 1 n/Joshen Tan m/Heartache` -AddressBook data are saved in the hard disk automatically after any command that changes the data. There is no need to save manually. +**Expected outcome:**
    +``` +Edited Patient: +Joshen Tan; Phone: 12345678; Email: google@gmail.com; Address: 311 clementi SG540192; Medical History: Heartache, recorded 31 Oct 2021 +``` -### Editing the data file +--- -AddressBook data are saved as a JSON file `[JAR file location]/data/addressbook.json`. Advanced users are welcome to update data directly by editing that data file. +### Delete a patient: `pt delete` -
    :exclamation: **Caution:** -If your changes to the data file makes its format invalid, AddressBook will discard all data and start with an empty data file at the next run. -
    +Deletes a patient record, including all information about the patient. + +**Format:** `pt delete INDEX` + +- Deletes the patient at the specified `INDEX` (one-indexed). + +**Examples:** +``` +pt list +pt delete 1 +``` + +**Expected Outcome:** +``` +Deleted patient: +Joshen Tan; Phone: 12345678; Email: google@gmail.com; Address: 311 clementi SG540192; Medical History: Heartache, recorded 31 Oct 2021 +``` + +--- + +### Add a Medical Entry: `pt ma` + +Adds a medical entry to the Medical History of a Patient Record, saving the medical history and ```today``` as the date of entry. + +**Format:** `pt ma INDEX m/MEDICAL_HISTORY...` + +- Adds a medical history to the patient at the specified `INDEX` (one-indexed). +- Multiple entries of medical history can be added in one command: e.g. `m/Diabetes`, `m/Scoliosis m/High Blood Pressure` etc. +- `m/MEDICAL_HISTORY` is a required field in this command + +**Examples:** +``` +pt list +pt ma 1 m/diabetes +``` + +**Expected Outcome:** +``` +Updated: +Charlotte Oliveiro; Phone: 93210283; Email: charlotte@example.com; Address: Blk 11 Ang Mo Kio Street 74, #11-04; Medical History: diabetes, recorded 8 Nov 2021 +``` + +**GUI Display:** +![Add Medical History](images/AddMedicalHistory.png) + +**Restrictions:** +- Can only add up to 8 medical entries per patient +- Each medical entry can only have up to 50 characters + +--- + +### Delete a Medical History: `pt md` + +Deletes a medical history to the Patient Record. + +**Format:** `pt md INDEX i/MEDICAL_HISTORY_INDEX` + +- Deletes a medical history from the patient at the specified `INDEX` (one-indexed). The entry deleted is specified by the `MEDICAL_HISTORY_INDEX` + +**Examples:** +- `pt md 1 i/1` + +**Expected Outcome:** +``` +Updated: +Charlotte Oliveiro; Phone: 93210283; Email: charlotte@example.com; Address: Blk 11 Ang Mo Kio Street 74, #11-04 +``` + +--- + +### Find a Patient with keywords: `pt find [keywords...]` + +Finds all patients that match any one of the keywords listed. These keywords can come from +either the Patient's Name or Medical History. + +**Format:** `pt find [keywords...]` + +- Finds all patients that match any one of the keywords listed. + +**Examples:** +- `pt find Alex David diabetes high blood pressure` + +**Expected Outcome:** +``` +4 patients listed! +``` + +--- -### Archiving data files `[coming in v2.0]` +## Appointment Commands +A patient in `Doc'it` may have appointments to visit the clinic. -_Details coming soon ..._ +In the Appointments panel, upcoming appointments are shown in the Upcoming tab, and past appointments are archived in the Archived tab. + +One appointment stores these details: +* Index of patient: The index of an existing patient in the Patients panel +* Date and time: The date and time of the appointment + +>:information_source: All appointment-related commands have the keyword `apmt` in front of them. +These commands modify the Appointments panel of `Doc'it`. + +### Add an appointment: `apmt add` +Adds an appointment for the patient at the specified index in the Patients panel. + +**Format:** `apmt add i/PATIENT_INDEX d/DATETIME` + +- `PATIENT_INDEX`: Index of patient who should have this appointment +- `DATETIME`: Date and time of appointment in format `yyyy-mm-dd HHmm` + - Year must be between 2000 to 2999 inclusive. + +**Examples:** +* `apmt add i/1 d/2021-10-05 1500` adds appointment on 5 Oct 2021 at 3pm to patient at index 1. +* `apmt add i/2 d/2022-12-31 0700` adds appointment on 31 Dec 2022 at 7am to patient at index 2. + +**Example Usage:** +- `apmt add i/1 d/2021-12-28 1500` + +**Expected Outcome:** +``` +New appointment added: +Patient: Alex Yeoh; Datetime: 28 Dec 2021 1500; Prescription: [] +``` + +### List all appointments: `apmt list` +Shows the list of all appointments. + +**Format:** `apmt list` + +**Examples:** +* `apmt list` Lists all appointments. + +**GUI Display:** +![Appointment Card](images/AppointmentCard.png) + +### List all archived appointments: `apmt alist` +Shows the list of all archived appointments. + +**Format:** `apmt alist` + +**Examples:** +* `apmt alist` Lists all archived appointments. + +**GUI Display:** +![Show Archived](images/ShowArchiveAppointments.png) + +### Edit an appointment: `apmt edit` + +Edits the details of an appointment at the specified index in the Appointments panel. + +**Format:** `apmt edit APMT_INDEX [i/PATIENT_INDEX] [d/DATETIME]` + +- `APMT_INDEX`: Index of appointment in the Appointments panel +- `PATIENT_INDEX`: Index of patient who should have this appointment +- `DATETIME`: Date and time of appointment in format `yyyy-mm-dd HHmm` + - Year must be between 2000 to 2999 inclusive. +- At least one of the optional fields should be present + +> :bulb: Use `i/PATIENT_INDEX` to change whose appointment it belongs to.
    +> e.g. `apmt edit 1 i/2` modifies the first appointment to belong to the patient at index 2 + +**Examples:** +- `apmt edit 1 i/2` +- `apmt edit 1 d/2021-10-28 1500` +- `apmt edit 1 i/1 d/2021-10-28 1500` + +**Example Usage:** +- `apmt edit 1 i/1 d/2021-12-25 1500` + +**Expected Outcome:** +``` +Edited Appointment: +Patient: Alex Yeoh; Datetime: 25 Dec 2021 1500; Prescription: [] +``` + + +### Delete an appointment: `apmt delete` +Deletes the appointment at the specified index in the Appointments panel. + +**Format:** `apmt delete INDEX` +* Deletes the appointment at the specified INDEX. +* The index refers to the index number shown in the displayed appointment list. +* The index must be a positive integer 1, 2, 3, ... + +**Examples:** +* `apmt list` Display Upcoming appointments tab. +* `apmt delete 1` Deletes appointment at index 1. + +**Example Usage:** +- `apmt delete 1` + +**Expected Outcome:** +``` +Deleted Appointment: +Patient: Alex Yeoh; Datetime: 28 Oct 2021 1500; Prescription: [] + +``` + + +### Archive an appointment: `apmt archive` +Archives an old appointment that is already past its date. + +**Format:** `apmt archive INDEX` +* Archives the appointment at the specified INDEX. +* The index refers to the index number shown in the displayed appointment list. +* The index must be a positive integer 1, 2, 3, ... + +**Examples:** +* `apmt archive 1` Archives appointment at index 1. + +**Expected Outcome:** +``` +Archived Appointment: +Patient: Alex Yeoh; Datetime: 31 Dec 2012 1200; Prescription: [] +``` + +### Sort all appointments: `apmt sort` +Shows a sorted list of all appointments based on urgency (appointments today > ascending date > ascending name). + +**Format:** `apmt sort` + +**Examples:** +* `apmt sort` Lists all sorted appointments. + +**GUI Display:** +![Sorted Appointments](images/SortAppointments.png) + +## Add prescription: `apmt pa` +Adds a prescription to the designated appointment. + + +**Format:** `apmt pa APMT_INDEX n/MEDICINE_NAME v/MEDICINE_VOLUME d/MEDICINE_DURATION` +* The names of medicine added to the prescription list must be unique. + +**Examples:** +* `apmt pa 1 n/Penicillin v/400 ml d/2 times a week` + +**Expected Outcome:** +``` +New prescription added: +Medicine: Penicillin +Volume: 400 ml +Duration: 2 times a week +``` + +**GUI Display:** +![Add Prescription](images/AddPrescription.png) + +## Delete prescription: `apmt pd` +Deletes a prescription from the designated appointment. + +**Format:** `apmt pd APMT_INDEX n/MEDICINE_NAME` + +**Examples:** +* `apmt pd 1 n/panadol` + +**Expected Outcome:** +``` +Deleted prescription: +Medicine: panadol + +from John Doe's appointment. +``` -------------------------------------------------------------------------------------------------------------------- ## FAQ **Q**: How do I transfer my data to another Computer?
    -**A**: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous AddressBook home folder. +**A**: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous `Doc'it` home folder. -------------------------------------------------------------------------------------------------------------------- ## Command summary -Action | Format, Examples ---------|------------------ -**Add** | `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…​`
    e.g., `add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague` -**Clear** | `clear` -**Delete** | `delete INDEX`
    e.g., `delete 3` -**Edit** | `edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]…​`
    e.g.,`edit 2 n/James Lee e/jameslee@example.com` -**Find** | `find KEYWORD [MORE_KEYWORDS]`
    e.g., `find James Jake` -**List** | `list` -**Help** | `help` +### Basic Commands + +| Command | Format | +|-------------|---------------| +| User Manual | `doc help` | +| Clear | `doc clear` | +| Exit | `doc exit` | + +### Patient-related Commands + +| Command | Format | Example | +|---------|-------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------| +| Add | `pt add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [m/MEDICAL_HISTORY]...` | `pt add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 m/cancer` | +| Delete | `pt delete INDEX` | `pt delete 3` | +| Edit | `pt edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [m/MEDICAL_HISTORY]` | `pt edit 2 n/James Lee e/jameslee@example.com` | +| Find | `pt find n/NAME` | `pt find n/James Jake` | +| List | `pt list` | - | +| Add Medical History | `pt ma INDEX m/MEDICAL_HISTORY` | `pt ma 1 m/diabetes` | +| Delete Medical History | `pt md INDEX i/MEDICAL_HISTORY_INDEX` | `pt md 1 i/1` | + +### Appointment and Prescription-related Commands + +| Command | Format | Example | +|----------------------|-------------------------------------------------------------------|--------------------------------------------------------| +| Add | `apmt add INDEX d/DATETIME` | `apmt add 1 d/2021-10-05 1600` | +| Edit | `apmt edit APMT_INDEX [i/PATIENT_INDEX] [d/DATETIME]` | `apmt edit 1 d/2021-10-05 1600` | +| Delete | `apmt delete INDEX` | `apmt delete 1` | +| Archive | `apmt archive INDEX` | `apmt archive 1` | +| List | `apmt list` | - | +| List Archived | `apmt alist` | - | +| Sort | `apmt sort` | - | +| Add Prescription | `apmt pa APPOINTMENT_INDEX n/MEDICINE v/VOLUME d/DURATION ` | `apmt pa 1 n/Penicillin v/400 ml d/2 times a week ` | +| Delete Prescription | `apmt pd APPOINTMENT_INDEX n/MEDICINE` | `apmt pd 1 n/Penicillin ` | + +-------------------------------------------------------------------------------------------------------------------- + +## Glossary + +| Term | Definition | +|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------| +| Appointment | A scheduled consult between a patient and the clinic's doctor at an exact date and time. The doctor may or may not prescribe medication. | +| Archive | Storage for data that is non-urgent, e.g. appointment records that are past their date. | +| Patient Record | A record of a patient's name, phone number, address, email and medical history. | +| Prescription | The issued medication/treatment for a patient along with a duration and volume. | +| Expired Appointment | An appointment that is 24-hours past its scheduled time. | +| Medical History | A list of past medical conditions faced by a patient. Each medical condition is stored as a Medical Entry. | +| Medical Entry | Description of the past medical condition of a patient, with a date of record when the entry was recorded. | diff --git a/docs/_config.yml b/docs/_config.yml index 6bd245d8f4e..c42d6b04820 100644 --- a/docs/_config.yml +++ b/docs/_config.yml @@ -1,4 +1,4 @@ -title: "AB-3" +title: "Doc'it" theme: minima header_pages: @@ -8,7 +8,7 @@ header_pages: markdown: kramdown -repository: "se-edu/addressbook-level3" +repository: "AY2122S1-CS2103-W14-1/tp" github_icon: "images/github-icon.png" plugins: diff --git a/docs/_sass/minima/_base.scss b/docs/_sass/minima/_base.scss index 0d3f6e80ced..e280cedfdb2 100644 --- a/docs/_sass/minima/_base.scss +++ b/docs/_sass/minima/_base.scss @@ -288,7 +288,7 @@ table { text-align: center; } .site-header:before { - content: "AB-3"; + content: "Doc'it"; font-size: 32px; } } diff --git a/docs/diagrams/AddAppointmentSequenceDiagram.png b/docs/diagrams/AddAppointmentSequenceDiagram.png new file mode 100644 index 00000000000..3f3e43f0a41 Binary files /dev/null and b/docs/diagrams/AddAppointmentSequenceDiagram.png differ diff --git a/docs/diagrams/AddAppointmentSequenceDiagram.puml b/docs/diagrams/AddAppointmentSequenceDiagram.puml new file mode 100644 index 00000000000..a614428b44e --- /dev/null +++ b/docs/diagrams/AddAppointmentSequenceDiagram.puml @@ -0,0 +1,49 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":AddAppointmentCommand" as AddAppointmentCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":Model" as Model MODEL_COLOR +participant "lastShownList:LastShownList" as LastShownList MODEL_COLOR +participant "toAdd:Appointment" as Appointment MODEL_COLOR +end box + +[-> AddAppointmentCommand : execute() +activate AddAppointmentCommand + +AddAppointmentCommand -> Model : getFilteredPatientList() +activate Model + +Model --> AddAppointmentCommand : lastShownList +deactivate Model + +AddAppointmentCommand -> LastShownList : get(targetPatientIndex) +activate LastShownList +LastShownList ---> AddAppointmentCommand : patientToMakeAppointment +deactivate LastShownList + +create Appointment +AddAppointmentCommand -> Appointment +activate Appointment +Appointment ---> AddAppointmentCommand +deactivate Appointment + +AddAppointmentCommand -> Model : addAppointment(toAdd) +activate Model +Model ---> AddAppointmentCommand +deactivate Model + +create CommandResult +AddAppointmentCommand -> CommandResult +activate CommandResult +CommandResult ---> AddAppointmentCommand +deactivate CommandResult + +[<--AddAppointmentCommand : result +deactivate AddAppointmentCommand + +@enduml diff --git a/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.png b/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.png new file mode 100644 index 00000000000..79e16ad3ca8 Binary files /dev/null and b/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.png differ diff --git a/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.puml b/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.puml new file mode 100644 index 00000000000..99344ff9f35 --- /dev/null +++ b/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.puml @@ -0,0 +1,16 @@ +@startuml + +start +:User inputs Add Medical Feature command; +if () then ([user input is valid]) +: Find specified target patient from Patient Book; +: Produce patient copy of target patient; +: Add medical entry into patient copy's medical history; +: Replace target patient in Patient Book with the patient copy; +: Display updated Patient Book; +else ([else]) +: Display Error Message; +endif +stop + +@enduml diff --git a/docs/diagrams/AddMedicalEntryFeatureClassDiagram.png b/docs/diagrams/AddMedicalEntryFeatureClassDiagram.png new file mode 100644 index 00000000000..f6b8780ee18 Binary files /dev/null and b/docs/diagrams/AddMedicalEntryFeatureClassDiagram.png differ diff --git a/docs/diagrams/AddMedicalEntryFeatureClassDiagram.puml b/docs/diagrams/AddMedicalEntryFeatureClassDiagram.puml new file mode 100644 index 00000000000..cadd4696950 --- /dev/null +++ b/docs/diagrams/AddMedicalEntryFeatureClassDiagram.puml @@ -0,0 +1,52 @@ +@startuml +!include style.puml +skinparam arrowThickness 1.1 +skinparam arrowColor LOGIC_COLOR + +Package Model { +Package Patient { +class Patient MODEL_COLOR { +} +class MedicalHistory MODEL_COLOR { +} +} +} +Patient *-down-> "1"MedicalHistory MODEL_COLOR : contains > + +Package Logic <> { + +Package Parser { +class AddMedicalEntryCommandParser LOGIC_COLOR { +} +class "<>\nPatientParser" as PatientParser LOGIC_COLOR { +} +class PatientBookParser LOGIC_COLOR { +} +class AddressBookParser LOGIC_COLOR { +} +} + +AddMedicalEntryCommandParser -up[dashed]-|> PatientParser +AddressBookParser *--> PatientBookParser +PatientBookParser -[dashed]-> AddMedicalEntryCommandParser : creates > + +Package Command { +class PatientCommand LOGIC_COLOR { +} +class AddMedicalEntryCommand LOGIC_COLOR { +} +} +} + +AddMedicalEntryCommand -up-|> PatientCommand + +AddMedicalEntryCommandParser -down-> AddMedicalEntryCommand : creates > + + +AddMedicalEntryCommand *--> "1"MedicalHistory : creates > +AddMedicalEntryCommand *--> "1"Patient : modifies > + +note bottom on link: Reference is stored in\n the form of an Index + + +@enduml diff --git a/docs/diagrams/AddMedicalEntryFeatureSequenceDiagram.png b/docs/diagrams/AddMedicalEntryFeatureSequenceDiagram.png new file mode 100644 index 00000000000..a209d5f5a13 Binary files /dev/null and b/docs/diagrams/AddMedicalEntryFeatureSequenceDiagram.png differ diff --git a/docs/diagrams/AddMedicalEntryFeatureSequenceDiagram.puml b/docs/diagrams/AddMedicalEntryFeatureSequenceDiagram.puml new file mode 100644 index 00000000000..b1e3d7ffdbb --- /dev/null +++ b/docs/diagrams/AddMedicalEntryFeatureSequenceDiagram.puml @@ -0,0 +1,53 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant "a:AddMedicalEntryCommand" as AddMedicalEntryCommand LOGIC_COLOR +participant ":ModelManager" as ModelManager MODEL_COLOR +participant "r:CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":ModelManager" as ModelManager MODEL_COLOR +end box + +[-> LogicManager : execute("...") +activate LogicManager + +ref over LogicManager: Parse User Input + + +LogicManager -> AddMedicalEntryCommand : execute(model) +activate AddMedicalEntryCommand + +AddMedicalEntryCommand -> ModelManager : setPatient +activate ModelManager +ModelManager --> AddMedicalEntryCommand +deactivate ModelManager +AddMedicalEntryCommand -> ModelManager : updateAppointmentBook +activate ModelManager +ModelManager --> AddMedicalEntryCommand +deactivate ModelManager +AddMedicalEntryCommand -> ModelManager : updateFilteredPatientList +activate ModelManager +ModelManager --> AddMedicalEntryCommand +deactivate ModelManager +AddMedicalEntryCommand -> ModelManager : updateFilteredAppointmentList +activate ModelManager +ModelManager --> AddMedicalEntryCommand +deactivate ModelManager + +create CommandResult +AddMedicalEntryCommand -> CommandResult +activate CommandResult + +CommandResult --> AddMedicalEntryCommand : r +deactivate CommandResult + +AddMedicalEntryCommand --> LogicManager : r +deactivate AddMedicalEntryCommand + +[<--LogicManager : r +deactivate LogicManager +@enduml diff --git a/docs/diagrams/AddMedicalEntrySequenceFeatureDiagram1.png b/docs/diagrams/AddMedicalEntrySequenceFeatureDiagram1.png new file mode 100644 index 00000000000..213b7837b01 Binary files /dev/null and b/docs/diagrams/AddMedicalEntrySequenceFeatureDiagram1.png differ diff --git a/docs/diagrams/AddMedicalEntrySequenceFeatureDiagram1.puml b/docs/diagrams/AddMedicalEntrySequenceFeatureDiagram1.puml new file mode 100644 index 00000000000..7518c4b24b9 --- /dev/null +++ b/docs/diagrams/AddMedicalEntrySequenceFeatureDiagram1.puml @@ -0,0 +1,44 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR +participant ":PatientBookParser" as PatientBookParser LOGIC_COLOR +participant ":AddMedicalEntryCommandParser" as AddMedicalEntryCommandParser LOGIC_COLOR +participant "a:AddMedicalEntryCommand" as AddMedicalEntryCommand LOGIC_COLOR +end box + + +[-> LogicManager : execute("...") +activate LogicManager + +LogicManager -> AddressBookParser : parseCommand +activate AddressBookParser +AddressBookParser -> PatientBookParser : parsePatientCommand +activate PatientBookParser +PatientBookParser -> AddMedicalEntryCommandParser : parsePatientCommand +activate AddMedicalEntryCommandParser +ref over AddMedicalEntryCommandParser: Parse argument + +create AddMedicalEntryCommand +AddMedicalEntryCommandParser -> AddMedicalEntryCommand +activate AddMedicalEntryCommand + +AddMedicalEntryCommand --> AddMedicalEntryCommandParser : a +deactivate AddMedicalEntryCommand +AddMedicalEntryCommandParser --> PatientBookParser : a +deactivate AddMedicalEntryCommandParser +AddMedicalEntryCommandParser -[hidden]-> LogicManager +destroy AddMedicalEntryCommandParser + +PatientBookParser --> AddressBookParser : a +deactivate PatientBookParser +PatientBookParser -[hidden]-> LogicManager +destroy PatientBookParser + +AddressBookParser --> LogicManager : a +deactivate AddressBookParser + +ref over LogicManager: Execute\na:AddMedicalEntryCommand +@enduml diff --git a/docs/diagrams/AddPrescriptionCommandSequenceDiagram.png b/docs/diagrams/AddPrescriptionCommandSequenceDiagram.png new file mode 100644 index 00000000000..cba9ad2b221 Binary files /dev/null and b/docs/diagrams/AddPrescriptionCommandSequenceDiagram.png differ diff --git a/docs/diagrams/AddPrescriptionCommandSequenceDiagram.puml b/docs/diagrams/AddPrescriptionCommandSequenceDiagram.puml new file mode 100644 index 00000000000..a61de3373e0 --- /dev/null +++ b/docs/diagrams/AddPrescriptionCommandSequenceDiagram.puml @@ -0,0 +1,42 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":AddPrescriptionCommand" as AddPrescriptionCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":ModelManager" as Model MODEL_COLOR +participant "appointment:Appointment" as appointment MODEL_COLOR +participant "Prescription" as Prescription MODEL_COLOR + +participant "appointmentBook\n:AppointmentBook" as appointmentBook MODEL_COLOR +end box + +[-> AddPrescriptionCommand : execute() + +AddPrescriptionCommand -> Model : get AppointmentBook + +Model --> AddPrescriptionCommand : AppointmentBook + + +AddPrescriptionCommand -> Model : addPrescription() +Model -> appointment : getPrescription() +appointment --> Model : prescriptions + +create Prescription +Model -> Prescription : medicine, volume, duration +Prescription --> Model :new prescription +Model -> appointmentBook : setAppointment(newAppointment) +appointmentBook --> Model + +Model ---> AddPrescriptionCommand + +create CommandResult +AddPrescriptionCommand -> CommandResult +CommandResult ---> AddPrescriptionCommand : result + +[<--AddPrescriptionCommand : result + +@enduml diff --git a/docs/diagrams/AppointmentClassDiagram.png b/docs/diagrams/AppointmentClassDiagram.png new file mode 100644 index 00000000000..6fb73e60f53 Binary files /dev/null and b/docs/diagrams/AppointmentClassDiagram.png differ diff --git a/docs/diagrams/AppointmentClassDiagram.puml b/docs/diagrams/AppointmentClassDiagram.puml new file mode 100644 index 00000000000..3e508b0d9a0 --- /dev/null +++ b/docs/diagrams/AppointmentClassDiagram.puml @@ -0,0 +1,11 @@ +@startuml +!include style.puml + +Package Model <>{ +Class Appointment MODEL_COLOR_T3 +Class Patient MODEL_COLOR_T3 + +Appointment "*" *-- "1"Patient +} + +@enduml diff --git a/docs/diagrams/ArchitectureDiagram.png b/docs/diagrams/ArchitectureDiagram.png new file mode 100644 index 00000000000..e4939a96c41 Binary files /dev/null and b/docs/diagrams/ArchitectureDiagram.png differ diff --git a/docs/diagrams/ArchitectureSequenceDiagram.png b/docs/diagrams/ArchitectureSequenceDiagram.png new file mode 100644 index 00000000000..ad32ae92354 Binary files /dev/null and b/docs/diagrams/ArchitectureSequenceDiagram.png differ diff --git a/docs/diagrams/ArchitectureSequenceDiagram.puml b/docs/diagrams/ArchitectureSequenceDiagram.puml index ef81d18c337..ad0a7ef88e1 100644 --- a/docs/diagrams/ArchitectureSequenceDiagram.puml +++ b/docs/diagrams/ArchitectureSequenceDiagram.puml @@ -13,7 +13,7 @@ activate ui UI_COLOR ui -[UI_COLOR]> logic : execute("delete 1") activate logic LOGIC_COLOR -logic -[LOGIC_COLOR]> model : deletePerson(p) +logic -[LOGIC_COLOR]> model : deletePatient(p) activate model MODEL_COLOR model -[MODEL_COLOR]-> logic diff --git a/docs/diagrams/ArchiveCommandSequenceDiagram.png b/docs/diagrams/ArchiveCommandSequenceDiagram.png new file mode 100644 index 00000000000..eab547b8d42 Binary files /dev/null and b/docs/diagrams/ArchiveCommandSequenceDiagram.png differ diff --git a/docs/diagrams/ArchiveCommandSequenceDiagram.puml b/docs/diagrams/ArchiveCommandSequenceDiagram.puml new file mode 100644 index 00000000000..bc295af2752 --- /dev/null +++ b/docs/diagrams/ArchiveCommandSequenceDiagram.puml @@ -0,0 +1,34 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":ArchiveAppointmentCommand" as ArchiveAppointmentCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":Model" as Model MODEL_COLOR +participant "appointmentBook:AppointmentBook" as ab MODEL_COLOR +participant "archivedAppointmentBook\n:ArchivedAppointmentBook" as archiveab MODEL_COLOR +end box + +[-> ArchiveAppointmentCommand : execute() + +ArchiveAppointmentCommand -> Model : get appointment to archive + +Model --> ArchiveAppointmentCommand : toArchive + + +ArchiveAppointmentCommand -> Model : archiveAppointment(toArchive) +Model -> ab : removeAppointment(toArchive) +Model -> archiveab : addAppointment(toArchive) + +Model ---> ArchiveAppointmentCommand + +create CommandResult +ArchiveAppointmentCommand -> CommandResult +CommandResult ---> ArchiveAppointmentCommand + +[<--ArchiveAppointmentCommand : result + +@enduml diff --git a/docs/diagrams/ArchivedStorageClassDiagram.png b/docs/diagrams/ArchivedStorageClassDiagram.png new file mode 100644 index 00000000000..7d7b02ae5bb Binary files /dev/null and b/docs/diagrams/ArchivedStorageClassDiagram.png differ diff --git a/docs/diagrams/ArchivedStorageClassDiagram.puml b/docs/diagrams/ArchivedStorageClassDiagram.puml new file mode 100644 index 00000000000..a2f6d7113b9 --- /dev/null +++ b/docs/diagrams/ArchivedStorageClassDiagram.puml @@ -0,0 +1,29 @@ +@startuml +!include style.puml +skinparam arrowThickness 1.1 +skinparam arrowColor STORAGE_COLOR +skinparam classBackgroundColor STORAGE_COLOR + +package Storage{ + +Interface UserPrefsStorage <> + +Class StorageManager + +Interface AddressBookStorage <> + +Interface AppointmentBookStorage <> + +Interface ArchivedAppointmentBookStorage <> + +Class Storage #FFFFFF + + +StorageManager -.left.- Storage +StorageManager -up-> "1" UserPrefsStorage +StorageManager --> "1" AddressBookStorage +StorageManager -up-> "1" AppointmentBookStorage +StorageManager --> "1" ArchivedAppointmentBookStorage + + +@enduml diff --git a/docs/diagrams/AutoArchiveSequenceDiagram.png b/docs/diagrams/AutoArchiveSequenceDiagram.png new file mode 100644 index 00000000000..03e74eb9122 Binary files /dev/null and b/docs/diagrams/AutoArchiveSequenceDiagram.png differ diff --git a/docs/diagrams/AutoArchiveSequenceDiagram.puml b/docs/diagrams/AutoArchiveSequenceDiagram.puml new file mode 100644 index 00000000000..3bfa00b6287 --- /dev/null +++ b/docs/diagrams/AutoArchiveSequenceDiagram.puml @@ -0,0 +1,50 @@ +@startuml +!include style.puml + +Participant ":ModelManager" as modelmanager MODEL_COLOR +Participant "scheduler:ScheduledExecutorService" as scheduler #b00b69 +Participant ":AutoArchiveApmts" as task #green + +[-[#grey]> modelmanager: Model initiated +activate modelmanager MODEL_COLOR + +modelmanager -> modelmanager : initAutoArchive() +activate modelmanager MODEL_COLOR + +modelmanager -> modelmanager : archivePastAppointments() +activate modelmanager MODEL_COLOR + +modelmanager --> modelmanager +deactivate modelmanager + +create scheduler + + +modelmanager -> scheduler : Create thread pool with 1 thread +activate scheduler #b00b69 + +note right: this lifeline continues on a separate thread +par + loop daily + create task + scheduler -> task + activate task #green + + task -> modelmanager : archivePastAppointments() + activate modelmanager MODEL_COLOR + + modelmanager --> task + + + deactivate modelmanager + + deactivate task + destroy task + + end +else + + modelmanager --> modelmanager + deactivate modelmanager +end +@enduml diff --git a/docs/diagrams/BetterModelClassDiagram.png b/docs/diagrams/BetterModelClassDiagram.png new file mode 100644 index 00000000000..859b1b29fca Binary files /dev/null and b/docs/diagrams/BetterModelClassDiagram.png differ diff --git a/docs/diagrams/BetterModelClassDiagram.puml b/docs/diagrams/BetterModelClassDiagram.puml index 5731f9cbaa1..415c8680249 100644 --- a/docs/diagrams/BetterModelClassDiagram.puml +++ b/docs/diagrams/BetterModelClassDiagram.puml @@ -4,18 +4,13 @@ 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 *-down-> "1 " UniquePatientList -UniqueTagList *-right-> "*" Tag -UniquePersonList -right-> Person +UniquePatientList -right-> Patient -Person -up-> "*" Tag - -Person *--> Name -Person *--> Phone -Person *--> Email -Person *--> Address +Patient *--> Name +Patient *--> Phone +Patient *--> Email +Patient *--> Address +Patient *--> MedicalHistory @enduml diff --git a/docs/diagrams/CommitActivityDiagram.png b/docs/diagrams/CommitActivityDiagram.png new file mode 100644 index 00000000000..bc25cebc2d9 Binary files /dev/null and b/docs/diagrams/CommitActivityDiagram.png differ diff --git a/docs/diagrams/ComponentManagers.png b/docs/diagrams/ComponentManagers.png new file mode 100644 index 00000000000..e89250bcd61 Binary files /dev/null and b/docs/diagrams/ComponentManagers.png differ diff --git a/docs/diagrams/DeleteMedicalEntryFeatureActivityDiagram.png b/docs/diagrams/DeleteMedicalEntryFeatureActivityDiagram.png new file mode 100644 index 00000000000..1ea5e5f25a5 Binary files /dev/null and b/docs/diagrams/DeleteMedicalEntryFeatureActivityDiagram.png differ diff --git a/docs/diagrams/DeleteMedicalEntryFeatureActivityDiagram.puml b/docs/diagrams/DeleteMedicalEntryFeatureActivityDiagram.puml new file mode 100644 index 00000000000..75b53c0e44a --- /dev/null +++ b/docs/diagrams/DeleteMedicalEntryFeatureActivityDiagram.puml @@ -0,0 +1,16 @@ +@startuml + +start +:User inputs Delete Medical Feature command; +if () then ([user input is valid]) +: Find specified target patient from Patient Book; +: Produce patient copy of target patient; +: Delete the specified medical entry from the patient copy's medical history; +: Replace target patient in Patient Book with the patient copy; +: Display updated Patient Book; +else ([else]) +: Display Error Message; +endif +stop + +@enduml diff --git a/docs/diagrams/DeleteMedicalEntryFeatureClassDiagram.png b/docs/diagrams/DeleteMedicalEntryFeatureClassDiagram.png new file mode 100644 index 00000000000..4fa572e3848 Binary files /dev/null and b/docs/diagrams/DeleteMedicalEntryFeatureClassDiagram.png differ diff --git a/docs/diagrams/DeleteMedicalEntryFeatureClassDiagram.puml b/docs/diagrams/DeleteMedicalEntryFeatureClassDiagram.puml new file mode 100644 index 00000000000..fdb3dffadff --- /dev/null +++ b/docs/diagrams/DeleteMedicalEntryFeatureClassDiagram.puml @@ -0,0 +1,54 @@ +@startuml +!include style.puml +skinparam arrowThickness 1.1 +skinparam arrowColor LOGIC_COLOR + +Package Model { +Package Patient { +class Patient MODEL_COLOR { +} +class MedicalHistory MODEL_COLOR { +} +class MedicalHistory.MedicalEntry MODEL_COLOR { +} +} +} +Patient *-down-> "1"MedicalHistory MODEL_COLOR : contains > +MedicalHistory --> "0..*" MedicalHistory.MedicalEntry MODEL_COLOR : contains > + +Package Logic <> { + +Package Parser { +class DeleteMedicalEntryCommandParser LOGIC_COLOR { +} +class "<>\nPatientParser" as PatientParser LOGIC_COLOR { +} +class PatientBookParser LOGIC_COLOR { +} +class AddressBookParser LOGIC_COLOR { +} +} + +DeleteMedicalEntryCommandParser -up[dashed]-|> PatientParser +AddressBookParser *--> PatientBookParser +PatientBookParser -[dashed]-> DeleteMedicalEntryCommandParser : creates > + +Package Command { +class PatientCommand LOGIC_COLOR { +} +class DeleteMedicalEntryCommand LOGIC_COLOR { +} +} +} + +DeleteMedicalEntryCommand -up-|> PatientCommand + +DeleteMedicalEntryCommandParser -down-> DeleteMedicalEntryCommand : creates > +DeleteMedicalEntryCommand -[dashed]-> "1"MedicalHistory.MedicalEntry : deletes > +note bottom on link: Reference is stored in\n the form of an Index +DeleteMedicalEntryCommand -[dashed]-> "1"Patient : modifies > +note bottom on link: Reference is stored in\n the form of an Index + + + +@enduml diff --git a/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram.png b/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram.png new file mode 100644 index 00000000000..2d802707193 Binary files /dev/null and b/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram.png differ diff --git a/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram.puml b/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram.puml new file mode 100644 index 00000000000..c7c84e8736e --- /dev/null +++ b/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram.puml @@ -0,0 +1,53 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant "d:DeleteMedicalEntryCommand" as DeleteMedicalEntryCommand LOGIC_COLOR +participant ":ModelManager" as ModelManager MODEL_COLOR +participant "r:CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":ModelManager" as ModelManager MODEL_COLOR +end box + +[-> LogicManager : execute("...") +activate LogicManager +ref over LogicManager: Parse User Input +LogicManager -> DeleteMedicalEntryCommand : execute(model) +activate DeleteMedicalEntryCommand + +DeleteMedicalEntryCommand -> ModelManager : setPatient +activate ModelManager +ModelManager --> DeleteMedicalEntryCommand +deactivate ModelManager + +DeleteMedicalEntryCommand -> ModelManager : updateAppointmentBook +activate ModelManager +ModelManager --> DeleteMedicalEntryCommand +deactivate ModelManager + +DeleteMedicalEntryCommand -> ModelManager : updateFilteredPatientList +activate ModelManager +ModelManager --> DeleteMedicalEntryCommand +deactivate ModelManager + +DeleteMedicalEntryCommand -> ModelManager : updateFilteredAppointmentList +activate ModelManager +ModelManager --> DeleteMedicalEntryCommand +deactivate ModelManager + +create CommandResult +DeleteMedicalEntryCommand -> CommandResult +activate CommandResult + +CommandResult --> DeleteMedicalEntryCommand : r +deactivate CommandResult + +DeleteMedicalEntryCommand --> LogicManager : r +deactivate DeleteMedicalEntryCommand + +[<--LogicManager : r +deactivate LogicManager +@enduml diff --git a/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram1.png b/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram1.png new file mode 100644 index 00000000000..a6f62c13290 Binary files /dev/null and b/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram1.png differ diff --git a/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram1.puml b/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram1.puml new file mode 100644 index 00000000000..9b861bcb4da --- /dev/null +++ b/docs/diagrams/DeleteMedicalEntryFeatureSequenceDiagram1.puml @@ -0,0 +1,42 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR +participant ":PatientBookParser" as PatientBookParser LOGIC_COLOR +participant ":DeleteMedicalEntryCommandParser" as DeleteMedicalEntryCommandParser LOGIC_COLOR +participant "d:DeleteMedicalEntryCommand" as DeleteMedicalEntryCommand LOGIC_COLOR +end box + +[-> LogicManager : execute("...") +activate LogicManager +LogicManager -> AddressBookParser : parseCommand +activate AddressBookParser + +AddressBookParser -> PatientBookParser : parsePatientCommand +activate PatientBookParser +PatientBookParser -> DeleteMedicalEntryCommandParser : parsePatientCommand +activate DeleteMedicalEntryCommandParser +ref over DeleteMedicalEntryCommandParser: Parse argument + +create DeleteMedicalEntryCommand +DeleteMedicalEntryCommandParser -> DeleteMedicalEntryCommand +activate DeleteMedicalEntryCommand + +DeleteMedicalEntryCommand --> DeleteMedicalEntryCommandParser : d +deactivate DeleteMedicalEntryCommand +DeleteMedicalEntryCommandParser --> PatientBookParser : d +deactivate DeleteMedicalEntryCommandParser +DeleteMedicalEntryCommandParser -[hidden]-> AddressBookParser +destroy DeleteMedicalEntryCommandParser + +PatientBookParser --> AddressBookParser : d +deactivate PatientBookParser +PatientBookParser -[hidden]-> AddressBookParser +destroy PatientBookParser + +AddressBookParser --> LogicManager : d +deactivate AddressBookParser +ref over LogicManager: Execute\nd:DeleteMedicalEntryCommand +@enduml diff --git a/docs/diagrams/DeletePatientActivityDiagram.png b/docs/diagrams/DeletePatientActivityDiagram.png new file mode 100644 index 00000000000..1ffb3fccb47 Binary files /dev/null and b/docs/diagrams/DeletePatientActivityDiagram.png differ diff --git a/docs/diagrams/DeletePatientActivityDiagram.puml b/docs/diagrams/DeletePatientActivityDiagram.puml new file mode 100644 index 00000000000..f38ad27aa81 --- /dev/null +++ b/docs/diagrams/DeletePatientActivityDiagram.puml @@ -0,0 +1,19 @@ +@startuml + +start +:User inputs Delete Patient command; +if () then ([user input is valid]) +: Find specified target Patient from Address Book; +: Delete the Patient; +if () then ([Patient has made appointments]) +: Find all appointments with that Patient; +: Delete all appointments with that Patient; +else ([else]) +endif +: Display updated UI; +else ([else]) +: Display Error Message; +endif +stop + +@enduml diff --git a/docs/diagrams/DeletePatientFeatureSequenceDiagram.png b/docs/diagrams/DeletePatientFeatureSequenceDiagram.png new file mode 100644 index 00000000000..9bc9e093312 Binary files /dev/null and b/docs/diagrams/DeletePatientFeatureSequenceDiagram.png differ diff --git a/docs/diagrams/DeletePatientFeatureSequenceDiagram.puml b/docs/diagrams/DeletePatientFeatureSequenceDiagram.puml new file mode 100644 index 00000000000..ded868771e7 --- /dev/null +++ b/docs/diagrams/DeletePatientFeatureSequenceDiagram.puml @@ -0,0 +1,43 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant "d:DeletePatientCommand" as DeletePatientCommand LOGIC_COLOR +participant "r:CommandResult" as CommandResult LOGIC_COLOR + +end box + +box Model MODEL_COLOR_T1 +participant ":ModelManager" as ModelManager MODEL_COLOR +end box + +[-> LogicManager : execute("...") +activate LogicManager +ref over LogicManager: Parse User Input + +LogicManager -> DeletePatientCommand : execute(model) +activate DeletePatientCommand + +DeletePatientCommand -> ModelManager : deletePatient +activate ModelManager +ModelManager --> DeletePatientCommand +deactivate ModelManager +DeletePatientCommand -> ModelManager : deleteAppointmentsWithPatients +activate ModelManager +ModelManager --> DeletePatientCommand +deactivate ModelManager + +create CommandResult +DeletePatientCommand -> CommandResult +activate CommandResult + +CommandResult --> DeletePatientCommand : r +deactivate CommandResult + +DeletePatientCommand --> LogicManager : r +deactivate DeletePatientCommand + +[<--LogicManager : r +deactivate LogicManager +@enduml diff --git a/docs/diagrams/DeletePatientFeatureSequenceDiagram1.png b/docs/diagrams/DeletePatientFeatureSequenceDiagram1.png new file mode 100644 index 00000000000..8833bf3d535 Binary files /dev/null and b/docs/diagrams/DeletePatientFeatureSequenceDiagram1.png differ diff --git a/docs/diagrams/DeletePatientFeatureSequenceDiagram1.puml b/docs/diagrams/DeletePatientFeatureSequenceDiagram1.puml new file mode 100644 index 00000000000..9cb3f27d7fc --- /dev/null +++ b/docs/diagrams/DeletePatientFeatureSequenceDiagram1.puml @@ -0,0 +1,46 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":LogicManager" as LogicManager LOGIC_COLOR +participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR +participant ":PatientBookParser" as PatientBookParser LOGIC_COLOR +participant ":DeletePatientCommandParser" as DeletePatientCommandParser LOGIC_COLOR +participant "d:DeletePatientCommand" as DeletePatientCommand LOGIC_COLOR + +[-> LogicManager : execute("...") +activate LogicManager +LogicManager -> AddressBookParser : parseCommand +activate AddressBookParser + +AddressBookParser -> PatientBookParser : parsePatientCommand +activate PatientBookParser + +PatientBookParser -> DeletePatientCommandParser : parsePatientCommand(\n command, args) +activate DeletePatientCommandParser +ref over DeletePatientCommandParser: Parse argument + + +create DeletePatientCommand +DeletePatientCommandParser -> DeletePatientCommand +activate DeletePatientCommand + +DeletePatientCommand --> DeletePatientCommandParser : d +deactivate DeletePatientCommand + +DeletePatientCommandParser --> PatientBookParser : d +deactivate DeletePatientCommandParser +DeletePatientCommandParser -[hidden]-> LogicManager +destroy DeletePatientCommandParser + +PatientBookParser --> AddressBookParser : d +deactivate PatientBookParser +PatientBookParser -[hidden]-> LogicManager +destroy PatientBookParser + +AddressBookParser --> LogicManager : d +deactivate AddressBookParser + +ref over LogicManager: Execute command + +@enduml diff --git a/docs/diagrams/DeletePrescriptionCommandSequenceDiagram.png b/docs/diagrams/DeletePrescriptionCommandSequenceDiagram.png new file mode 100644 index 00000000000..3df9ff8bc74 Binary files /dev/null and b/docs/diagrams/DeletePrescriptionCommandSequenceDiagram.png differ diff --git a/docs/diagrams/DeletePrescriptionCommandSequenceDiagram.puml b/docs/diagrams/DeletePrescriptionCommandSequenceDiagram.puml new file mode 100644 index 00000000000..49a07dae4c2 --- /dev/null +++ b/docs/diagrams/DeletePrescriptionCommandSequenceDiagram.puml @@ -0,0 +1,40 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":DeletePrescriptionCommand" as DeletePrescriptionCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":ModelManager" as Model MODEL_COLOR +participant "appointment:Appointment" as appointment MODEL_COLOR +participant ":Prescription" as Prescription MODEL_COLOR +participant "appointmentBook\n:AppointmentBook" as appointmentBook MODEL_COLOR +end box + +[-> DeletePrescriptionCommand : execute() + +DeletePrescriptionCommand -> Model : get AppointmentBook + +Model --> DeletePrescriptionCommand : AppointmentBook + + +DeletePrescriptionCommand -> Model : deletePrescription() +Model -> appointment : deletePrescription(medicineName) +appointment -> Prescription : remove() +Prescription --> appointment +destroy Prescription +appointment --> Model +Model -> appointmentBook : setAppointment(newAppointment) +appointmentBook --> Model + +Model ---> DeletePrescriptionCommand + +create CommandResult +DeletePrescriptionCommand -> CommandResult +CommandResult ---> DeletePrescriptionCommand : result + +[<--DeletePrescriptionCommand : result + +@enduml diff --git a/docs/diagrams/DeleteSequenceDiagram.puml b/docs/diagrams/DeleteSequenceDiagram.puml deleted file mode 100644 index 1dc2311b245..00000000000 --- a/docs/diagrams/DeleteSequenceDiagram.puml +++ /dev/null @@ -1,69 +0,0 @@ -@startuml -!include style.puml - -box Logic LOGIC_COLOR_T1 -participant ":LogicManager" as LogicManager LOGIC_COLOR -participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR -participant ":DeleteCommandParser" as DeleteCommandParser LOGIC_COLOR -participant "d:DeleteCommand" as DeleteCommand 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("delete 1") -activate LogicManager - -LogicManager -> AddressBookParser : parseCommand("delete 1") -activate AddressBookParser - -create DeleteCommandParser -AddressBookParser -> DeleteCommandParser -activate DeleteCommandParser - -DeleteCommandParser --> AddressBookParser -deactivate DeleteCommandParser - -AddressBookParser -> DeleteCommandParser : parse("1") -activate DeleteCommandParser - -create DeleteCommand -DeleteCommandParser -> DeleteCommand -activate DeleteCommand - -DeleteCommand --> DeleteCommandParser : d -deactivate DeleteCommand - -DeleteCommandParser --> AddressBookParser : d -deactivate DeleteCommandParser -'Hidden arrow to position the destroy marker below the end of the activation bar. -DeleteCommandParser -[hidden]-> AddressBookParser -destroy DeleteCommandParser - -AddressBookParser --> LogicManager : d -deactivate AddressBookParser - -LogicManager -> DeleteCommand : execute() -activate DeleteCommand - -DeleteCommand -> Model : deletePerson(1) -activate Model - -Model --> DeleteCommand -deactivate Model - -create CommandResult -DeleteCommand -> CommandResult -activate CommandResult - -CommandResult --> DeleteCommand -deactivate CommandResult - -DeleteCommand --> LogicManager : result -deactivate DeleteCommand - -[<--LogicManager -deactivate LogicManager -@enduml diff --git a/docs/diagrams/LoadAppointmentSequenceDiagram.png b/docs/diagrams/LoadAppointmentSequenceDiagram.png new file mode 100644 index 00000000000..999e289bde3 Binary files /dev/null and b/docs/diagrams/LoadAppointmentSequenceDiagram.png differ diff --git a/docs/diagrams/LoadAppointmentSequenceDiagram.puml b/docs/diagrams/LoadAppointmentSequenceDiagram.puml new file mode 100644 index 00000000000..7e631608506 --- /dev/null +++ b/docs/diagrams/LoadAppointmentSequenceDiagram.puml @@ -0,0 +1,45 @@ +@startuml +!include style.puml + +Participant ":Main" as main #grey +Participant ":Storage" as storage STORAGE_COLOR +Participant ":JsonUtil" as jsonutil USER_COLOR +Participant ":Model" as model MODEL_COLOR + +[-[#grey]> main: App launch +activate main #grey + +main -> main : initModelManager() +activate main #grey + +main -> storage : readAddressBook() +activate storage STORAGE_COLOR +storage --> main +deactivate storage STORAGE_COLOR + +main -> storage : readAppointmentBook(addressBook) +activate storage STORAGE_COLOR +storage -> jsonutil : Read from JSON file +activate jsonutil USER_COLOR +jsonutil --> storage +deactivate jsonutil + +storage -> storage : toModelType(addressBook) +activate storage STORAGE_COLOR + +storage -> storage : getPatientOfIndex() +activate storage STORAGE_COLOR + +storage --> storage : patientToAppointment +deactivate storage + +create model +storage -> model : Appointment() +activate model MODEL_COLOR +model --> storage +deactivate model +storage --> storage +deactivate storage +storage --> main : Loaded appointment book +deactivate storage +@enduml diff --git a/docs/diagrams/LogicClassDiagram.png b/docs/diagrams/LogicClassDiagram.png new file mode 100644 index 00000000000..403fb329ed4 Binary files /dev/null and b/docs/diagrams/LogicClassDiagram.png differ diff --git a/docs/diagrams/LogicClassDiagram.puml b/docs/diagrams/LogicClassDiagram.puml index 6d14b17b361..2e86429e69e 100644 --- a/docs/diagrams/LogicClassDiagram.puml +++ b/docs/diagrams/LogicClassDiagram.puml @@ -38,7 +38,7 @@ LogicManager --> Storage Storage --[hidden] Model Command .[hidden]up.> Storage Command .right.> Model -note right of XYZCommand: XYZCommand = AddCommand, \nFindCommand, etc +note right of XYZCommand: XYZCommand = AddPatientCommand, \nFindPatientCommand, etc Logic ..> CommandResult LogicManager .down.> CommandResult diff --git a/docs/diagrams/MedicalHistoryClassDiagram.png b/docs/diagrams/MedicalHistoryClassDiagram.png new file mode 100644 index 00000000000..498a4f154de Binary files /dev/null and b/docs/diagrams/MedicalHistoryClassDiagram.png differ diff --git a/docs/diagrams/MedicalHistoryClassDiagram.puml b/docs/diagrams/MedicalHistoryClassDiagram.puml new file mode 100644 index 00000000000..67bfdcd806b --- /dev/null +++ b/docs/diagrams/MedicalHistoryClassDiagram.puml @@ -0,0 +1,42 @@ +@startuml +!include style.puml +skinparam arrowThickness 1.1 +skinparam arrowColor MODEL_COLOR +skinparam classBackgroundColor MODEL_COLOR + +Package Model <> { +class Patient { +} + +class MedicalHistory { +} + +class MedicalHistory.MedicalEntry { +} + +class EntryList { +} + +class "{abstract}\nEntry" as Entry + +class Entry MODEL_COLOR { +} + +class Entry.Some MODEL_COLOR { +} + +class Entry.Empty MODEL_COLOR { +} + +Class HiddenOutside #FFFFFF +} + +HiddenOutside -[dashed]-> Patient + +Patient *--> "1"MedicalHistory : contains > +MedicalHistory *--> "1" EntryList : contains > +EntryList --> "1..*"Entry : contains > +Entry.Some -up-|> Entry : extends > +Entry.Empty -up-|> Entry : extends > +Entry.Some --> "1"MedicalHistory.MedicalEntry +@enduml diff --git a/docs/diagrams/ModelClassDiagram.png b/docs/diagrams/ModelClassDiagram.png new file mode 100644 index 00000000000..38890289fca Binary files /dev/null and b/docs/diagrams/ModelClassDiagram.png differ diff --git a/docs/diagrams/ModelClassDiagram.puml b/docs/diagrams/ModelClassDiagram.puml index 1122257bd9a..d6ac910906a 100644 --- a/docs/diagrams/ModelClassDiagram.puml +++ b/docs/diagrams/ModelClassDiagram.puml @@ -6,24 +6,33 @@ skinparam classBackgroundColor MODEL_COLOR Package Model <>{ Interface ReadOnlyAddressBook <> +Interface ReadOnlyAppointmentBook <> Interface ReadOnlyUserPrefs <> Interface Model <> Class AddressBook +Class AppointmentBook +Class ArchivedAppointmentBook Class ReadOnlyAddressBook +Class ReadOnlyAppointmentBook Class Model Class ModelManager Class UserPrefs Class ReadOnlyUserPrefs -Class UniquePersonList -Class Person +Class UniquePatientList +Class UniqueAppointmentList +Class Patient Class Address Class Email Class Name Class Phone -Class Tag +Class Prescription +Class MedicalHistory +Class MedicalHistory.MedicalEntry +Class Appointment +Class Datetime } Class HiddenOutside #FFFFFF @@ -31,24 +40,44 @@ HiddenOutside ..> Model AddressBook .up.|> ReadOnlyAddressBook +AppointmentBook .up.|> ReadOnlyAppointmentBook +ArchivedAppointmentBook .up.|> ReadOnlyAppointmentBook + + +Model .down.> ReadOnlyUserPrefs +Model .down.> ReadOnlyAddressBook +Model .down.> ReadOnlyAppointmentBook ModelManager .up.|> Model -Model .right.> ReadOnlyUserPrefs -Model .left.> ReadOnlyAddressBook ModelManager -left-> "1" AddressBook -ModelManager -right-> "1" UserPrefs +ModelManager -left-> "1" UserPrefs +ModelManager -right-> "1" ArchivedAppointmentBook +ModelManager -right-> "1" AppointmentBook + UserPrefs .up.|> ReadOnlyUserPrefs -AddressBook *--> "1" UniquePersonList -UniquePersonList --> "~* all" Person -Person *--> Name -Person *--> Phone -Person *--> Email -Person *--> Address -Person *--> "*" Tag +AddressBook *--> "1" UniquePatientList +AppointmentBook *--> "1" UniqueAppointmentList +ArchivedAppointmentBook *--> "1" UniqueAppointmentList + +Patient *--> Name +Patient *--> Phone +Patient *--> Email +Patient *--> Address + + +UniqueAppointmentList --> "~* all" Appointment + +Appointment *--> "1" Patient +Appointment *--> "1" Datetime +Appointment *--> "*" Prescription Name -[hidden]right-> Phone Phone -[hidden]right-> Address Address -[hidden]right-> Email +UniquePatientList --> "~* all" Patient -ModelManager -->"~* filtered" Person +ModelManager -->"~* filtered" Patient +Patient *--> MedicalHistory +MedicalHistory -[dashed]-> "0..*"MedicalHistory.MedicalEntry +note bottom on link: More detailed implementation\n of MedicalHistory can \nbe found under the\n MedicalHistoryClassDiagram @enduml diff --git a/docs/diagrams/ParserClasses.png b/docs/diagrams/ParserClasses.png new file mode 100644 index 00000000000..d786c6086c3 Binary files /dev/null and b/docs/diagrams/ParserClasses.png differ diff --git a/docs/diagrams/ParserClasses.puml b/docs/diagrams/ParserClasses.puml index 6ba585cba01..3cf7bbedc1b 100644 --- a/docs/diagrams/ParserClasses.puml +++ b/docs/diagrams/ParserClasses.puml @@ -18,6 +18,9 @@ Class ArgumentTokenizer Class Prefix } +note left of Parser: Parser = BasicParser, PatientParser, or \nAppointmentParser +note bottom of XYZCommand: XYZCommand = AddPatientCommand, \nEditAppointmentCommand, etc. +note right of Command: Command = BasicCommand, PatientCommand, \nAppointmentCommand Class HiddenOutside #FFFFFF HiddenOutside ..> AddressBookParser diff --git a/docs/diagrams/PrescriptionActivityDiagram.png b/docs/diagrams/PrescriptionActivityDiagram.png new file mode 100644 index 00000000000..2f517dd975e Binary files /dev/null and b/docs/diagrams/PrescriptionActivityDiagram.png differ diff --git a/docs/diagrams/PrescriptionActivityDiagram.puml b/docs/diagrams/PrescriptionActivityDiagram.puml new file mode 100644 index 00000000000..442da802a50 --- /dev/null +++ b/docs/diagrams/PrescriptionActivityDiagram.puml @@ -0,0 +1,19 @@ +@startuml +start +:User executes prescription command; + +'Since the beta syntax does not support placing the condition outside the +'diamond we place it as the true branch instead. + +if () then ([command is valid]) + :Add/remove prescription + from Appointment object; + :Updates model; + :Write to file; +else ([else]) + :Show error + message to user; + +endif +stop +@enduml diff --git a/docs/diagrams/PrescriptionClassDiagram.png b/docs/diagrams/PrescriptionClassDiagram.png new file mode 100644 index 00000000000..bd6e128e83b Binary files /dev/null and b/docs/diagrams/PrescriptionClassDiagram.png differ diff --git a/docs/diagrams/PrescriptionClassDiagram.puml b/docs/diagrams/PrescriptionClassDiagram.puml new file mode 100644 index 00000000000..f63c2583451 --- /dev/null +++ b/docs/diagrams/PrescriptionClassDiagram.puml @@ -0,0 +1,16 @@ +@startuml +!include ./style.puml + + +Package Model <>{ + +Class Appointment MODEL_COLOR_T3 +Class Prescription MODEL_COLOR_T3 + +} + +Appointment "1" *--> "*"Prescription + + + +@enduml diff --git a/docs/diagrams/PrescriptionCommandSequenceDiagram.png b/docs/diagrams/PrescriptionCommandSequenceDiagram.png new file mode 100644 index 00000000000..1c9c3228349 Binary files /dev/null and b/docs/diagrams/PrescriptionCommandSequenceDiagram.png differ diff --git a/docs/diagrams/PrescriptionCommandSequenceDiagram.puml b/docs/diagrams/PrescriptionCommandSequenceDiagram.puml new file mode 100644 index 00000000000..d4c564878fb --- /dev/null +++ b/docs/diagrams/PrescriptionCommandSequenceDiagram.puml @@ -0,0 +1,38 @@ +@startuml +!include style.puml + +box Logic LOGIC_COLOR_T1 +participant ":PrescriptionCommand" as PrescriptionCommand LOGIC_COLOR +participant ":CommandResult" as CommandResult LOGIC_COLOR +end box + +box Model MODEL_COLOR_T1 +participant ":Model" as Model MODEL_COLOR +participant "appointment:Appointment" as appointment MODEL_COLOR +participant "appointmentBook\n:AppointmentBook" as appointmentBook MODEL_COLOR +end box + +[-> PrescriptionCommand : execute() + +PrescriptionCommand -> Model : getAppointmentBook() + +Model --> PrescriptionCommand : AppointmentBook + + +PrescriptionCommand -> Model : add/delete Prescription +Model -> appointment : getPrescription() +appointment --> Model : prescriptions + + +Model -> appointmentBook : setAppointment() +appointmentBook --> Model + +Model ---> PrescriptionCommand + +create CommandResult +PrescriptionCommand -> CommandResult +CommandResult ---> PrescriptionCommand : result + +[<--PrescriptionCommand : result + +@enduml diff --git a/docs/diagrams/SaveAppointmentSequenceDiagram1.png b/docs/diagrams/SaveAppointmentSequenceDiagram1.png new file mode 100644 index 00000000000..d1aa358ec7d Binary files /dev/null and b/docs/diagrams/SaveAppointmentSequenceDiagram1.png differ diff --git a/docs/diagrams/SaveAppointmentSequenceDiagram1.puml b/docs/diagrams/SaveAppointmentSequenceDiagram1.puml new file mode 100644 index 00000000000..45717bcf074 --- /dev/null +++ b/docs/diagrams/SaveAppointmentSequenceDiagram1.puml @@ -0,0 +1,20 @@ +@startuml +!include style.puml + +Participant ":Logic" as logic LOGIC_COLOR +Participant ":Storage" as storage STORAGE_COLOR +Participant ":JsonUtil" as jsonutil USER_COLOR +Participant ":Model" as model MODEL_COLOR + +[-> logic: execute() + +logic -> model : getAddressBook() + +logic -> model : getAppointmentBook() + +logic -> storage : saveAppointmentBook(appointmentBook, addressBook) + +storage -> model : JsonAdaptedAppointment() + +storage -> jsonutil : Save JSON File +@enduml diff --git a/docs/diagrams/SaveAppointmentSequenceDiagram2.png b/docs/diagrams/SaveAppointmentSequenceDiagram2.png new file mode 100644 index 00000000000..193beeb0a08 Binary files /dev/null and b/docs/diagrams/SaveAppointmentSequenceDiagram2.png differ diff --git a/docs/diagrams/SaveAppointmentSequenceDiagram2.puml b/docs/diagrams/SaveAppointmentSequenceDiagram2.puml new file mode 100644 index 00000000000..a14c3c92810 --- /dev/null +++ b/docs/diagrams/SaveAppointmentSequenceDiagram2.puml @@ -0,0 +1,17 @@ +@startuml +!include style.puml + +Participant ":Storage" as storage STORAGE_COLOR + +box Model MODEL_COLOR_T1 +participant ":JsonAdaptedAppointment" as jaa MODEL_COLOR +participant ":Appointment" as appointment MODEL_COLOR +participant ":AddressBook" as addressbook MODEL_COLOR +end box + +create jaa +storage -> jaa : JsonAdaptedAppointment() +jaa -> appointment : getPatient() +jaa -> addressbook : getIndexOfPatient(patient) + +@enduml diff --git a/docs/diagrams/StorageClassDiagram.png b/docs/diagrams/StorageClassDiagram.png new file mode 100644 index 00000000000..79c4956553f Binary files /dev/null and b/docs/diagrams/StorageClassDiagram.png differ diff --git a/docs/diagrams/StorageClassDiagram.puml b/docs/diagrams/StorageClassDiagram.puml index 85ac3ea2dee..3dde6b81df7 100644 --- a/docs/diagrams/StorageClassDiagram.puml +++ b/docs/diagrams/StorageClassDiagram.puml @@ -18,10 +18,23 @@ package "AddressBook Storage" #F4F6F6{ Interface AddressBookStorage <> Class JsonAddressBookStorage Class JsonSerializableAddressBook -Class JsonAdaptedPerson +Class JsonAdaptedPatient Class JsonAdaptedTag } +package "AppointmentBook Storage" #F4F6F6{ +Interface AppointmentBookStorage <> +Class JsonAppointmentBookStorage +Class JsonSerializableAppointmentBook +} + +package "ArchivedAppointmentBook Storage" #F4F6F6{ +Interface ArchivedAppointmentBookStorage <> +Class JsonArchivedAppointmentBookStorage +Class JsonSerializableArchivedAppointmentBook +} + +Class JsonAdaptedAppointment } Class HiddenOutside #FFFFFF @@ -30,14 +43,26 @@ HiddenOutside ..> Storage StorageManager .up.|> Storage StorageManager -up-> "1" UserPrefsStorage StorageManager -up-> "1" AddressBookStorage +StorageManager --> "1" AppointmentBookStorage +StorageManager --> "1" ArchivedAppointmentBookStorage -Storage -left-|> UserPrefsStorage -Storage -right-|> AddressBookStorage +Storage --|> UserPrefsStorage +Storage --|> AddressBookStorage +Storage --|> AppointmentBookStorage +Storage --|> ArchivedAppointmentBookStorage JsonUserPrefsStorage .up.|> UserPrefsStorage JsonAddressBookStorage .up.|> AddressBookStorage JsonAddressBookStorage ..> JsonSerializableAddressBook -JsonSerializableAddressBook --> "*" JsonAdaptedPerson -JsonAdaptedPerson --> "*" JsonAdaptedTag +JsonSerializableAddressBook --> "*" JsonAdaptedPatient +JsonAdaptedPatient --> "*" JsonAdaptedTag + +JsonAppointmentBookStorage .up.|> AppointmentBookStorage +JsonAppointmentBookStorage ..> JsonSerializableAppointmentBook +JsonSerializableAppointmentBook --> "*" JsonAdaptedAppointment + +JsonArchivedAppointmentBookStorage .up.|> ArchivedAppointmentBookStorage +JsonArchivedAppointmentBookStorage ..> JsonSerializableArchivedAppointmentBook +JsonSerializableArchivedAppointmentBook --> "*" JsonAdaptedAppointment @enduml diff --git a/docs/diagrams/UiClassDiagram.puml b/docs/diagrams/UiClassDiagram.puml deleted file mode 100644 index ecae4876432..00000000000 --- a/docs/diagrams/UiClassDiagram.puml +++ /dev/null @@ -1,60 +0,0 @@ -@startuml -!include style.puml -skinparam arrowThickness 1.1 -skinparam arrowColor UI_COLOR_T4 -skinparam classBackgroundColor UI_COLOR - -package UI <>{ -Interface Ui <> -Class "{abstract}\nUiPart" as UiPart -Class UiManager -Class MainWindow -Class HelpWindow -Class ResultDisplay -Class PersonListPanel -Class PersonCard -Class StatusBarFooter -Class CommandBox -} - -package Model <> { -Class HiddenModel #FFFFFF -} - -package Logic <> { -Class HiddenLogic #FFFFFF -} - -Class HiddenOutside #FFFFFF -HiddenOutside ..> Ui - -UiManager .left.|> Ui -UiManager -down-> "1" MainWindow -MainWindow *-down-> "1" CommandBox -MainWindow *-down-> "1" ResultDisplay -MainWindow *-down-> "1" PersonListPanel -MainWindow *-down-> "1" StatusBarFooter -MainWindow --> "0..1" HelpWindow - -PersonListPanel -down-> "*" PersonCard - -MainWindow -left-|> UiPart - -ResultDisplay --|> UiPart -CommandBox --|> UiPart -PersonListPanel --|> UiPart -PersonCard --|> UiPart -StatusBarFooter --|> UiPart -HelpWindow --|> UiPart - -PersonCard ..> Model -UiManager -right-> Logic -MainWindow -left-> Logic - -PersonListPanel -[hidden]left- HelpWindow -HelpWindow -[hidden]left- CommandBox -CommandBox -[hidden]left- ResultDisplay -ResultDisplay -[hidden]left- StatusBarFooter - -MainWindow -[hidden]-|> UiPart -@enduml diff --git a/docs/diagrams/UndoRedoState0.puml b/docs/diagrams/UndoRedoState0.puml deleted file mode 100644 index 96e30744d24..00000000000 --- a/docs/diagrams/UndoRedoState0.puml +++ /dev/null @@ -1,20 +0,0 @@ -@startuml -!include style.puml -skinparam ClassFontColor #000000 -skinparam ClassBorderColor #000000 - -title Initial state - -package States { - class State1 as "__ab0:AddressBook__" - class State2 as "__ab1:AddressBook__" - class State3 as "__ab2:AddressBook__" -} -State1 -[hidden]right-> State2 -State2 -[hidden]right-> State3 -hide State2 -hide State3 - -class Pointer as "Current State" #FFFFF -Pointer -up-> State1 -@end diff --git a/docs/diagrams/UndoRedoState1.puml b/docs/diagrams/UndoRedoState1.puml deleted file mode 100644 index 01fcb9b2b96..00000000000 --- a/docs/diagrams/UndoRedoState1.puml +++ /dev/null @@ -1,22 +0,0 @@ -@startuml -!include style.puml -skinparam ClassFontColor #000000 -skinparam ClassBorderColor #000000 - -title After command "delete 5" - -package States <> { - class State1 as "__ab0:AddressBook__" - class State2 as "__ab1:AddressBook__" - class State3 as "__ab2:AddressBook__" -} - -State1 -[hidden]right-> State2 -State2 -[hidden]right-> State3 - -hide State3 - -class Pointer as "Current State" #FFFFF - -Pointer -up-> State2 -@end diff --git a/docs/diagrams/UndoRedoState2.puml b/docs/diagrams/UndoRedoState2.puml deleted file mode 100644 index bccc230a5d1..00000000000 --- a/docs/diagrams/UndoRedoState2.puml +++ /dev/null @@ -1,20 +0,0 @@ -@startuml -!include style.puml -skinparam ClassFontColor #000000 -skinparam ClassBorderColor #000000 - -title After command "add n/David" - -package States <> { - class State1 as "__ab0:AddressBook__" - class State2 as "__ab1:AddressBook__" - class State3 as "__ab2:AddressBook__" -} - -State1 -[hidden]right-> State2 -State2 -[hidden]right-> State3 - -class Pointer as "Current State" #FFFFF - -Pointer -up-> State3 -@end diff --git a/docs/diagrams/UndoRedoState3.puml b/docs/diagrams/UndoRedoState3.puml deleted file mode 100644 index ea29c9483e4..00000000000 --- a/docs/diagrams/UndoRedoState3.puml +++ /dev/null @@ -1,20 +0,0 @@ -@startuml -!include style.puml -skinparam ClassFontColor #000000 -skinparam ClassBorderColor #000000 - -title After command "undo" - -package States <> { - class State1 as "__ab0:AddressBook__" - class State2 as "__ab1:AddressBook__" - class State3 as "__ab2:AddressBook__" -} - -State1 -[hidden]right-> State2 -State2 -[hidden]right-> State3 - -class Pointer as "Current State" #FFFFF - -Pointer -up-> State2 -@end diff --git a/docs/diagrams/UndoRedoState4.puml b/docs/diagrams/UndoRedoState4.puml deleted file mode 100644 index 1b784cece80..00000000000 --- a/docs/diagrams/UndoRedoState4.puml +++ /dev/null @@ -1,20 +0,0 @@ -@startuml -!include style.puml -skinparam ClassFontColor #000000 -skinparam ClassBorderColor #000000 - -title After command "list" - -package States <> { - class State1 as "__ab0:AddressBook__" - class State2 as "__ab1:AddressBook__" - class State3 as "__ab2:AddressBook__" -} - -State1 -[hidden]right-> State2 -State2 -[hidden]right-> State3 - -class Pointer as "Current State" #FFFFF - -Pointer -up-> State2 -@end diff --git a/docs/diagrams/UndoRedoState5.puml b/docs/diagrams/UndoRedoState5.puml deleted file mode 100644 index 88927be32bc..00000000000 --- a/docs/diagrams/UndoRedoState5.puml +++ /dev/null @@ -1,21 +0,0 @@ -@startuml -!include style.puml -skinparam ClassFontColor #000000 -skinparam ClassBorderColor #000000 - -title After command "clear" - -package States <> { - class State1 as "__ab0:AddressBook__" - class State2 as "__ab1:AddressBook__" - class State3 as "__ab3:AddressBook__" -} - -State1 -[hidden]right-> State2 -State2 -[hidden]right-> State3 - -class Pointer as "Current State" #FFFFF - -Pointer -up-> State3 -note right on link: State ab2 deleted. -@end diff --git a/docs/diagrams/UndoSequenceDiagram.puml b/docs/diagrams/UndoSequenceDiagram.puml deleted file mode 100644 index 410aab4e412..00000000000 --- a/docs/diagrams/UndoSequenceDiagram.puml +++ /dev/null @@ -1,53 +0,0 @@ -@startuml -!include style.puml - -box Logic LOGIC_COLOR_T1 -participant ":LogicManager" as LogicManager LOGIC_COLOR -participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR -participant "u:UndoCommand" as UndoCommand LOGIC_COLOR -end box - -box Model MODEL_COLOR_T1 -participant ":Model" as Model MODEL_COLOR -participant ":VersionedAddressBook" as VersionedAddressBook MODEL_COLOR -end box -[-> LogicManager : execute(undo) -activate LogicManager - -LogicManager -> AddressBookParser : parseCommand(undo) -activate AddressBookParser - -create UndoCommand -AddressBookParser -> UndoCommand -activate UndoCommand - -UndoCommand --> AddressBookParser -deactivate UndoCommand - -AddressBookParser --> LogicManager : u -deactivate AddressBookParser - -LogicManager -> UndoCommand : execute() -activate UndoCommand - -UndoCommand -> Model : undoAddressBook() -activate Model - -Model -> VersionedAddressBook : undo() -activate VersionedAddressBook - -VersionedAddressBook -> VersionedAddressBook :resetData(ReadOnlyAddressBook) -VersionedAddressBook --> Model : -deactivate VersionedAddressBook - -Model --> UndoCommand -deactivate Model - -UndoCommand --> LogicManager : result -deactivate UndoCommand -UndoCommand -[hidden]-> LogicManager : result -destroy UndoCommand - -[<--LogicManager -deactivate LogicManager -@enduml diff --git a/docs/diagrams/tracing/LogicSequenceDiagram.puml b/docs/diagrams/tracing/LogicSequenceDiagram.puml index fdcbe1c0ccc..a102805fe92 100644 --- a/docs/diagrams/tracing/LogicSequenceDiagram.puml +++ b/docs/diagrams/tracing/LogicSequenceDiagram.puml @@ -13,7 +13,7 @@ create ecp abp -> ecp abp -> ecp ++: parse(arguments) create ec -ecp -> ec ++: index, editPersonDescriptor +ecp -> ec ++: index, editPatientDescriptor ec --> ecp -- ecp --> abp --: command abp --> logic --: command diff --git a/docs/images/AddAppointmentSequenceDiagram.png b/docs/images/AddAppointmentSequenceDiagram.png new file mode 100644 index 00000000000..3f3e43f0a41 Binary files /dev/null and b/docs/images/AddAppointmentSequenceDiagram.png differ diff --git a/docs/images/AddMedicalEntryFeatureActivityDiagram.png b/docs/images/AddMedicalEntryFeatureActivityDiagram.png new file mode 100644 index 00000000000..79e16ad3ca8 Binary files /dev/null and b/docs/images/AddMedicalEntryFeatureActivityDiagram.png differ diff --git a/docs/images/AddMedicalEntryFeatureClassDiagram.png b/docs/images/AddMedicalEntryFeatureClassDiagram.png new file mode 100644 index 00000000000..f6b8780ee18 Binary files /dev/null and b/docs/images/AddMedicalEntryFeatureClassDiagram.png differ diff --git a/docs/images/AddMedicalEntryFeatureSequenceDiagram.png b/docs/images/AddMedicalEntryFeatureSequenceDiagram.png new file mode 100644 index 00000000000..af10cb1bbce Binary files /dev/null and b/docs/images/AddMedicalEntryFeatureSequenceDiagram.png differ diff --git a/docs/images/AddMedicalHistory.png b/docs/images/AddMedicalHistory.png new file mode 100644 index 00000000000..019eb6afb38 Binary files /dev/null and b/docs/images/AddMedicalHistory.png differ diff --git a/docs/images/AddPrescription.png b/docs/images/AddPrescription.png new file mode 100644 index 00000000000..5f9fa0549e9 Binary files /dev/null and b/docs/images/AddPrescription.png differ diff --git a/docs/images/AppointmentCard.png b/docs/images/AppointmentCard.png new file mode 100644 index 00000000000..71552887d84 Binary files /dev/null and b/docs/images/AppointmentCard.png differ diff --git a/docs/images/AppointmentClassDiagram.png b/docs/images/AppointmentClassDiagram.png new file mode 100644 index 00000000000..6fb73e60f53 Binary files /dev/null and b/docs/images/AppointmentClassDiagram.png differ diff --git a/docs/images/AppointmentView.png b/docs/images/AppointmentView.png new file mode 100644 index 00000000000..8084016d6e7 Binary files /dev/null and b/docs/images/AppointmentView.png differ diff --git a/docs/images/ArchitectureDiagram.png b/docs/images/ArchitectureDiagram.png index 86c60246ccb..e4939a96c41 100644 Binary files a/docs/images/ArchitectureDiagram.png and b/docs/images/ArchitectureDiagram.png differ diff --git a/docs/images/ArchitectureSequenceDiagram.png b/docs/images/ArchitectureSequenceDiagram.png index 2f1346869d0..ad32ae92354 100644 Binary files a/docs/images/ArchitectureSequenceDiagram.png and b/docs/images/ArchitectureSequenceDiagram.png differ diff --git a/docs/images/ArchiveCommandSequenceDiagram.png b/docs/images/ArchiveCommandSequenceDiagram.png new file mode 100644 index 00000000000..eab547b8d42 Binary files /dev/null and b/docs/images/ArchiveCommandSequenceDiagram.png differ diff --git a/docs/images/ArchivedStorageClassDiagram.png b/docs/images/ArchivedStorageClassDiagram.png new file mode 100644 index 00000000000..7d7b02ae5bb Binary files /dev/null and b/docs/images/ArchivedStorageClassDiagram.png differ diff --git a/docs/images/AutoArchiveSequenceDiagram.png b/docs/images/AutoArchiveSequenceDiagram.png new file mode 100644 index 00000000000..0c982b5b663 Binary files /dev/null and b/docs/images/AutoArchiveSequenceDiagram.png differ diff --git a/docs/images/BetterModelClassDiagram.png b/docs/images/BetterModelClassDiagram.png index 1ec62caa2a5..859b1b29fca 100644 Binary files a/docs/images/BetterModelClassDiagram.png and b/docs/images/BetterModelClassDiagram.png differ diff --git a/docs/images/CommandBox.png b/docs/images/CommandBox.png new file mode 100644 index 00000000000..01399342a10 Binary files /dev/null and b/docs/images/CommandBox.png differ diff --git a/docs/images/CommandResultStatusDisplay.png b/docs/images/CommandResultStatusDisplay.png new file mode 100644 index 00000000000..e9824adb2e9 Binary files /dev/null and b/docs/images/CommandResultStatusDisplay.png differ diff --git a/docs/images/CommitActivityDiagram.png b/docs/images/CommitActivityDiagram.png index c08c13f5c8b..bc25cebc2d9 100644 Binary files a/docs/images/CommitActivityDiagram.png and b/docs/images/CommitActivityDiagram.png differ diff --git a/docs/images/ComponentManagers.png b/docs/images/ComponentManagers.png index 40f20323674..e89250bcd61 100644 Binary files a/docs/images/ComponentManagers.png and b/docs/images/ComponentManagers.png differ diff --git a/docs/images/DeleteMedicalEntryFeatureActivityDiagram.png b/docs/images/DeleteMedicalEntryFeatureActivityDiagram.png new file mode 100644 index 00000000000..1ea5e5f25a5 Binary files /dev/null and b/docs/images/DeleteMedicalEntryFeatureActivityDiagram.png differ diff --git a/docs/images/DeleteMedicalEntryFeatureClassDiagram.png b/docs/images/DeleteMedicalEntryFeatureClassDiagram.png new file mode 100644 index 00000000000..4fa572e3848 Binary files /dev/null and b/docs/images/DeleteMedicalEntryFeatureClassDiagram.png differ diff --git a/docs/images/DeleteMedicalEntryFeatureSequenceDiagram.png b/docs/images/DeleteMedicalEntryFeatureSequenceDiagram.png new file mode 100644 index 00000000000..0e1ae662ce0 Binary files /dev/null and b/docs/images/DeleteMedicalEntryFeatureSequenceDiagram.png differ diff --git a/docs/images/DeletePatientActivityDiagram.png b/docs/images/DeletePatientActivityDiagram.png new file mode 100644 index 00000000000..3442f8ab2d9 Binary files /dev/null and b/docs/images/DeletePatientActivityDiagram.png differ diff --git a/docs/images/DeletePatientFeatureSequenceDiagram.png b/docs/images/DeletePatientFeatureSequenceDiagram.png new file mode 100644 index 00000000000..833aa3cdcfa Binary files /dev/null and b/docs/images/DeletePatientFeatureSequenceDiagram.png differ diff --git a/docs/images/DeleteSequenceDiagram.png b/docs/images/DeleteSequenceDiagram.png index fa327b39618..3789a3ab488 100644 Binary files a/docs/images/DeleteSequenceDiagram.png and b/docs/images/DeleteSequenceDiagram.png differ diff --git a/docs/images/DocHelp.png b/docs/images/DocHelp.png new file mode 100644 index 00000000000..d7ac0855f4c Binary files /dev/null and b/docs/images/DocHelp.png differ diff --git a/docs/images/DocitHeader.png b/docs/images/DocitHeader.png new file mode 100644 index 00000000000..23bce4ec4c2 Binary files /dev/null and b/docs/images/DocitHeader.png differ diff --git a/docs/images/LoadAppointmentSequenceDiagram.png b/docs/images/LoadAppointmentSequenceDiagram.png new file mode 100644 index 00000000000..999e289bde3 Binary files /dev/null and b/docs/images/LoadAppointmentSequenceDiagram.png differ diff --git a/docs/images/LogicClassDiagram.png b/docs/images/LogicClassDiagram.png index c3028aa1cda..403fb329ed4 100644 Binary files a/docs/images/LogicClassDiagram.png and b/docs/images/LogicClassDiagram.png differ diff --git a/docs/images/MedicalHistoryClassDiagram.png b/docs/images/MedicalHistoryClassDiagram.png new file mode 100644 index 00000000000..498a4f154de Binary files /dev/null and b/docs/images/MedicalHistoryClassDiagram.png differ diff --git a/docs/images/ModelClassDiagram.png b/docs/images/ModelClassDiagram.png index 39d7aec4b33..38890289fca 100644 Binary files a/docs/images/ModelClassDiagram.png and b/docs/images/ModelClassDiagram.png differ diff --git a/docs/images/Navigability.png b/docs/images/Navigability.png new file mode 100644 index 00000000000..abe08652106 Binary files /dev/null and b/docs/images/Navigability.png differ diff --git a/docs/images/ParserClasses.png b/docs/images/ParserClasses.png index 58ad22ce16a..d786c6086c3 100644 Binary files a/docs/images/ParserClasses.png and b/docs/images/ParserClasses.png differ diff --git a/docs/images/PatientCard.png b/docs/images/PatientCard.png new file mode 100644 index 00000000000..e6d8d9804a8 Binary files /dev/null and b/docs/images/PatientCard.png differ diff --git a/docs/images/PatientView.png b/docs/images/PatientView.png new file mode 100644 index 00000000000..5b832bcbcd3 Binary files /dev/null and b/docs/images/PatientView.png differ diff --git a/docs/images/PrescriptionActivityDiagram.png b/docs/images/PrescriptionActivityDiagram.png new file mode 100644 index 00000000000..9267857d7ae Binary files /dev/null and b/docs/images/PrescriptionActivityDiagram.png differ diff --git a/docs/images/PrescriptionClassDiagram.png b/docs/images/PrescriptionClassDiagram.png new file mode 100644 index 00000000000..5e2726356cd Binary files /dev/null and b/docs/images/PrescriptionClassDiagram.png differ diff --git a/docs/images/PrescriptionSequenceDiagram.png b/docs/images/PrescriptionSequenceDiagram.png new file mode 100644 index 00000000000..b7ce6057a31 Binary files /dev/null and b/docs/images/PrescriptionSequenceDiagram.png differ diff --git a/docs/images/PtAdd.png b/docs/images/PtAdd.png new file mode 100644 index 00000000000..ac95faf6d76 Binary files /dev/null and b/docs/images/PtAdd.png differ diff --git a/docs/images/PtDelete.png b/docs/images/PtDelete.png new file mode 100644 index 00000000000..10244187906 Binary files /dev/null and b/docs/images/PtDelete.png differ diff --git a/docs/images/PtEdit.png b/docs/images/PtEdit.png new file mode 100644 index 00000000000..c621daceb01 Binary files /dev/null and b/docs/images/PtEdit.png differ diff --git a/docs/images/PtList.png b/docs/images/PtList.png new file mode 100644 index 00000000000..ac83a072da2 Binary files /dev/null and b/docs/images/PtList.png differ diff --git a/docs/images/PtMa.png b/docs/images/PtMa.png new file mode 100644 index 00000000000..3dc4ceebe86 Binary files /dev/null and b/docs/images/PtMa.png differ diff --git a/docs/images/PtMd.png b/docs/images/PtMd.png new file mode 100644 index 00000000000..dfc5b2fdb17 Binary files /dev/null and b/docs/images/PtMd.png differ diff --git a/docs/images/SaveAppointmentSequenceDiagram.png b/docs/images/SaveAppointmentSequenceDiagram.png new file mode 100644 index 00000000000..8fd281cc787 Binary files /dev/null and b/docs/images/SaveAppointmentSequenceDiagram.png differ diff --git a/docs/images/SaveAppointmentSequenceDiagram1.png b/docs/images/SaveAppointmentSequenceDiagram1.png new file mode 100644 index 00000000000..d1aa358ec7d Binary files /dev/null and b/docs/images/SaveAppointmentSequenceDiagram1.png differ diff --git a/docs/images/SaveAppointmentSequenceDiagram2.png b/docs/images/SaveAppointmentSequenceDiagram2.png new file mode 100644 index 00000000000..193beeb0a08 Binary files /dev/null and b/docs/images/SaveAppointmentSequenceDiagram2.png differ diff --git a/docs/images/ShowArchiveAppointments.png b/docs/images/ShowArchiveAppointments.png new file mode 100644 index 00000000000..1a006432d84 Binary files /dev/null and b/docs/images/ShowArchiveAppointments.png differ diff --git a/docs/images/SortAppointments.png b/docs/images/SortAppointments.png new file mode 100644 index 00000000000..90d2bdf999a Binary files /dev/null and b/docs/images/SortAppointments.png differ diff --git a/docs/images/StorageClassDiagram.png b/docs/images/StorageClassDiagram.png index 82c66f8f16e..790aa448efa 100644 Binary files a/docs/images/StorageClassDiagram.png and b/docs/images/StorageClassDiagram.png differ diff --git a/docs/images/Ui.png b/docs/images/Ui.png index 91488fd1a0f..5468926e91f 100644 Binary files a/docs/images/Ui.png and b/docs/images/Ui.png differ diff --git a/docs/images/UiClassDiagram.png b/docs/images/UiClassDiagram.png index 4bb8b2ce591..8470de25d64 100644 Binary files a/docs/images/UiClassDiagram.png and b/docs/images/UiClassDiagram.png differ diff --git a/docs/images/UndoRedoState0.png b/docs/images/UndoRedoState0.png deleted file mode 100644 index 8f7538cd884..00000000000 Binary files a/docs/images/UndoRedoState0.png and /dev/null differ diff --git a/docs/images/UndoRedoState1.png b/docs/images/UndoRedoState1.png deleted file mode 100644 index df9908d0948..00000000000 Binary files a/docs/images/UndoRedoState1.png and /dev/null differ diff --git a/docs/images/UndoRedoState2.png b/docs/images/UndoRedoState2.png deleted file mode 100644 index 36519c1015b..00000000000 Binary files a/docs/images/UndoRedoState2.png and /dev/null differ diff --git a/docs/images/UndoRedoState3.png b/docs/images/UndoRedoState3.png deleted file mode 100644 index 19959d01712..00000000000 Binary files a/docs/images/UndoRedoState3.png and /dev/null differ diff --git a/docs/images/UndoRedoState4.png b/docs/images/UndoRedoState4.png deleted file mode 100644 index 4c623e4f2c5..00000000000 Binary files a/docs/images/UndoRedoState4.png and /dev/null differ diff --git a/docs/images/UndoRedoState5.png b/docs/images/UndoRedoState5.png deleted file mode 100644 index 84ad2afa6bd..00000000000 Binary files a/docs/images/UndoRedoState5.png and /dev/null differ diff --git a/docs/images/UndoSequenceDiagram.png b/docs/images/UndoSequenceDiagram.png deleted file mode 100644 index 6addcd3a8d9..00000000000 Binary files a/docs/images/UndoSequenceDiagram.png and /dev/null differ diff --git a/docs/images/didymental.png b/docs/images/didymental.png new file mode 100644 index 00000000000..4372a6a4153 Binary files /dev/null and b/docs/images/didymental.png differ diff --git a/docs/images/gycgabriel.png b/docs/images/gycgabriel.png new file mode 100644 index 00000000000..1894af88a3c Binary files /dev/null and b/docs/images/gycgabriel.png differ diff --git a/docs/images/huyuxin0429.png b/docs/images/huyuxin0429.png new file mode 100644 index 00000000000..8ed97b221dd Binary files /dev/null and b/docs/images/huyuxin0429.png differ diff --git a/docs/images/joshenx.png b/docs/images/joshenx.png new file mode 100644 index 00000000000..b08de738c93 Binary files /dev/null and b/docs/images/joshenx.png differ diff --git a/docs/images/rish-16.png b/docs/images/rish-16.png new file mode 100644 index 00000000000..d51dfbe7241 Binary files /dev/null and b/docs/images/rish-16.png differ diff --git a/docs/index.md b/docs/index.md index 7601dbaad0d..46f7bab5f49 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,17 +1,17 @@ --- layout: page -title: AddressBook Level-3 +title: Doc'it --- -[![CI Status](https://github.com/se-edu/addressbook-level3/workflows/Java%20CI/badge.svg)](https://github.com/se-edu/addressbook-level3/actions) -[![codecov](https://codecov.io/gh/se-edu/addressbook-level3/branch/master/graph/badge.svg)](https://codecov.io/gh/se-edu/addressbook-level3) +[![CI Status](https://github.com/AY2122S1-CS2103-W14-1/tp/workflows/Java%20CI/badge.svg)](https://github.com/AY2122S1-CS2103-W14-1/tp/actions) +[![codecov](https://codecov.io/gh/AY2122S1-CS2103-W14-1/tp/branch/master/graph/badge.svg)](https://codecov.io/gh/AY2122S1-CS2103-W14-1/tp) ![Ui](images/Ui.png) -**AddressBook is a desktop application for managing your contact details.** While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface). +**Doc'it is a desktop application for clinic staff to view, update, and onboard patient records, solving the inefficient paper records and files used today.** While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface). -* If you are interested in using AddressBook, head over to the [_Quick Start_ section of the **User Guide**](UserGuide.html#quick-start). -* If you are interested about developing AddressBook, the [**Developer Guide**](DeveloperGuide.html) is a good place to start. +* If you are interested in using Doc'it, head over to the [_Quick Start_ section of the **User Guide**](UserGuide.html#quick-start). +* If you are interested about developing Doc'it, the [**Developer Guide**](DeveloperGuide.html) is a good place to start. **Acknowledgements** diff --git a/docs/team/didymental.md b/docs/team/didymental.md new file mode 100644 index 00000000000..84818387395 --- /dev/null +++ b/docs/team/didymental.md @@ -0,0 +1,55 @@ +--- +layout: page +title: Didymus' Project Portfolio Page +--- + +### Project: Doc'it + +#### Overview +Doc’it provides a centralised platform for authorised staff from small family clinics to view, update, and onboard +patient records and schedule appointments, solving the inefficient paper records and files used today. With Doc’it, small family clinics can +reduce man-hours in managing paper files, translating this ‘saved’ time into better frontline care services. + +#### Summary of Contributions +Given below are my contributions to the project: +- **New Feature**: Create `MedicalHistory` class to store the medical history of Patient Records. + * What it does: allows clinic staff to record medical histories when a patient is created. + * Justification: This feature improves the product significantly because clinic staff can have more medical information about a Patient, which allows for better diagnosis. + * Highlights: This feature was challenging and required an in-depth analysis of design alternatives. The final design chosen was to build `MedicalHistory` class to compose multiple `MedicalEntry` subclasses, which required the use OOP composition and polymorphism principles. The implementation also introduced wrapper classes, `Entry` and `EntryList` for the purpose of defensive programming. It also required changes to Json serialisation for storage of the new `MedicalHistory` information. Storage was particularly challenging given the need to record the `date` of recording, and reboot the `date` according to what was saved. CRUD operations inherited from Ab3's `Person` class, now `Patient`, also needed to be modified to accommodate the new `MedicalHistory` attribute. Existing test cases for `parser` and CRUD operations inherited from AB3 needed modification. +- **New Feature**: Add and Delete `MedicalEntry` to the `MedicalHistory` of a Patient Record. + * What it does: allows clinic staff to add and delete specified medical histories for an existing patient, with an automatic record of the date the description of the medical history was entered (for adding). + * Justification: This feature improves the product significantly because clinic staff can record important medical details about the patient to have a stronger medical understanding. The automatic date of entry also ensures the medical history can be checked and updated. They can also delete wrong or irrelevant entries. + * Highlights: This features requires a new `Command` to be created. It required some analysis of design alternatives. The implementation required modifications to existing commands, test cases and the `Parser` set of class. + * Credits: *The design of the code was modelled after existing AB3 command codes, due to the existing `Parser` and `Command` associations.* +- **New Feature**: Modified GUI for `Prescription`. + * What it does: allows clinic staff see `Prescription` added after executing command to add prescription to an appointment. + * Justification: This feature improves the product significantly because clinic staff can visually view and record the prescriptions prescribed after an appointment. + * Highlights: This features was challenging. It required a strong understanding of `ObservableList` and how `ObservableList` worked with the GUI. As `Prescription` was a class encapsulated by `Appointment`, merely changing the `Prescription` would not trigger an event for GUI to change as the `ObservableList` only observes `Appointment` objects. Thus, for every modification to `Prescription`, we needed to update the `Appointment` object by creating a copy of the `Appointment` object. +- **Code contributed**: [RepoSense link](https://nus-cs2103-ay2122s1.github.io/tp-dashboard/?search=&sort=groupTitle&sortWithin=title&since=2021-09-17&timeframe=commit&mergegroup=&groupSelect=groupByRepos&breakdown=false&tabOpen=true&tabType=authorship&tabAuthor=didymental&tabRepo=AY2122S1-CS2103-W14-1%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code~other&authorshipIsBinaryFileTypeChecked=false) +- **Enhancements to existing features**: + * **`FIND PATIENT` feature:** + * Enhanced `pt find` to be able to find a list of patients based on their medical history description. This enhancement allows clinic staff to find patients by their `name` and any `description` of their medical history. + * Justification: clinic staff can find a list of patients not only by their name but by their medical history, making it easier to track patients with similar past conditions. + * Wrote additional tests for existing features and new features, specifically add medical entry, delete medical entry +- **Project management**: + * Managed releases `v1.1` - `v1.4` (4 releases) on Github + * Coordinated forking workflow + * Coordinated weekly tasks and delegated to individual members +- **Coordinating and Maintaining Issue Tracker**: + * Coordinated sprint issues by dividing tasks and assigning tasks to group members (examples: [\#54](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/54), [\#55](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/55), [\#56](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/56), [\#57](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/57), [\#67](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/67), [\#75](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/75), [\#76](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/76), [\#77](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/77), [\#78](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/78), [\#79](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/79), [\#80](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/80), [\#81](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/81), [\#102](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/102), [\#108](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/108), and [more](https://github.com/AY2122S1-CS2103-W14-1/tp/issues?q=is%3Aissue+author%3Adidymental+is%3Aclosed)) +- **Documentation**: + * User Guide: + * Added documentation for the section on `MedicalHistory` and all `MedicalHistory` related features expected outcomes [\#179](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/179), [\#240](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/240) + * Fix formatting of User Guide [\#255](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/255) + * Developer Guide: + * Added implementation details of the `MedicalHistory` class, `Add Medical Entry` feature, `Delete Medical Entry` feature. [\#282](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/282) + * Drew the UML class diagram which captures the associations between `MedicalHistory`, `MedicalEntry` and `Patient` classes. [\#304](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/304) + * Drew the sequence and activity diagram which captures the associations between `Logic` and `Model` components for `AddMedicalEntry`, `DeleteMedicalEntry` features [\#282](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/282), [\#304](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/304), [\#321](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/321) + * Wrote 8 initial use cases [\#38](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/38), + * Updated previous use cases and added 3 new use cases [\#38](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/38), [\#321](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/321) + * Added manual testing test cases for Adding a Patient, Deleting a Patient, Adding a Medical Entry, Deleting a Medical Entry from patient with non-empty medical history, Deleting a Medical Entry from patient with empty medical history [\#321](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/321) + * Updated target user profile and value proposition. [\#321](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/321) +- **Community**: + * PRs reviewed (with non-trivial review comments): [\#71](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/71), [\#29](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/29), [\#18](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/18), [\#61](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/61) + * Contributed to forum discussions (examples: [1](https://github.com/nus-cs2103-AY2122S1/forum/issues/237), [2](https://github.com/nus-cs2103-AY2122S1/forum/issues/306)) + * Reported bugs and suggestions for other teams in the class (example: [1](https://github.com/didymental/ped)) diff --git a/docs/team/gycgabriel.md b/docs/team/gycgabriel.md new file mode 100644 index 00000000000..4f36e26e17b --- /dev/null +++ b/docs/team/gycgabriel.md @@ -0,0 +1,74 @@ +--- +layout: page +title: Gabriel's Project Portfolio Page +--- + +### Project: Doc'IT + +Doc’it provides a centralised platform for authorised staff from small family clinics to view, update, and onboard +patient records, solving the inefficient paper records and files used today. With Doc’it, small family clinics can +reduce man-hours in managing paper files, translating this ‘saved’ time into better frontline care services +Doc'IT is a desktop address book application. Users key in CLI-themed commands in the command box, and the results of the commands are dislayed in the GUI created with JavaFX. It is written in Java, and has about 10 kLOC. + +Given below are my contributions to the project. + +* **New Feature**: Create `Appointment` class to represent a patient's appointment. + * What it does: Allows users to record a patient's appointment after a patient is created. + * Justification: This feature allows users to represent multiple appointments of patients with each having their own date and time. + * Highlights: The implementation of `Appointment` class required creation of `AppointmentBook`, `ReadOnlyAppointmentBook` and `UniqueAppointmentList` in `Storage` to support saving and loading of `Appointment`. Changes required in `ModelManager` to instantiate `AppointmentBook` with `AddressBook`, i.e. to instantiate list of appointments with list of patient. Appointments had to be listed in a separate list from `Patient` class, yet have a link to the patient that has the appointment. This feature required an in-depth analysis of design alternatives. The design choice was to build `Appointment` class to compose `Patient` and a `LocalDateTime` to represent the date and time of the appointment. This design required the use of OOP composition and polymorphism principles. The implementation required careful thought in how the `Appointment` class will be loaded and stored to memory as a list of appointments, while referencing a patient object. The design choice was to use `Index` of a `Patient` to store the appointment instead of a `Patient` object for easier loading from and storing to JSON. ([\#58](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/58), [\#85](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/85), [\#87](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/87)) + +* **New Feature**: Implement Add, Edit, Delete operations for `Appointment` class. + * What it does: Allows users to add, edit and delete a patient's appointment after the appointment is created. + * Justification: Allows users to create, modify and delete appointments. Users can modify appointments to reflect changes in appointment details. + * Highlights: This implementation required the creation of `Parser` and `Command` classes to support `Appointment`-related commands and addition of methods in `AppointmentBook` class. Modified `AddressBookParser` class to accept `Appointment` commands. Created `XYZCommandParser` classes (e.g. `AddAppointmentCommandParser`). Created `XYZCommand` classes to create, modify or delete the `Appointment` as commanded (e.g. `AddAppointmentCommand`). Added methods in `AppointmentBook` to update the list of appointments. ([\#135](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/135), [\#85](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/85)) + +* **New Feature**: Implement date-time parsing for `Appointment` class. + * Justification: Allows date and time that to be reformatted in the UI, and be used to implement sort and archive features. + * Highlights: Required to implement `ParserUtil#parseDateTime` for adding, editing appointments, and loading appointments from JSON. ([\#132](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/132)) + +* **New Feature**: Implement stricter parsers for `Datetime`, `Name`, `Address`, `MedicalHistory` + * Justification: Prevents users from entering incorrectly formatted information. + * Highlights: Required a strong understanding of regex. Added logging for `Datetime` parsing. ([\#236](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/236), [\#261](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/261)) + +* **New Feature**: Change command result box to wrap text + * Highlights: The implementation in UI property removes the need to include a newline in command results in multiple places. [\#236](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/236) + +* **New Feature**: Wrote tests for `Appointment`-related classes to increase coverage by 4% in total ([\#265](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/265), [\#286](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/286)) + +* **Code contributed**: [RepoSense link](https://nus-cs2103-ay2122s1.github.io/tp-dashboard/#breakdown=true&search=gycgabriel) + +* **Project management**: + * Ensured scheduling and tracking, including setting up labels for issues for the team's use, and beginning milestones + * Managed `Appointment` component and gave technical advice regarding `Appointment`-related classes and tests + * Gave advice for tests for EditAppointmentCommand [\#287](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/287) + * Fixed tests for DeleteAppointmentCommand [\#286](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/286) + * Made suggestions regarding renaming methods to better suit its purpose in `Appointments` [\#237](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/237), [\#98](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/98) + * Suggested enhancements [\#92](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/92) + * Kept track of deadlines, updating team member's of current progress and reminding the team of upcoming deadlines + +* **Documentation**: + * User Guide: + * Added documentation for the commands `apmt add`, `apmt list`, `apmt edit`, `apmt delete` [\#36](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/36/) + * Did cosmetic tweaks to `Appointment` documentation of features to include 💡 and ℹ icons to improve readability: [\#162](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/162) + * Added Table Of Contents links: [\#162](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/162) + * Developer Guide: + * Added implementation details of the `Appointments with valid Patient` feature. + - [Appointment composed of a Valid Patient when added, loaded and stored](https://ay2122s1-cs2103-w14-1.github.io/tp/DeveloperGuide.html#appointment-composed-of-a-valid-patient-when-added-loaded-and-stored) + - [How Appointment is implemented](https://ay2122s1-cs2103-w14-1.github.io/tp/DeveloperGuide.html#how-appointment-is-implemented) + - [Add a new Appointment](https://ay2122s1-cs2103-w14-1.github.io/tp/DeveloperGuide.html#add-a-new-appointment) + - [Load Appointments on App Launch](https://ay2122s1-cs2103-w14-1.github.io/tp/DeveloperGuide.html#load-appointments-on-app-launch) + - [Save Appointments after every command](https://ay2122s1-cs2103-w14-1.github.io/tp/DeveloperGuide.html#save-appointments-after-every-command) + - [Delete Patient that has made an Appointment](https://ay2122s1-cs2103-w14-1.github.io/tp/DeveloperGuide.html#delete-patient-that-has-made-an-appointment) + * Relevant PRs: [\#93](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/93), [\#317](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/317/files) + * Added [Adding an Appointment](https://ay2122s1-cs2103-w14-1.github.io/tp/DeveloperGuide.html#adding-an-appointment) and 'Deleting a patient that has an appointment' test cases under Instructions for Manual Testing and made note of the similar test case for Edit Appointments. + * Added 'Deleting an Appointment' test cases + * Updated Appointment Use Cases to v1.4 + * Remove `User lists commands` because Doc'it displays full list by default + * Added `Use case: UC06 - Edit an appointment` + * Added [Glossary](https://ay2122s1-cs2103-w14-1.github.io/tp/DeveloperGuide.html#glossary), Glossary credits to User Guide. + * Relevant PRs: [\#322](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/322), [\#319](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/319) + +* **Community**: + * PRs reviewed (with non-trivial review comments): [\#165](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/165), [\#262](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/262), [\#91](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/91), [\#97](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/97)) + * Contributed to forum discussions by raising good questions (examples: [\#58](https://github.com/nus-cs2103-AY2122S1/forum/issues/58)) + * Reported bugs and suggestions for other teams in the class (examples: [1](https://github.com/gycgabriel/ped/issues/8), [2](https://github.com/gycgabriel/ped/issues/1), [3](https://github.com/gycgabriel/ped/issues/6)) diff --git a/docs/team/huyuxin0429.md b/docs/team/huyuxin0429.md new file mode 100644 index 00000000000..6d74a7f7cf0 --- /dev/null +++ b/docs/team/huyuxin0429.md @@ -0,0 +1,48 @@ +--- +layout: page +title: Yu Xin's Project Portfolio Page +--- + +### Project: Doc'IT + +Doc’it provides a centralised platform for authorised staff from small family clinics +to view, update, and onboard patient records and schedule appointments, solving the +inefficient paper records and files used today. With Doc’it, small family clinics can +reduce man-hours in managing paper files, translating this ‘saved’ time into better +frontline care services. + +Given below are my contributions to the project. + +* **New Feature**: Added the Prescription class + * What it does: allows the user to record down prescriptions given to the patient. + * Justification: This allows medical professionals to record down prescriptions provided to patients during each appointment. It also allows them to check past prescription histories of patient. + * Highlights: This enhancement requires careful navigation of nested lists structures and modifies the storage serializer to deal with this structure. + +* **Code contributed**: [RepoSense link](https://nus-cs2103-ay2122s1.github.io/tp-dashboard/?search=&sort=groupTitle&sortWithin=title&timeframe=commit&mergegroup=&groupSelect=groupByRepos&breakdown=true&checkedFileTypes=docs~functional-code~test-code~other&since=2021-09-17&tabOpen=true&tabType=authorship&tabAuthor=huyuxin0429&tabRepo=AY2122S1-CS2103-W14-1%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code&authorshipIsBinaryFileTypeChecked=false) + +* **Project management**: + * Managed releases `v1.1` - `v1.4` (4 releases) on GitHub + +* **Enhancements to existing features**: + * Wrote additional tests for existing features to increase coverage from 66% to 76% (Pull requests [\#59](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/59), [\#277](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/277)) + +* **Documentation**: + * User Guide: + * Added documentation for the features `add prescription` and `delete prescription` [\#181](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/181), [\#306](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/306) + * Developer Guide: + * Wrote target user profile, value proposition and user stories. [\#37](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/37) + * Created Plant-UML diagrams for `prescription` class. [\#181](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/181), [\#306](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/306) + * Added implementation details of the `prescription` feature. [\#181](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/181), [\#306](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/306) +* **Community**: + * PRs reviewed (with non-trivial review comments): [\#44](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/44), [\#282](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/282) + * Contributed to forum discussions (examples: [1](https://github.com/nus-cs2103-AY2122S1/forum/issues/174), [2](https://github.com/nus-cs2103-AY2122S1/forum/issues/195), [3](https://github.com/nus-cs2103-AY2122S1/forum/issues/325)) + * Reported bugs and suggestions for other teams in the class (examples: [1](https://github.com/huyuxin0429/ped/issues/8), [2](https://github.com/huyuxin0429/ped/issues/4), [3](https://github.com/huyuxin0429/ped/issues/9)) + +* **Testing**: + * Designated as main tester for team, in charge of testing and finding ways to break our app. + * Contributed to more than 42% of all bug related issues raised for team. (examples: [1](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/259), [2](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/257), [3](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/157)) + * Emphasized on KISS design principle to team during high level design meetings. + * Input validation: Implemented more restrictive general parsing to reduce likelihood of unintended inputs. [\#232](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/232) + * Introduced more restrictive parsing guidelines for prescriptions. [\#274](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/274) + * Initiated discussions on forum regarding sustainable testing rigor across development life cycle. ([Link here](https://github.com/nus-cs2103-AY2122S1/forum/issues/325)) + diff --git a/docs/team/joshenx.md b/docs/team/joshenx.md new file mode 100644 index 00000000000..b52d5ecaeb0 --- /dev/null +++ b/docs/team/joshenx.md @@ -0,0 +1,209 @@ +--- +layout: page +title: Joshen's Project Portfolio Page +--- + +### Project: Doc'it + +Doc’it provides a centralised platform for authorised staff from small family clinics to view, update, and onboard +patient records, solving the inefficient paper records and files used today. With Doc’it, small family clinics can +reduce man-hours in managing paper files, translating this ‘saved’ time into better frontline care services +Doc'IT is a desktop address book application. The user interacts with it using a CLI, and it has a GUI created +with JavaFX. It is written in Java, and has about 10 kLoC. + +**Summary of Contributions** + +Given below are my contributions to the project: + +- **New Feature**: Added `ArchivedAppointmentBook` class to store details of archived appointments + * What it does: stores details of archived appointments, but prevents internal modification of data. + * Justification: This feature allows the user to archive and view archived appointments, to look at previous patient + prescriptions and past appointments. + * Highlights: The implementation requires careful restriction of access for the new classes + to prevent misuse and inappropriate modification of archived data. + * Credits: Implementation details of `AppointmentBook` by teammate Gabriel Goh + * Relevant PR: [\#69](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/69) + + +- **New Feature**: Integrate `Appointment` and `Prescriptions` into the GUI + * What it does: display appointment information on the GUI. + * Justification: This feature extends the functionality of the CLI application as a user can immediately view upcoming appointments at a glance. + * Highlights: A "TODAY" tag is displayed on appointment cards with appointments scheduled today. Integration of appointments on the GUI was + challenging as many considerations had to be made with regards to how appointments should be handled when patients + were removed from the system. + * Relevant PRs: [\#152](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/152), [\#91](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/91) + + +- **New Feature**: Auto-Archive feature + * What it does: auto-archives expired (24-hour past) appointments. + * Justification: This feature improves the archiving process significantly because + this saves the user trouble of archiving many (e.g. >20) past appointments when + they are already over. + * Highlights: This feature uses a thread pool to schedule the archive command at a specific timing each day. It was challenging to implement testcases due to the time-sensitive nature + of the feature. + * Credits: Implementation adapted from https://stackoverflow.com/a/20388073 + * Relevant PR: [\#155](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/155) + + +- **New Feature**: Sort Appointments feature + * What it does: sorts appointments in order of whether its today, followed by dateTime, and patient name. + * Justification: This feature allows the user to view the most urgent appointments first, and assign prescriptions to the most important + appointments (those happening today). + * Highlights: This feature required use of the Comparable interface for the `Patient` and `Appointment` classes, and + checks with the current system time to verify if an appointment is deemed 'expired'. + * Relevant PR: [\#155](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/155) + + +- **Code contributed**: [RepoSense link](https://nus-cs2103-ay2122s1.github.io/tp-dashboard/?search=&sort=totalCommits&sortWithin=title&timeframe=commit&mergegroup=AY2122S1-CS2103T-W10-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103-W14-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T12-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W15-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T11-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T10-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T17-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W17-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103-T16-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T13-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103-T16-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103-T14-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W10-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103-T16-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T12-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103-F10-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W13-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F11-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F11-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103-F10-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W12-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W10-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103-T14-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W10-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103-F09-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103-T14-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T10-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W17-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W12-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103-F09-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T09-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F12-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T09-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F12-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T13-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103-W14-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103-F10-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W16-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W17-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F11-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W15-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W12-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F12-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W08-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W17-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W11-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T13-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F12-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T15-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103-F09-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W12-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F11-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103-F10-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T11-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W16-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W08-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T17-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W08-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T15-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T15-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T10-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T12-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103-F09-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W15-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T09-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W11-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W08-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W16-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F13-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T09-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T17-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F13-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W13-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F13-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W11-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W15-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T11-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T10-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T13-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W11-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W13-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T12-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103-W14-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W13-4%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-F13-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103-T16-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T11-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103-T14-3%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T17-1%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-W16-2%2Ftp%5Bmaster%5D~AY2122S1-CS2103T-T15-1%2Ftp%5Bmaster%5D&groupSelect=groupByRepos&breakdown=true&checkedFileTypes=docs~functional-code~test-code~other&since=2021-09-17&tabOpen=true&tabType=authorship&tabAuthor=joshenx&tabRepo=AY2122S1-CS2103-W14-1%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code~other&authorshipIsBinaryFileTypeChecked=false) + + +- **Project management**: + * Managed releases `v1.1` - `v1.4` (4 releases) on Github + + +- **Enhancements to existing features**: + * Completely revamped the GUI with modern UI trends [\#121](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/121) + * Wrote additional tests for existing features + * Handled most of the UI changes, UI testing, and UI debugging + + +- **Documentation**: + * User Guide: + * Added documentation for the features Sort Command, Archive Command + * Developer Guide: + * Added documentation for the UI. + * Updated PUML diagrams for UI and Storage classes. [\#96](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/96) + * Added implementation details and PUML diagrams for the Auto-Archive feature and Archive Command. [\#114](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/114), [\#180](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/180), [\#296](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/296) + + +- **Community**: + * Detailed PRs made: [\#88](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/88), [\#121](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/121), [\#152](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/152), [\#155](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/155), [\#175](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/175) + * PRs reviewed (with non-trivial review comments): [\#120](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/120), [\#128](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/128), [\#136](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/136), [\#174](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/174) + +- **Debugging**: + * Bugs fixed: [\#97](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/97), [\#114](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/114), [\#130](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/130), [\#167](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/167), [\#173](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/173), [\#229](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/229), [\#230](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/230), [\#238](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/238), [\#262](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/262) + +
    + +### Contributions to the User Guide: + +### List all archived appointments: `apmt alist` +Shows the list of all archived appointments. + +**Format:** `apmt alist` + +**Examples:** +* `apmt alist` Lists all archived appointments. + +**Expected Outcome:** +``` +[UI CARDS] +1. Patient Name: Bernice Yu | Appointment Date: 2021-1-05 +2. Patient Name: Alex Yeoh | Appointment Date: 2021-1-06 +3. Patient Name: Charlotte Oliveiro | Appointment Date: 2021-1-23 +Listed all archived appointments +``` + +### Archive an appointment: `apmt archive` +Archives an old appointment that is already past its date. + +**Format:** `apmt archive INDEX` +* Archives the appointment at the specified INDEX. +* The index refers to the index number shown in the displayed appointment list. +* The index must be a positive integer 1, 2, 3, ... + +**Examples:** +* `apmt archive 1` Archives appointment at index 1. + +**Expected Outcome:** +``` +Archived Appointment: +Patient: Alex Yeoh; Datetime: 31 Dec 2012 1200; Prescription: [] +``` + +### Sort all appointments: `apmt sort` +Shows a sorted list of all appointments + +**Format:** `apmt sort` + +**Examples:** +* `apmt sort` Lists all appointments. + +**Expected Outcome:** +``` +[UI CARDS] +1. Patient Name: Bernice Yu | Appointment Date: 2021-06-05 +2. Patient Name: Charlotte Oliveiro | Appointment Date: 2021-07-21 +3. Patient Name: Alex Yeoh | Appointment Date: 2021-10-05 +4. Patient Name: David Li | Appointment Date: 2021-10-06 +Sorted Appointments based on default settings. +``` + +
    + +### Contributions to the Developer Guide: + +#### Archiving an Appointment + +**Overview** + +A user is able to archive an appointment when the appointment is _expired_, i.e. the patient has either missed his/her appointment +or already attended the scheduled appointment. In this case, the appointment should be archived, so that clinic staff +are able to view what medicine was prescribed to the patient during previous appointments. + +**Implementation Details** + +![Sequence diagram of Archive Command](../diagrams/ArchiveCommandSequenceDiagram.png) + + +Users may archive specific appointments manually to remove visual clutter. This is done through the `ArchiveAppointmentCommand`. + +The above sequence diagram displays how the archive command works. The parsing mechanism has been abstracted out from the above diagram as it +has been covered in previous diagrams. An example input can be viewed in our [User guide](UserGuide.md). It first retrieves the Appointment to archive from the +appointment index parsed through the user input, removes the appointment from upcoming appointments, and adds it to archived appointments. + +Archiving is facilitated by the `ArchivedAppointmentBook`. As opposed to the regular `AppointmentBook`, it does not allow +users to directly modify the data of appointments as archived data should not be edited. Hence, the following operations +have the `private` access modifier: + +- `ArchivedAppointmentBook#setAppointment(Appointment target, Appointment editedAppointment)` - edits the `target` Appointment + to be replaced with `editedAppointment`. +- `ArchivedAppointmentBook#removeAppointment(Appointment key)` - removes the target Appointment `key`. + +The reason these methods exist in the class is so to support the methods `ArchivedAppointmentBook#updatePatient(Patient target, Patient editedPatient)` +and `ArchivedAppointmentBook#removePatient(Patient target)`, which are called to accurately reflect any updates/removals of patient +details. + +![Class diagram of Archive Storage](../diagrams/ArchivedStorageClassDiagram.png) + +In the `Storage` component, the addition of `ArchivedAppointmentBook` also necessitates the implementation of a separate storage system +for archived appointments. This forms under `ArchivedAppointmentBookStorage`, alongside `AddressBookStorage` and `AppointmentBookStorage`. +The .json file for archived appointments is named 'archivedappointmentbook.json'. + +**Design Considerations** + +| Alternative Considered | Current implementation | Rationale for current implementation | +| ---------- | ------------------------ | ------------------------ | +| Implementing archived appointments as a second `UniqueAppointmentList` attribute under the `AppointmentBook` class | Have a separate class `ArchivedAppointmentBook` | Having a separate class `ArchivedAppointmentBook` separates the two types of appointments better to facilitate data management. It ties in better with our Storage framework, and archivedappointmentbook.json files can be easily used by the user, instead of having to split one appointmentbook.json files into two segments. | + + +#### Auto-Archiving Feature + +The archiving implementation involves scanning through all appointments in a day and comparing it to +the current date and time of the user system. If the current date and time is 24 hours ahead of the scheduled +appointment time (24-hour buffer), i.e. by our definition, _expired_, the appointment is automatically archived. This auto-archiving implementation is handled +by the `ModelManager` class in two ways. + +![Sequence diagram of Auto-Archive Feature](../diagrams/AutoArchiveSequenceDiagram.png) + +1. Upon initialisation of the application, the application automatically archives expired appointments (24-hours past their + scheduled time). This is called through `ModelManager#archivePastAppointments()`. + + +2. A `ScheduledExecutorService` object schedules the task `AutoArchiveApmts` which implements the `Runnable` interface. + Every day at the `ModelManager.UPDATE_HOUR`th hour, the `Runnable` object executes the `ModelManager#archivePastAppointments()` + method. + + +In the case where there are many scheduled appointments, this saves the user trouble of archiving past appointments when +they are already over. diff --git a/docs/team/rish-16.md b/docs/team/rish-16.md new file mode 100644 index 00000000000..2d4c4f7b392 --- /dev/null +++ b/docs/team/rish-16.md @@ -0,0 +1,116 @@ +--- +layout: page +title: Rishabh's Project Portfolio Page +--- + +### Project: `Doc'it` + +#### Overview +`Doc’it` provides a centralised platform for authorised staff from small family clinics to view, update, and onboard +patient records and schedule appointments, solving the inefficient paper records and files used today. With `Doc’it`, +small family clinics can reduce man-hours in managing paper files, translating this ‘saved’ time into better frontline +care services. + +## Contribution Summary + +### Project Specifics +* **Managed releases**: `v1.1` - `v1.4` (4 releases) on GitHub +* **Code contributed**: [Rishabh's RepoSense link](https://nus-cs2103-ay2122s1.github.io/tp-dashboard/?search=rish-16&sort=totalCommits%20dsc&sortWithin=title&timeframe=commit&mergegroup=&groupSelect=groupByAuthors&breakdown=true&checkedFileTypes=docs~functional-code~test-code~other&since=2021-09-17&tabOpen=true&tabType=authorship&tabAuthor=rish-16&tabRepo=AY2122S1-CS2103-W14-1%2Ftp%5Bmaster%5D&authorshipIsMergeGroup=false&authorshipFileTypes=docs~functional-code~test-code&authorshipIsBinaryFileTypeChecked=false&zFR=false) + +--- + +### Enhancements + +* Divided `Command` into `BasicCommand`, `PatientCommand`, and `AppointmentCommand` to promote better OOP. + * Allocated each existing and new command into these 3 categories based on purpose and function. +* Divided `Parser` into `BasicParser`, `PatientParser`, and `AppointmentParser` to promote better OOP. + * Allocated each existing and new command parser into these 3 categories based on purpose and function. +* Removed all mentions of `Tag` from the app and revamped Patient-related tests ([#248](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/248)) +* Wrote unit tests for `EditCommandTest` ([#287](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/287)) +--- + +### Documentation +* User Guide: + * Add description and usage instructions for new commands ([#142](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/142)) + * Cosmetic changes in terms of grammar ([#184](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/184), [#185](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/185), [#248](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/248)) +* Developer Guide: + * Revamped full `Logic` section with breakdown of `Command` ([#165](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/165), ) + * Updated DG with new breakdown of `Command` ([#100](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/100), [#105](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/105), [#248](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/248)) + * Added a new `Parser` section under `Logic` detailing the changes to existing parsers for all commands + * Updated diagrams based on new designs/ideas used throughout DG ([#165](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/165)) + * Add table of contents and fix formatting issues to final release ([#318](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/318)) + +--- + +### Community +* Contributed to [CS2103 Forum](https://github.com/nus-cs2103-AY2122S1/forum/issues) discussions (examples: [#198](https://github.com/nus-cs2103-AY2122S1/forum/issues/198), [#274](https://github.com/nus-cs2103-AY2122S1/forum/issues/274), [#276](https://github.com/nus-cs2103-AY2122S1/forum/issues/276), [#300](https://github.com/nus-cs2103-AY2122S1/forum/issues/300), [#353](https://github.com/nus-cs2103-AY2122S1/forum/issues/353), [#250](https://github.com/nus-cs2103-AY2122S1/forum/issues/350), [#307](https://github.com/nus-cs2103-AY2122S1/forum/issues/307)) +* Have written emails to Prof. Damith on Outlook containing suggestions/feedback on the website and general execution + +--- + +### Absolute Contributions +Here's a list of all the Issues I was assigned:
    +[#8](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/8), +[#14](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/14), +[#27](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/27), +[#56](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/56), +[#80](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/80), +[#81](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/81), +[#109](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/109), +[#112](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/112), +[#118](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/118), +[#137](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/137), +[#138](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/138), +[#144](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/144), +[#154](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/154), +[#156](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/156), +[#160](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/160), +[#188](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/188), +[#189](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/189), +[#190](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/190), +[#191](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/191), +[#192](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/192), +[#193](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/193), +[#194](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/194), +[#207](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/207), +[#215](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/215), +[#228](https://github.com/AY2122S1-CS2103-W14-1/tp/issues/228) + +Here's a list of all my PRs that were approved that addressed the above-mentioned issues:
    +[#34](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/34), +[#44](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/44), +[#61](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/61), +[#65](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/65), +[#100](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/100), +[#101](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/101), +[#104](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/104), +[#105](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/105), +[#133](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/133), +[#140](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/140), +[#142](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/142), +[#165](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/165), +[#168](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/168), +[#184](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/184), +[#185](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/185), +[#226](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/226), +[#227](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/227), +[#243](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/243), +[#248](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/248), +[#287](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/287), +[#318](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/318) + +Here's a list of PRs I reviewed, approved, and merged:
    +[#30](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/30), +[#44](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/44), +[#60](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/60), +[#103](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/103), +[#143](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/143), +[#151](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/151), +[#155](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/155), +[#166](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/166), +[#167](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/167), +[#182](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/182), +[#242](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/242), +[#249](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/249), +[#250](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/250), +[#251](https://github.com/AY2122S1-CS2103-W14-1/tp/pull/251) diff --git a/docs/tutorials/AddRemark.md b/docs/tutorials/AddRemark.md index 8919d8eaa17..d8a40daab15 100644 --- a/docs/tutorials/AddRemark.md +++ b/docs/tutorials/AddRemark.md @@ -16,19 +16,19 @@ We’ll assume that you have already set up the development environment as outli Looking in the `logic.command` package, you will notice that each existing command have their own class. All the commands inherit from the abstract class `Command` which means that they must override `execute()`. Each `Command` returns an instance of `CommandResult` upon success and `CommandResult#feedbackToUser` is printed to the `ResultDisplay`. -Let’s start by creating a new `RemarkCommand` class in the `src/main/java/seedu/address/logic/command` directory. +Let’s start by creating a new `RemarkCommand` class in the `src/main/java/seedu/docit/logic/command` directory. For now, let’s keep `RemarkCommand` as simple as possible and print some output. We accomplish that by returning a `CommandResult` with an accompanying message. **`RemarkCommand.java`:** ``` java -package seedu.address.logic.commands; +package seedu.docit.logic.commands; -import seedu.address.model.Model; +import seedu.docit.model.Model; /** - * Changes the remark of an existing person in the address book. + * Changes the remark of an existing patient in the address book. */ public class RemarkCommand extends Command { @@ -45,7 +45,7 @@ public class RemarkCommand extends Command { Now that we have our `RemarkCommand` ready to be executed, we need to update `AddressBookParser#parseCommand()` to recognize the `remark` keyword. Add the new command to the `switch` block by creating a new `case` that returns a new instance of `RemarkCommand`. -You can refer to the changes in this [diff](https://github.com/se-edu/addressbook-level3/commit/35eb7286f18a029d39cb7a29df8f172a001e4fd8#diff-34ace715a8a8d2e5a66e71289f017b47). +You can refer to the changes in this [diff](https://github.com/AY2122S1-CS2103-W14-1/tp/commit/35eb7286f18a029d39cb7a29df8f172a001e4fd8#diff-34ace715a8a8d2e5a66e71289f017b47). ### Run the application @@ -65,8 +65,8 @@ Following the convention in other commands, we add relevant messages as constant ``` java public static final String MESSAGE_USAGE = COMMAND_WORD - + ": Edits the remark of the person identified " - + "by the index number used in the last person listing. " + + ": Edits the remark of the patient identified " + + "by the index number used in the last patient listing. " + "Existing remark will be overwritten by the input.\n" + "Parameters: INDEX (must be a positive integer) " + "r/ [REMARK]\n" @@ -91,7 +91,7 @@ Let’s change `RemarkCommand` to parse input from the user. We start by modifying the constructor of `RemarkCommand` to accept an `Index` and a `String`. While we are at it, let’s change the error message to echo the values. While this is not a replacement for tests, it is an obvious way to tell if our code is functioning as intended. ``` java -import static seedu.address.commons.util.CollectionUtil.requireAllNonNull; +import static seedu.docit.commons.util.CollectionUtil.requireAllNonNull; //... public class RemarkCommand extends Command { //... @@ -101,8 +101,8 @@ public class RemarkCommand extends Command { private final String remark; /** - * @param index of the person in the filtered person list to edit the remark - * @param remark of the person to be updated to + * @param index of the patient in the filtered patient list to edit the remark + * @param remark of the patient to be updated to */ public RemarkCommand(Index index, String remark) { requireAllNonNull(index, remark); @@ -136,13 +136,13 @@ public class RemarkCommand extends Command { } ``` -Your code should look something like [this](https://github.com/se-edu/addressbook-level3/commit/35eb7286f18a029d39cb7a29df8f172a001e4fd8#diff-34ace715a8a8d2e5a66e71289f017b47) after you are done. +Your code should look something like [this](https://github.com/AY2122S1-CS2103-W14-1/tp/commit/35eb7286f18a029d39cb7a29df8f172a001e4fd8#diff-34ace715a8a8d2e5a66e71289f017b47) after you are done. ### Parse user input Now let’s move on to writing a parser that will extract the index and remark from the input provided by the user. -Create a `RemarkCommandParser` class in the `seedu.address.logic.parser` package. The class must extend the `Parser` interface. +Create a `RemarkCommandParser` class in the `seedu.docit.logic.parser` package. The class must extend the `Parser` interface. ![The relationship between Parser and RemarkCommandParser](../images/add-remark/ParserInterface.png) @@ -221,17 +221,17 @@ public RemarkCommand parse(String args) throws ParseException { If you are stuck, check out the sample -[here](https://github.com/se-edu/addressbook-level3/commit/dc6d5139d08f6403da0ec624ea32bd79a2ae0cbf#diff-fc19ecee89c3732a62fbc8c840250508). +[here](https://github.com/AY2122S1-CS2103-W14-1/tp/commit/dc6d5139d08f6403da0ec624ea32bd79a2ae0cbf#diff-fc19ecee89c3732a62fbc8c840250508). ## Add `Remark` to the model -Now that we have all the information that we need, let’s lay the groundwork for propagating the remarks added into the in-memory storage of person data. We achieve that by working with the `Person` model. Each field in a Person is implemented as a separate class (e.g. a `Name` object represents the person’s name). That means we should add a `Remark` class so that we can use a `Remark` object to represent a remark given to a person. +Now that we have all the information that we need, let’s lay the groundwork for propagating the remarks added into the in-memory storage of patient data. We achieve that by working with the `Patient` model. Each field in a Patient is implemented as a separate class (e.g. a `Name` object represents the patient’s name). That means we should add a `Remark` class so that we can use a `Remark` object to represent a remark given to a patient. ### Add a new `Remark` class -Create a new `Remark` in `seedu.address.model.person`. Since a `Remark` is a field that is similar to `Address`, we can reuse a significant bit of code. +Create a new `Remark` in `seedu.docit.model.patient`. Since a `Remark` is a field that is similar to `Address`, we can reuse a significant bit of code. -A copy-paste and search-replace later, you should have something like [this](https://github.com/se-edu/addressbook-level3/commit/4516e099699baa9e2d51801bd26f016d812dedcc#diff-af2f075d24dfcd333876f0fbce321f25). Note how `Remark` has no constrains and thus does not require input +A copy-paste and search-replace later, you should have something like [this](https://github.com/AY2122S1-CS2103-W14-1/tp/commit/4516e099699baa9e2d51801bd26f016d812dedcc#diff-af2f075d24dfcd333876f0fbce321f25). Note how `Remark` has no constrains and thus does not require input validation. ### Make use of `Remark` @@ -240,11 +240,11 @@ Let’s change `RemarkCommand` and `RemarkCommandParser` to use the new `Remark` ## Add a placeholder element for remark to the UI -Without getting too deep into `fxml`, let’s go on a 5 minute adventure to get some placeholder text to show up for each person. +Without getting too deep into `fxml`, let’s go on a 5 minute adventure to get some placeholder text to show up for each patient. -Simply add the following to [`seedu.address.ui.PersonCard`](https://github.com/se-edu/addressbook-level3/commit/850b78879582f38accb05dd20c245963c65ea599#diff-0c6b6abcfac8c205e075294f25e851fe). +Simply add the following to [`seedu.docit.ui.PatientCard`](https://github.com/AY2122S1-CS2103-W14-1/tp/commit/850b78879582f38accb05dd20c245963c65ea599#diff-0c6b6abcfac8c205e075294f25e851fe). -**`PersonCard.java`:** +**`PatientCard.java`:** ``` java @FXML @@ -254,9 +254,9 @@ private Label remark; `@FXML` is an annotation that marks a private or protected field and makes it accessible to FXML. It might sound like Greek to you right now, don’t worry — we will get back to it later. -Then insert the following into [`main/resources/view/PersonListCard.fxml`](https://github.com/se-edu/addressbook-level3/commit/850b78879582f38accb05dd20c245963c65ea599#diff-12580431f55d7880578aa4c16f249e71). +Then insert the following into [`main/resources/view/PatientListCard.fxml`](https://github.com/AY2122S1-CS2103-W14-1/tp/commit/850b78879582f38accb05dd20c245963c65ea599#diff-12580431f55d7880578aa4c16f249e71). -**`PersonListCard.fxml`:** +**`PatientListCard.fxml`:** ``` xml