Wrong arrow for abstract class implementation for Adding/deleting feature.

[vevek]

Wrong arrow for abstract class implementation. Some of the arrows for abstract class inheritance are solid, while some are dotted.

Expected: All arrows to have solid lines.

As shown in the screenshots,

For a different screenshot. They both contradict one another.

[nus-pe-bot]

Team's Response

No response provided.

The 'Original' Bug

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

Wrong notation for abstract class extension

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.

---

I believe wrong notation is used here to extend to abstract class Command. Should be solid line instead.

---

_{[original: nus-cs2103-AY2021S2/pe-interim#1566] [original labels: severity.Low type.DocumentationBug]}

Their Response to the 'Original' Bug

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

No response provided.

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)

• [x] I disagree

Reason for disagreement: In my bug report. I referenced 2 separate screenshots that highlight 2 different instances of the issue, where one of the instances may be wrong. The screenshots show contradictory use of solid/dotted lines. Hence, either way, one of the instances have to be wrong. Thus, it is not a duplicate of the original issue, as it references a similar but different example in another section of the DG.

Screenshots of the different sections:

and ---------------------------------------------

---

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I do not know why the developer team rejected this issue, as they did not provide an explanation for my bug report, as well as for the original bug report. I do believe that this is a valid issue.

Firstly, since dotted arrows are used to show a dependency from one class to another. In the case of a class implementing an interface, it is valid to use dotted arrows, since it is a dependancy and not an association. In this case however, it is showing two abstract classes extending another abstract class with dotted lines, which is invalid, as it is an extension, which should use a solid line.

Secondly, in my bug report. I referenced 2 separate screenshots. These screenshots show contradictory use of the solid/dotted lines for this issue in multiple instances of separate sections of the DG. Hence, either way, one of the usages has to be wrong. Thus I am unsure why the dev team rejected the issue, marked it as duplicate, and lowered its severity.

and ---------------------------------------------

---

:question: Issue severity

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

• [x] I disagree

Reason for disagreement: I disagree with the dev team on the severity of this issue. The team changed the severity to low. Whereas I originally chose the severity of medium.

I believe this is a medium or even a high severity issue.

Firstly, when looking at this diagram, I initially felt “off” about it. However, I doubted myself whether this issue was actually a problem. I took some time to visit the textbook to check whether this was a valid thing to do, as I had to consider whether it was an association rather than a dependency. This is considering that the initial {abstract} class was being extended by 2 other {abstract} classes.

It took me time to determine this, as I had to look up conventions in the textbook. This is because I found it difficult to find examples in the textbook that showed an abstract class extending another abstract class. Given that it did take me some time to figure it out, it posed an inconvenience to me, and I’m sure it inconvenienced other readers as well. AFTER figuring out that this is indeed an error, I was able to continue to use this product.

Secondly, since dotted arrows are used to show a dependency from one class to another. In the case of a class implementing an interface, it is valid to use dotted arrows, since it is a dependancy and not an association. In this case however, it is showing two abstract classes extending another abstract class with dotted lines. This is invalid, as it is an extension, which should use a solid line.

Thirdly, in my bug report. I referenced 2 separate screenshots. These screenshots show contradictory use of the solid/dotted lines for this issue. Hence, either way, one of the usages has to be wrong. In fact, this contradictory use had further confused me about the usages of the lines.

and ---------------------------------------------

Hence, I believe that this issue is of medium or even a high severity, as it affects/inconveniences/confuses most users.

---