soc-se-bot
commented
7 months ago Team's Response
The reason why we treated UI and Parser the same can be found in #1145.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Wrong explanation for UI component (DG)
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.
This paragraph seems to be describing the "Parser" component instead? Perhaps there was a mix-up or confusion in terms of what "UI" and "Parser" components were when writing this part of the DG.
[original: nus-cs2113-AY2324S2/pe-interim#1030] [original labels: type.DocumentationBug severity.High]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
There is no mistake on our part as we intentionally treated the Parser as part of our user interface (UI) component. The definition of UI should be a point of contact between computers and humans. Within the context of a CLI-based application, there isn't a traditional "UI". Since the Parser directly accepts user input from the terminal and translates it into appropriate commands for the other sub-systems to carry out, it could be considered as a component of UI.
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)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue response Team chose [`response.Rejected`] - [x] I disagree **Reason for disagreement:** I respectfully disagree with this approach and believe it can lead to confusion and misunderstandings for developers working with your system. While it is true that the Parser acts as a point of contact between the user and the application, it is more accurate to consider it as a separate component that bridges the gap between the user interface and the underlying system logic. The Parser's primary responsibility is to interpret and transform user input into a format that can be processed by the application's core logic. This is a distinct concern from the UI's role, which focuses on presenting information to the user and accepting their input. Mixing these responsibilities can make the system harder to understand, maintain, and extend. Furthermore, treating the Parser as a separate component helps to clearly define the boundaries and interactions between different parts of the system. It allows developers to reason about the flow of data and the responsibilities of each component more easily. Lumping the Parser together with the UI can obscure these boundaries and make the architecture less clear.
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I believe this should be at least a low based on the reasons provided.
"UI" component is not shown in the architecture diagram at all, even though it is explained as one of the components. Reader might not be able to make sense of how the "UI" component interacts with the other main components of the app.