Skip to content

Commit

Permalink
Add explanation on extensions to add and edit command
Browse files Browse the repository at this point in the history
Lack of explanation to how add and edit command works, and birthday and priority features.

Updating the developer guide will make future understanding easier.

Let's
* Add PUML object and sequence diagrams for add command.
* Add brief explanation on how add and edit commands and command parsers work.
* Add explanation of birthday class.
* Add explanation of priority class and priority value enum.
  • Loading branch information
solomonng2001 committed Mar 28, 2024
1 parent c12467f commit b726205
Show file tree
Hide file tree
Showing 3 changed files with 126 additions and 0 deletions.
43 changes: 43 additions & 0 deletions docs/DeveloperGuide.md
Original file line number Diff line number Diff line change
Expand Up @@ -184,6 +184,49 @@ The following object diagram illustrates the above:
The following sequence diagram shows the addpolicy operation:
<puml src="diagrams/AddPolicySequenceDiagram.puml" width="900" />

### Enhancements to add command end edit command: Add birthday, edit birthday, add priority, edit priority features

The add birthday and edit birthday features allow users to add and edit the birthday of a client. Birthdays support the birthday reminders feature. The birthday is stored in the `Birthday` class, which contains the birthday details such as day, month, and year. The `Birthday` class is part of the `Person` object in the `Model` component.

The add priority and edit priority features allow users to add and edit the priority of a client. Priority supports the sort by priority feature, and helps optimise client management. The priority is stored in the `Priority` class, which contains the priority details such as priority value. The priority value are enumerated, and can be one of the following: LOW, MEDIUM, HIGH, VIP. The `Priority` class is part of the `Person` object in the `Model` component.

#### Implementation

The functionality to add and edit birthday and priority is implemented in the `AddCommand` and `EditCommand` classes. The `AddCommandParser` and `EditCommandParser` classes are responsible for parsing the user input and creating an `AddCommand` or `EditCommand` object respectively.

The `AddCommandParser` and `EditCommandParser` classes parse the input arguments by storing the prefixes of their respective values in a `ArgumentMultimap` object, and create a new `AddCommand` or `EditCommand` object with the parsed birthday or priority, amongst other fields.

The `AddCommand` and `EditCommand` objects then communicate with the `Model` component to add or edit the birthday or priority of the client. The `Model` component then updates the `Person` object with the new birthday or priority, amongst other fields.

The `AddCommand` object then communicates with the `Model` component to add a person.
- `Model#addPerson(Person)` - Adds the new client to the existing client list.
- `Model#setDisplayClient(Person)` - Updates the displayed client in the UI to the client that has been added.

The following object diagram illustrates the above:
<puml src="diagrams/AddPersonObjectDiagram.puml" width="600" />

The following sequence diagram shows the addpolicy operation:
<puml src="diagrams/AddPersonSequenceDiagram.puml" width="900" />

More on birthday class
* Birthday is immutable and stores the day, month and year as a `LocalDate` object, as time is not relevant for birthday.
* The message constraints for birthday utilise the `DateUtil` common class to ensure that the date is valid and in the correct format.
* `DateUtil` class is used to validate (conforms to `DateUtil` date format and is parsable) and parse the string to a `LocalDate` object. `DateUtil` is also used to ensure that the date is in the past.
* Refer to the `DateUtil` class for more information on the date format and parsing.

More on priority class
* Priority is immutable and stores the priority value as a `PriorityValue` object, which is an enumerated type, to ensure that priority value is a valid type.
* The message constraints for priority utilise the `PriorityValue` enum class which should be responsible for the `toString()` logic for display.
* `PriorityValue` enum class is used to validate the priority value, which is responsible for the possible valid priority values.
* Refer to the `PriorityValue` enum class for more information on the priority values.

More on priority value enum class
* `PriorityValue` is an enumerated type that contains the possible valid priority values: LOW, MEDIUM, HIGH, VIP.
* When parsing from a string and displaying as a string, the `PriorityValue` allows full form values (`low`, `medium`, `high`, `vip`) and short form values (`l`, `m`, `h`, `v`) to be used interchangeably.
* Parsing from a string to a `PriorityValue` object is case-insensitive, and is handled by `getPriority`.
* Obtaining the all available full form and short form of the `PriorityValue` object is handled by `getFullPriorities()` and `getShortPriorities()` respectively.
* The mapping of the full form strings and short form strings to the enum values is handled through `HashMap<String, PriorityValue> FULL_PRIORITY_MAP` and `HashMap<String, PriorityValue> SHORT_PRIORITY_MAP`, which has a constant time complexity.

### \[Proposed\] Undo/redo feature

#### Proposed Implementation
Expand Down
23 changes: 23 additions & 0 deletions docs/diagrams/AddPersonObjectDiagram.puml
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
@startuml
!include style.puml
skinparam objectFontColor white

object "<u>:AddCommand</u>" as AddCommand LOGIC_COLOR
object "<u>:AddCommandParser</u>" as AddCommandParser LOGIC_COLOR
object "<u>:AddressBookParser</u>" as AddressBookParser LOGIC_COLOR
object "<u>:Model</u>" as Model MODEL_COLOR
object "<u>:CommandResult</u>" as CommandResult LOGIC_COLOR
object "<u>toAdd:Person" as Person LOGIC_COLOR
object "<u>:ArgumentMultimap" as ArgumentMultimap LOGIC_COLOR
object "<u>:ParserUtil" as ParserUtil LOGIC_COLOR

AddressBookParser --> AddCommandParser : calls
AddressBookParser --> AddCommand
AddCommandParser -> AddCommand
AddCommandParser --> ArgumentMultimap : instantiates
ParserUtil --> ArgumentMultimap : parses
AddCommand --> Person
AddCommand --> Model
AddCommand -right-> CommandResult : outputs
Model --> Person : Adds
@enduml
60 changes: 60 additions & 0 deletions docs/diagrams/AddPersonSequenceDiagram.puml
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
@startuml
!include style.puml
skinparam ArrowFontStyle plain

box Logic LOGIC_COLOR_T1
participant ":LogicManager" as LogicManager LOGIC_COLOR
participant ":AddressBookParser" as AddressBookParser LOGIC_COLOR
participant "a:AddCommand" as AddCommand 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(...)
activate LogicManager

LogicManager -> AddressBookParser : parseCommand(...)
activate AddressBookParser

create AddCommand
AddressBookParser -> AddCommand : AddCommand(...)
activate AddCommand

AddCommand --> AddressBookParser
deactivate AddCommand

AddressBookParser --> LogicManager : a
deactivate AddressBookParser

LogicManager -> AddCommand : execute()
activate AddCommand

AddCommand -> Model : addPerson(toAdd)
activate Model

Model --> AddCommand
deactivate Model

AddCommand -> Model : setDisplayClient(toAdd)
activate Model

Model --> AddCommand
deactivate Model

create CommandResult
AddCommand --> CommandResult
activate CommandResult

CommandResult --> AddCommand
deactivate CommandResult

AddCommand --> LogicManager : result
deactivate AddCommand
AddCommand -[hidden]-> LogicManager : result
destroy AddCommand

[<--LogicManager
deactivate LogicManager
@enduml

0 comments on commit b726205

Please sign in to comment.