[F09-1] NUSSU-Connect #23
Conversation
There was a problem hiding this comment.
Dear team F09-1,
Your team is progressing well and steadily in terms of implementation and documentation. To view your own progress, you could also go to your upstream repo page click 'project insights' tab for activity statistics.
Some housekeeping points you should note moving ahead:
- Each team member should implement at least 1 feature with a UML diagram. As for UML diagrams, they should not include too low-level details or be too big, as that would go against the top-down approach for documentation.
docs/DeveloperGuide.adoc
Outdated
| demonstrates the flow of operation and interaction between the `Logic` and `Model` component in the login mechanism. | ||
| Specifically, the diagram shows what happens when the user inputs the correct login credentials. | ||
|
|
||
| image::LoginSequenceDiagram.png[width="800"] |
There was a problem hiding this comment.
Good use of sequence diagram, based on the following:
- drew proper lifelines for each object
- specified invocation method
- use dashed arrows for return calls.
You may consider using minimal notation:
To reduce clutter, activation bars and return arrows may be omitted if they do not result in ambiguities or loss of information. Informal operation descriptions such as those given in the example below can be used, if more precise details are not required for the task at hand.
docs/DeveloperGuide.adoc
Outdated
| Step 1. The user launches the application for the first time. The `filteredLoginDetails` object will be initialized with | ||
| a list of all the accounts in `LoginBook`. | ||
|
|
||
| image::InitialLoginBookList.PNG[width="300"] |
There was a problem hiding this comment.
Good job in providing snapshots of the dataset for verification.
docs/DeveloperGuide.adoc
Outdated
|
|
||
| The activity diagram below shows the overall picture of how the login mechanism works. | ||
|
|
||
| image::LoginActivityDiagram.png[width="800"] |
There was a problem hiding this comment.
Again, good attempt to include activity diagram to illustrate the workflow of your feature.
Points to improve here:
- it is okay to not explicitly state 'User-System Activities' and 'Condition check' the rectangle /w round corners and diamonds are understood as standard notation in UML.
- likewise you may exclude 'start of login process' and 'terminator', as the solid circles already convey the meaning.
- you can shorten the guard as well.
Please refer to the module website on the topic of Modeling>Activity Diagrams.
docs/DeveloperGuide.adoc
Outdated
|
|
||
| Step 7. Finally a success message is displayed with the details that have been entered by the user. | ||
|
|
||
| image::ExecuteBudgetCommand.png[width="800"] |
There was a problem hiding this comment.
These snapshots be put in the user guide instead, and replace the UI mockups.
Since you have already listed the sequence of steps, it is okay to use a sequence diagram as part of your design process.
Alternatively you may choose to use an activity diagram to model workflows.
|
|
||
| The image below is the sequence diagram for the functioning of the `budget` command: | ||
|
|
||
| image::BudgetCommandSequenceDiagram.png[width="800"] |
There was a problem hiding this comment.
There are some notation errors here. Consider how the activation bar is started and stopped by a method call. See below explanation from module website:
There was a problem hiding this comment.
Alternatively you may opt for minimal notation:
docs/DeveloperGuide.adoc
Outdated
|
|
||
| This method will simply empty the stack. | ||
|
|
||
| image::clearSearchHistoryStack.png[width="800"] |
There was a problem hiding this comment.
Excellent job here in illustrating how the stack works.
docs/DeveloperGuide.adoc
Outdated
|
|
||
| - `undosearch` command + | ||
|
|
||
| image::undoSearchSequenceDiagram.png[width="800"] |
There was a problem hiding this comment.
Good job for drawing the sequence diagram on the following:
- drew proper lifelines for each object
- specified invocation method
- used dashed arrows for return calls.
- clear separation of Logic classes and Model classes
docs/DeveloperGuide.adoc
Outdated
|
|
||
| Before executing the command: | ||
|
|
||
| image::aslbefore.png[width="800"] |
There was a problem hiding this comment.
Again the before and after snapshots of the UI are not mandatory here. Perhaps you could include them in the User guide. You may try to draw a UML diagram to describe your design. Note that each team member should provide at least 1 feature accompanied by 1 UML diagram.
| * **Alternative 2 (Current Choice)**: Separating the Skill and SkillLevel classes into different classes. | ||
|
|
||
| ** Pros: Easier to test. | ||
| ** Cons: Adds to the number of classes unnecessarily. |
There was a problem hiding this comment.
Note that SkillLevel would be an association class. The additional information can be encapsulated in the class.
|
|
||
| * **Alternative 2 (Current Choice)**: Separating the Skill and SkillLevel classes into different classes. | ||
|
|
||
| ** Pros: Easier to test. |
There was a problem hiding this comment.
How is it easier to test? You could explain in a little more detail.
Minor misc changes
Updated Documentation and PPP
edited UG
…into Multiuseraccesslevel
# Conflicts: # src/main/java/seedu/address/model/util/SampleDataUtil.java
Fixed portfolio link for derpyplops
…into Multiuseraccesslevel
Updated login sequence diagram to fit PPP 10 page limit
edited UG
Minor changes to PPP
edited UG
Changed version to v1.4
Reposense update
@derpyplops @sanjukta99 @ladderinc