sharpstorm
commented
2 years ago Team's Response
Rationale
The point of this diagram is to show that methods that modify Appointment objects are only present in Schedule and not ReadOnlySchedule. Therefore, the number of methods shown this diagram is already minimal. Moreover, omitting the parameter types is not allowed as it changes the method signature, so there is nothing that can be done about it.
We do agree that it is messy, but there is no way of further simplifying it.
Downgrade to Low
We do not feel that this issue justifies a medium severity as it does not impede understanding. The point of the diagram is still conveyed when read in context with the preceding text.
Duplicate status (if any):
--
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.
The following UML diagram seems to contain too much information (includes a huge amount of methods that the class has), and will be very difficult to maintain. This will also overwhelm the reader with too much information and doesn't really aid understanding.
[original: nus-cs2103-AY2122S2/pe-interim#226] [original labels: severity.Medium type.DocumentationBug]