From e1e63c8df70640dfc32f1702737867d84d8b9b42 Mon Sep 17 00:00:00 2001 From: jskimdev Date: Mon, 15 Apr 2024 23:51:29 +0800 Subject: [PATCH] Update page break --- docs/DeveloperGuide.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md index e8e870f21a5..5c8d1c9a57a 100644 --- a/docs/DeveloperGuide.md +++ b/docs/DeveloperGuide.md @@ -9,6 +9,8 @@ +
+ -------------------------------------------------------------------------------------------------------------------- ## **Acknowledgements** @@ -68,6 +70,8 @@ For example, the `Logic` component defines its API in the `Logic.java` interface The sections below give more details of each component. +
+ ### UI component The **API** of this component is specified in [`Ui.java`](https://github.com/AY2324S2-CS2103T-T14-2/tp/blob/master/src/main/java/seedu/address/ui/Ui.java) @@ -85,6 +89,8 @@ The `UI` component, * 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 `Patient` object residing in the `Model`. +
+ ### Logic component **API** : [`Logic.java`](https://github.com/AY2324S2-CS2103T-T14-2/tp/blob/master/src/main/java/seedu/address/logic/Logic.java) @@ -118,6 +124,8 @@ How the parsing works: * When called upon to parse a user command, the `InputParser` 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 `InputParser` returns back as a `Command` object. * All `XYZCommandParser` classes (e.g., `AddCommandParser`, `DeleteByIndexCommandParser`, ...) 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/AY2324S2-CS2103T-T14-2/tp/blob/master/src/main/java/seedu/address/model/Model.java) @@ -136,6 +144,8 @@ The `Model` component, * 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). +
+ ### Storage component **API** : [`Storage.java`](https://github.com/AY2324S2-CS2103T-T14-2/tp/blob/master/src/main/java/seedu/address/storage/Storage.java) @@ -151,6 +161,8 @@ The `Storage` component, Classes used by multiple components are in the `seedu.address.commons` package. +
+ -------------------------------------------------------------------------------------------------------------------- ## **Implementation** @@ -256,6 +268,8 @@ user truly wants to delete all entries when the 'delete-all' command is given. If the user wishes to bypass the safety check and is certain of the intent to delete all entries, the user can enter 'delete-all-f' command to forcefully delete all entries. +
+ ### Visit feature #### Implementation @@ -281,6 +295,8 @@ The initial design was to have the 3 `Visit` fields be part of the `Patient` obj * [Configuration guide](Configuration.md) * [DevOps guide](DevOps.md) +
+ -------------------------------------------------------------------------------------------------------------------- ## **Appendix: Requirements** @@ -317,6 +333,8 @@ Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unli | `* *` | receptionist | exit with a command | close the application with keyboard inputs only | +
+ ### Use cases (For all use cases below, the **System** is the `MediTrack` and the **Actor** is the `receptionist`, unless specified otherwise)