Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update Documentations #249

Merged
merged 4 commits into from
Nov 14, 2023
Merged

Update Documentations #249

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
4527989
Update UG and DG
cmHuang777 Nov 13, 2023
0e9af26
Merge upstream master
cmHuang777 Nov 13, 2023
1e23f8c
Update DG and PPP
cmHuang777 Nov 13, 2023
43d86cc
Merge branch 'master' into Documentations
kohkaijie Nov 14, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 31 additions & 40 deletions docs/DeveloperGuide.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ title: Developer Guide
## Table Of Contents

* Table of Contents
{:toc}
{:toc}

--------------------------------------------------------------------------------------------------------------------

Expand Down Expand Up @@ -96,8 +96,7 @@ 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/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java)

![Structure of the UI Component](images/UiClassDiagram.png)

Expand Down Expand Up @@ -151,10 +150,10 @@ Here are the other classes in `Logic` (omitted from the class diagram above) tha
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
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., `AddCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser`
* All `XYZCommandParser` classes (e.g., `AddPatientCommandParser`, `DeleteCommandParser`, ...) inherit from the `Parser`
interface so that they can be treated similarly where possible e.g, during testing.

### Model component
Expand All @@ -177,17 +176,12 @@ The `Model` component,
* does not depend on any of the other three components (as the `Model` represents data entities of the domain, they
should make sense on their own without depending on other components)

<div markdown="span" class="alert alert-info">:information_source: **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Tag` list in the `AddressBook`, which `Person` references. This allows `AddressBook` to only require one `Tag` object per unique tag, instead of each `Person` needing their own `Tag` objects.<br>

<img src="images/BetterModelClassDiagram.png" width="450" />

</div>

### Storage component

**API** : [`Storage.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/storage/Storage.java)

<img src="images/StorageClassDiagram.png" width="550" />
<img src="images/StorageClassDiagram.png" width="700" />

The `Storage` component,

Expand All @@ -211,7 +205,7 @@ This section describes some noteworthy details on how certain features are imple
### Add Patient/Doctor Feature

This feature allows users to add patients or doctors to the address book. No duplicated person should be added. There
are many fields for each patient/doctor which can be found in the user guide.
are many fields for each patient/doctor which can be found in the user guide. The implementation for adding patient and doctors are similar, we just need to change the relevant command name from patient to doctor. For the below details, we will just patient when mentioning the commands.

#### Implementation

Expand All @@ -223,23 +217,26 @@ Given below is an example usage scenario and how the add patient/doctor mechanis
Step 1. The user launches the application for the first time. The AddressBook will be initialized with the initial
address book state.

Step 2. The user types `add-patient` (or `add-Doctor`) as command, with the appropriate arguments for the person, for
example, `add-patient n/John Doe ic/S9851386G g/M p/98765432 ec/90123456 e/johnd@example.com a/John street, block 123, #01-01 d/T0123456H c/pneumothorax b/O+`.
Step 2. The user types `add-patient` (or `add-doctor`) as command, with the appropriate arguments for the person, for example, `add-patient n/John Doe ic/S9851386G g/M p/98765432 ec/90123456 e/johnd@example.com a/John street, block 123, #01-01 d/T0123456H c/pneumothorax b/O+`.

Step 3. The `AddressBookParser` parses the arguments and determine the required command parser based on the first word
of the arguments.

Step 4. Then `addPatientCommandParser` parses the remaining arguments and creates an `AddPatientCommand` with the
details of the patient given.

<div markdown="block" class="alert alert-info">
:information_source: **Note:** If the details of the person added does not match the correct format for any fields,
there will be an error telling user that the attributes are in the wrong format.
</div>

Step 5. The `AddPatientCommand` then gets executed and calls the Model#addPatient() and the patient will be added to
the `uniquePatientList` of the addressbook in the model.

<div markdown="block" class="alert alert-info">
:information_source: **Note:** If the Person to be added is already in the respective list in the addressbook, it will
return an error saying that this is a duplicate person. This will be checked during the execution of the Add command.
</div>

Step 6. The UI should display using the updated list of patients and the newly added patient should be in the patient
section of the GUI.
Expand Down Expand Up @@ -277,16 +274,18 @@ address book state.
Step 2. The user types `edit T0123456H` (or the relevant ic number) as command, with the appropriate arguments for the person, for
example, `edit T0123456H n/John Doe g/M p/98765432 ec/90123456 e/johnd@example.com a/John street, block 123, #01-01 d/T0123456H c/pneumothorax b/O+`.

Step 3. The `AddressBookParser` parses the arguments and determines the that EditCommandParser is required based on the first word
Step 3. The `AddressBookParser` parses the arguments and determines that the EditCommandParser is required based on the first word
of the arguments.

Step 4. Then `editCommandParser` parses the remaining arguments and creates an `EditCommand` with the
details of the patient given.

