Unnecessary aggregation of different functionalities

[winston-lim]

The sequence diagram in 3.1 is large and aggregates several functionalities I would argue that :

• fav list and fav [ID] are two completely different functionalities(viewing vs updating) that should be encapsulated in separate sequence diagrams

[soc-pe-bot]

Team's Response

Thanks for your report!

We acknowledge that the sequence diagram in 3.1 is large. However, code-wise, the FavouriteCommand class handles both the fav [ID] and fav list commands, and hence should be in the same sequence diagram. Splitting them up into separate sequence diagrams will not accurately reflect how the source code handles the user inputs.

Hence we are rejecting this report.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: I disagree that just because they have a common super class, you say that they should be in the same program.

• In this case, they not only have different functionalities i.e. one lists and the other modifies, but also they have different implementations

Separation of concerns and OOP teaches that if two entities have different purposes and functionality they should be separate.

In fact, in tutorials we had this exact discussion and the agreement was that as far as possible, we should avoid having combined sequence diagrams as it reduces clarity unless there is a very good reason to do so

• In this case, I argue that there is no good reason to do so, except perhaps to save time

---