nus-pe-script
commented
2 weeks ago [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
The class diagrams for the other parts of the architecture (event, command) were represented by component diagrams, rather than class diagrams. This was as the design section described the components (and the classes within) at a high level, regarding their overall purpose and interactions with other components, so showing the components themselves (as in the diagram below), rather than all the details on their members and methods, was sufficient.
Moreover, since the different classes for these components had so many methods (e.g. for the event component, there were methods to get, add, remove and edit events, participants, and items within the event list class), a class diagram for these components would have been too detailed or complicated for the reader to understand easily, while the component diagram was sufficient to show the reader what he needed to know for that section. This is in line with what has been stated in the course, that the diagrams are supposed to be comprehensible, rather than comprehensive, as shown below:
As stated in the list of possible bugs in the course website:
The different methods within each class were also described in the "Implementation" section for each command. For example, the add and remove operations within EventList (that is, the class storing the list of events) were described in the "Add feature" and "Remove feature" sections of the "Implementation" section.
This also extended to some of the class diagrams, like for the Parser (as shown below), in which we omitted several methods (like the helper methods for the parsing of specific commands), and generalised others (with a general parseXYZCommand() method in place of individual methods for each command) to provide sufficient information to the reader to understand the general architecture of the Parser.
The details for the component were then covered in the subsequent "Command parsing" section under "Implementation", which we linked to to aid the reader, as shown below:
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [ ] I disagree
Reason for disagreement: [replace this with your reason]
The DG only provides details on some elements in the class diagrams and excludes diagrams for other areas (eg. event, participants)
These are the only class diagrams and the last one is not comprehensive of the actual classes