<div markdown="block" class="alert alert-info">
:information_source: **Note:** If the details of the person added does not match the correct format for any fields,
there will be an error telling user that the attributes are in the wrong format. Also, if there are no attributes passed there will be an error.
It's ok if the attributes are the same as the original attributes.
Lastly, an NRIC must be provided and if the nric cannot be found within the list of doctors and patients, there will be an error.
</div>

Step 5. The `EditCommand` then gets executed and calls the Model#setPerson() with the original person and the new
edited person. The original person will be replaced by the edited person.
Expand All @@ -308,8 +307,7 @@ The following sequence diagram shows how the add patient works:
2. Option 2: Use 2 commands edit-patient and edit-doctor
- Pros: The program might be faster. If you call edit-doctor you only need to search through a few doctors
rather than all the patients as well.
- Cons: Harder to implement, and there's a need to create new classes and add repeated code.
More commands for the user to remember as well.
- Cons: Harder to implement, and there's a need to create new classes and add repeated code. More commands for the user to remember as well.

### Delete Patient/Doctor Feature

Expand Down Expand Up @@ -346,36 +344,33 @@ can be found in the user guide.

#### Implementation

Implementation of creating an appointment is comprised of fairly new code. The adding mechanism is facilitated by the
AddressBook in the model.
Implementation of creating an appointment is comprised of fairly new code. The adding mechanism is facilitated by the AddressBook in the model.

Given below is an example usage scenario and how the new appointment mechanism behaves at each step.

Step 1. The user launches the application for the first time. The AddressBook will be initialized with the initial
address book state.
Step 1. The user launches the application for the first time. The AddressBook will be initialized with the initial address book state.

Step 2. The user populates the AddressBook with patients and doctors using the appropriate commands, if not already
done.
Step 2. The user populates the AddressBook with patients and doctors using the appropriate commands, if not already done.

Step 3. The user types `new-appointment`as command, with the appropriate arguments for the appointment, for example,
`new-appt pic/T0123456H dic/S9851586G time/2022-02-14 13:00:00`.

Step 4. The `Doctor` and `Patient` Class methods are used to add the details to the respective objects. This works in
a similar way to how the `NRIC` Class works for the `Doctor` and `Patient` Classes. `Appointment` is done externally for
Step 4. The `Doctor` and `Patient` Class methods are used to add the details to the respective objects. This works in a similar way to how the `NRIC` Class works for the `Doctor` and `Patient` Classes. `Appointment` is done externally for
OOP reasons.

Step 5. The `addPatientCommandParser`/ `addDoctorCommandParser` parses the Appointment and creates an `AddPatientCommand`/
`addDoctorCommand` with the details of the `Appointment` given.
Step 5. The `addPatientCommandParser`/ `addDoctorCommandParser` parses the Appointment and creates an `AddPatientCommand`/ `addDoctorCommand` with the details of the `Appointment` given.

<div markdown="block" class="alert alert-info">
:information_source: **Note:** If the details of the person added does not match the correct format for any fields,
there will be an error telling user that the attributes are in the wrong format.
</div>

Step 6. The `PatientCard` / `DoctorCard` then processes the appointment details and The UI should display the appointment
details for each Person in the AddressBook.
Step 6. The `PatientCard` / `DoctorCard` then processes the appointment details and The UI should display the appointment details for each Person in the AddressBook.

The following sequence diagram shows how the New Appointment works:
The following sequence diagram and activity diagram shows how the New Appointment works:

![AddPatientSequenceDiagram](images/AddPatientSequenceDiagram.png) //change this
![AddAppointmentSequenceDiagram](images/AddAppointmentSequenceDiagram.png)
![AddAppointmentActivityDiagram](images/AddAppointmentActivityDiagram.png)


### Undo/redo feature
Expand Down Expand Up @@ -440,9 +435,7 @@ before the `undo` command.

</div>

Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such
as `list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`.
Thus, the `addressBookStateList` remains unchanged.
Step 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.

![UndoRedoState4](images/UndoRedoState4.png)

Expand Down Expand Up @@ -478,9 +471,6 @@ The following activity diagram summarizes what happens when a user executes a ne

_{more aspects and alternatives to be added}_

### \[Proposed\] Data archiving

_{Explain here how the data archiving feature will be implemented}_


--------------------------------------------------------------------------------------------------------------------
Expand Down Expand Up @@ -531,7 +521,6 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli
| `*` | Hospital Staff | undo previous command | prevent mistakes |
| `*` | Hospital staff | redo previously undid command | prevent mistakes |

*{More to be added}*

### Use cases

Expand Down Expand Up @@ -720,8 +709,10 @@ otherwise)
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.
4. The size of the application’s jar file should not exceed 100MB.
5. The app should respond fast enough for any user command. (less than 3 seconds)
6. The app should not take too long to start. (less than 15 seconds)

*{More to be added}*

### Glossary

Expand Down
Loading
Loading