search

kangqiao322 / pe

0 stars 0 forks source link

Incorrect return arrows used in sequence diagram from edit command #15

Open kangqiao322 opened 1 year ago

kangqiao322 commented 1 year ago

image.png

The return arrow from the EditCommandParser should be a dashed line and not a solid one.

soc-se-bot commented 1 year ago

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Incorrect UML notation used

Note from the teaching team: This bug was reported during the Part II (Evaluating Documents) stage of the PE. You may reject this bug if it is not related to the quality of documentation.

In Editing a student, tutor or class implementation part in DG, uml diagram

image.png the incorrect notation for return arrow is used

[original: nus-cs2103-AY2223S1/pe-interim#5402] [original labels: severity.VeryLow type.DocumentationBug]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

No details provided by team.

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: [replace this with your explanation]

:question: Issue severity

Team chose [severity.VeryLow] Originally [severity.Medium]

Reason for disagreement: This is not just a minor error as this bug occurs way too frequently within this diagram which may lead to completely confusing the developer. There were at many instances of the return arrow being a solid line (methods were not named if they are self invocations and are ambiguous and thus can be considered as return values) such as ArgumentMultimap and EditCommandParser. This can result in the developer mistaking the constructors to be invoking an operation instead of returning values and vice versa due to the high frequency of this mistake. For a developer relying on the sequence diagram to understand the inner workings of this application, this proves to be a major hindrance as the entire diagram is invalidated by the number of incorrect return arrows and its ambiguity. This is especially so when the explanation for the implementation in the DG is vague as well , for instance, functions such as setPerson, setTuitionClass and updateFilteredTuitionClassList are not explained at all. Thus the severity should be at medium.