[CS2113T-F11-1] nocap#44
Conversation
|
|
||
| **API** : module | ||
|
|
||
| Data from all the modules are stored in the ModuleList class. This includes: |
There was a problem hiding this comment.
Maybe could add markups for ModuleList and ScheduleList as well to standardize with the rest of the components
|
|
||
| **API** : `semester` | ||
|
|
||
|  |
There was a problem hiding this comment.
Should the arrow from module list to module have a diamond at module cause it seems like an aggregation or composition of module objects
| # Design & Implementation | ||
|
|
||
| {Describe the design and implementation of the product. Use UML diagrams and short code snippets where applicable.} | ||
| ## Parser |
There was a problem hiding this comment.
Maybe add a subheading on how NoCap as a whole works like how you've done for parser. As in a program flow from user input till the output returned to user, showing how all the components work together.
|
|
||
|
|
||
|
|
||
| 1. `TaskList` stores all tasks in an `ArrayList<Task>`. |
There was a problem hiding this comment.
| Step 5: `overallListParser` creates an `OverallTaskList`. Through nested switch cases, **TaskType** and ** | ||
| TaskDescription** are matched, and the corresponding method `OverallTaskList#sortByDateAndPrint()` is called. As the |
There was a problem hiding this comment.
Appears incorrectly as TaskType and ** TaskDescription**.
| - If day of week and timeslot corresponds, venue and comments information is printed out | ||
| - If day of week and timeslot does not correspond, and blank character " " is printed instead. |
There was a problem hiding this comment.
Formatting here seems off. Appears like this:
| day of week | ||
|
|
||
| timeslot | ||
|
|
||
| location | ||
|
|
||
| comments |
There was a problem hiding this comment.
Could format this better like this section for consistency:
Currently appears like this:
| <<<<<<< HEAD | ||
| The modules are stored in an ArrayList and ModuleList uses the Module.get(int index) method to access the target Module. |
There was a problem hiding this comment.
Formatting is incorrect here. Appears like this:
| `list task sortbydate`. | ||
|
|
||
| The Sequence Diagram below illustrates the process | ||
|  |
There was a problem hiding this comment.
I think the group missed out on the colon : on the entity boxes for this sequence diagram
|
|
||
| The diagram below illustrates the `splitString` process: | ||
|
|
||
|  |
There was a problem hiding this comment.
Perhaps using a sequence diagram here is better? To make it more consistent with the diagram types you have been using throughout the DG.
Other developers may have different interpretations for non standard diagrams
|
|
||
|  | ||
|
|
||
| * When `commandAddGrade()` or `commandAddCredit()` is called in Parser, `addgrade(description)` |
There was a problem hiding this comment.
perhaps the group meant addGrade(description) here instead of addgrade(description)
|
|
||
| All data related to module is stored in the module class. An Arraylist of Module is used to store and manage the modules. ModuleList is also responsible for constructing and printing out the Timetable. | ||
|
|
||
|  |
There was a problem hiding this comment.
There is a minor formatting error in this diagram for #int: credits
| - ModuleList contains the getter method find(String input) which returns a module by the same name as the input. | ||
| - Module contains getter and setter methods to change or access its contents. | ||
| - When Module is constructed, an empty gradableTaskList, taskList and scheduleList wll be instantiated and stored in Module. | ||
|
|
There was a problem hiding this comment.
Perhaps the use of markdown here will make it clearer here.
It appears that the use of markdown is minimal in this section here. The group may want to consider using more markdowns for this section
| - If day of week and timeslot corresponds, venue and comments information is printed out | ||
| - If day of week and timeslot does not correspond, and blank character " " is printed instead. | ||
| ======= | ||
| #  |
There was a problem hiding this comment.
The group perhaps forget to include colon : for the entity boxes in this sequence diagram.
| list. | ||
| 3. toString() prints out all relevant schedule information in a list format. This is done by going through the list and | ||
| printing Schedule one after another. | ||
|
|
There was a problem hiding this comment.
Perhaps more markdowns can be used here to differentiate a code from a normal text
| characters in length. This is to ensure that it fits within its time slot within the Timetable when printed. | ||
|
|
||
|  | ||
|
|
There was a problem hiding this comment.
Colon : is missing here for the entity boxes
| The class diagram below is an overview of relationship between Parser classes and other classes. | ||
|
|
||
| {Describe the value proposition: what problem does it solve?} | ||
|  |
There was a problem hiding this comment.
The high level class diagram is a good addition for the reader to understand the overall structure of the parser. But perhaps you could try to follow the same style of class diagram that you have used for Semester.
|
|
||
| **API** : `semester` | ||
|
|
||
|  |
There was a problem hiding this comment.
This might perhaps be a aggregation relation instead as there seems to be a list of semester objects inside the semesterList class.
|
|
||
| **API** : `task.tasklist` | ||
|
|
||
|  |
There was a problem hiding this comment.
The self calling arrows here on TaskList are a little confusing to understand at first glance. You could perhaps extend the length of the activation block so that the arrows could be more spaced out.
| 1. Whenever the `Task` object is instantiated, the `attributes` listed above will be initialized by the `setter` | ||
| methods: `setDescription()`, `setDate()`, `setDone()`, `setLate()` and `setDeadline()`. | ||
| 2. When calling `printAllTask()`, `printWeeklyTask()`, `printMonthlyTask()` in `OverallTaskList` the | ||
| method `updateOverdue()`will be called which checks for the truth value of the `boolean` attribute `isDone` and also | ||
| whether the current date and time of the system clock is after the `deadline` of the `Task` object. | ||
| 3. If `isDone` is `FALSE` and the `deadline` is later than the current date and time, `updateOverdue()` will set the | ||
| attribute `isLate` of the current `Task` object to `TRUE`. | ||
| 4. Calling the toString prints out the task information in the Task object. |
There was a problem hiding this comment.
You could perhaps draw a sequence diagram for this set of steps just like how you have done for the others to help with clarity.
Add list gradable command
* 'master' of https://github.com/AY2122S1-CS2113T-F11-1/tp: add /m module list gradable add /m module list gradable Remove magic number fix checkstyle issues Update UG to give clearer explanation on list task functions Updated UG Edit UG Updated UG Bug fixes checkstyle fix bugs mainly in UG UG updates
Add grade bug and UG updates
Branch fix functional bugs
- Added list task normal
Add ug list task section
* 'master' of https://github.com/AY2122S1-CS2113T-F11-1/tp: Add ug list task section fix bug fix checkstyle fix checkstyle fix functional bugs addgrade bug fix
Add documentation for parser methods
Create Project portfolio page
chagnes
0 credit bug update
add gradable man testing 2
add feedback to task editdeadline
Finalbugfixes
Final Edits
Changed updateOverdue() to allow setting isLate to false
Bug fixes
Bug fixes
10 participants
NoCap (NC) is a desktop app for managing modules taken in NUS, optimized for use via a Command Line Interface (CLI). If you can type fast, NC can get your module management tasks done faster than traditional GUI apps. It is the perfect app for NUS students!