Sequence Diagram for 'Logic' `Delete` is Missing Methods

[ZaydM18]

The sequence diagram for a simple delete command is missing certain methods. While trivial or very deep methods may be omitted for the sake of convenience, it should be expected for some of the intermediary commands to be shown in more detail, for example the method call between :HouseholdParser and :DeleteHouseholdCommandParser.

[nus-pe-script]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

Since the method call you are highlighting is talking about the constructor, it seems quite apparent that the constructor is being called hence there is no ambiguity as a result of omitting the method call

Items for the Tester to Verify

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement: Although the command is calling the constructor, which may appear trivial, the specific method call would be more appropriate to view here, given that it is gradually unwrapping the command, which draws attention to the level of abstraction used in the OOP model of the project. Since sequence diagrams are intended to highlight the interaction between different classes and given that the example used is the only sequence diagram in the DG that covers Logic, it would be more apt to show how the different classes slowly 'unwrap' a command using the different method calls within each class. For instance, observe the behaviour of the HouseholdBookParser class. How is the parseCommand formatted below given that the arguments from the initial string user input is first thrown into a Matcher, and only then passed into a :DeleteHouseholdCommandParser? This would be relevant to devs who are interested in understanding how the OOP model works in the form of a practical sequence diagram. If this were not in scope, I would still understand (if they don't see this information as necessary, even though I believe that this is a matter of perspective), but I do not believe this bug should have been rejected due to the arguments presented above. I stand by my initial bug.

---

❓ Issue severity

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

• I disagree

Reason for disagreement: Regarding the severity of the bug, I think it is a matter of perspective. Although I can understand where the dev team is coming from, in my opinion the argument for the bug would suggest that this is not simply a cosmetic issue, but one of logic. The dev team has argued from the perspective that the sequence of operations involves trivial commands that have been omitted, which implies that it was a deliberate decision on their part. Therefore, if the bug is accepted, it would not simply be a cosmetic issue, as that implies some sort of error on the dev team's part, but this was likely intended behaviour. Therefore, since this issue would then be one of logic or understanding, it would make more sense to upgrade the bug to low severity.

---