[CS2103T-F14-2] TutorAid #91
Conversation
docs/DeveloperGuide.adoc
Outdated
| @@ -297,33 +298,33 @@ Priorities: High (must have) - `* * \*`, Medium (nice to have) - `* \*`, Low (un | |||
| |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 |add a new task | check the details of the task when I want | |||
There was a problem hiding this comment.
User vs Tutor: Do they refer to the same type of user? Would appreciate a bit more details with respect to the differences between these two types of users.
There was a problem hiding this comment.
Task: Perhaps a bit more detail with respect to what a task refers to, currently we're not sure what a task is.
| 1. User requests to list tasks | ||
| 2. TutorAid shows a list of tasks | ||
| 3. User requests to delete a specific task in the list | ||
| 4. TutorAid deletes the person |
There was a problem hiding this comment.
Should be "task" instead of "persons"
|
|
||
| [discrete] | ||
| === Use case: Delete person | ||
| === Use case: Delete task |
There was a problem hiding this comment.
Nice flow of use case, but can also include in user stories since it is a feature for the user.
docs/DeveloperGuide.adoc
Outdated
|
|
||
| |`*` |user with many persons in the address book |sort persons by name |locate a person easily | ||
| |`*` |caring tutor |check the upcoming events |remind my students |
There was a problem hiding this comment.
Events: Does event refer to class schedules or to things like deadlines (ie are regularly scheduled or one-off things)?
docs/DeveloperGuide.adoc
Outdated
| *Example* | ||
| The following activity diagram summarizes what happens when a user executes a new command. | ||
|
|
||
| image::AddEarningsActivityDiagram.png[] |
There was a problem hiding this comment.
The branching node (input is valid) only has one branch. Maybe include a second arrow for else that goes to the end of the diagram? Also, "input is valid" should be contained within square brackets ([input is valid]).
There was a problem hiding this comment.
Design diagrams have been unchanged since AB3. From how it looked like in Implementation, I would assume that there have been some changes to the architecture? I could be mistaken, of course.
| @@ -153,6 +153,73 @@ Classes used by multiple components are in the `seedu.addressbook.commons` packa | |||
|
|
|||
| This section describes some noteworthy details on how certain features are implemented. | |||
|
|
|||
| === Earnings Feature | |||
docs/DeveloperGuide.adoc
Outdated
| following input from the user: `Date`, `ClassId`, `Amount`, which will construct `Earnings` objects. | ||
|
|
||
| .Add Earnings Command Sequence Diagram | ||
| image::AddEarningsSequenceDiagram.png[] |
There was a problem hiding this comment.
Is your class still called AddressBookParser? Should it be renamed?
Code Refactoring and Documentations
Branch test classes
Delete button features
added in delete button and test cases updates
Added some tests for added commands
Added claim earnings method
@TeoShyanJie
@ngswbryan
@Xuerneas
@kerwin97