No mention of object deletion

[DannyDakota]

Expected:
Note: The lifeline for DeleteCommandParser should end at the destroy marker (X) but
due to a limitation of PlantUML, the lifeline reaches the end of diagram

Actual:
This note is missing under the diagram

[soc-pe-bot]

Team's Response

The note is found below the diagram after this particular diagram.
The team decided to leave the note after two diagrams as it applies to both diagram and to reduce clutter and duplication of the same note.

Items for the Tester to Verify

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement: For the same reason AB3 places a note at the bottom when there is object deletion, it is imperative to make it clear that the lifeline of the command ends at the destroy marker. The team states that the team decided to leave the note after two diagrams and thus is probably referring to this.

However, it is worthy to note that the note over here is DeleteCommandParser specific. They did not state that this note applies to all other object deletions in the various class diagrams they have used. For example, the FilterSkillCommandParser, AddCommandParser.

If the team wanted to use this note to encompass all object deletion scenarios, they should have used a general note that concisely states that such an error with plantUML encompasses all usages of the destroy marker.

Therefore, a user has reasonable grounds to believe that the note for the destroy marker displayed for the UndoCommand and DeleteCommandParser is only for the UndoCommand and DeleteCommandParser respectively, and not all other instances of destroy markers in the DG, and thus logically cannot be denied of believing the fact that the lifeline doesn't end after the destroy marker.

I also now have reason to believe that this is a severity.Low bug due to the inconvenience brought about to developers reading the DG as half of the diagrams does not have this note. The reason I chose this as veryLow initially was because I believed that this fundamentally is a cosmetic issue. However, after careful consideration of the extent to which this note is left out, developers could easily be confused, requiring them to cross-reference with the code and thus inconvenience is brought about. Furthermore, bringing back to the bug report in question, by leaving the note 2 diagrams after its supposed position in the DG, brings about inconvenience to the user as they have to refer back to the earlier diagrams to figure out what the note is talking about. This is made worse by the fact that note was in an entirely new page, hindering the reader due to the lack of proper integration of the note.

---