NayChi-7 / pe

0 stars 0 forks source link

Too much info on class diagram #9

Open NayChi-7 opened 1 year ago

NayChi-7 commented 1 year ago

Screenshot 2022-11-11 at 5.35.51 PM.png

The class diagram is very detailed (readability might be compromised). As such certain auxiliary methods such as "checkForEmptyAddPropertyDetails" can be omitted.

nus-se-bot commented 1 year ago

Team's Response

The intention of including all the methods within CommandAddPropertyParser and CommandAddClientParser class diagrams is to allow the reader to appreciate the flow of code via the method names as lengthy explanations are excluded. Furthermore, auxiliary methods such as checkForEmptyAddPropertyDetails() are included in class diagram to serve as context for subsequent explanation as shown below.

image.png

Also, when viewing class diagram at 100% (actual size) in adobe acrobat pro dc as shown below (consider reading DG at actual size), the diagram, although slightly small, is still sufficiently large enough for reading. Since its readability is preserved, this bug shall be rejected.

image.png

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: Even though the class diagram is still large enough for reading as the team argues, I believe my argument of "readability is compromised" still stands. This is because "readability" means "the ease with which a reader can understand a written text" and in this scenario, it is the extent to which a reader can understand the diagram. I believe the purpose of the diagrams in documentation is for the user to be able to understand the flow of certain components (and/or overview) by "taking a glance" at them. However, in this scenario, due to the overloading of the information in this diagram, the diagram is very "crowded" and the reader would not be able to understand it simply by taking a look at it. Instead, they would need to read through all the commands and doing the differentiation of "main" and "sub" commands themselves.

As such, if the team would like to document the "flow of the code", maybe a brief explanation about the subcommands could be provided outside of the diagram so that readers who would appreciate more details would be able to read them.