nus-pe-bot
commented
2 months ago Team's Response
The purpose of the UML diagram above is to assist the reader in understanding the Model component of FitBook. While we agree it would be ideal to have all the attributes of a Person in the diagram, we think that the omission of a few Person attributes would not hinder the reader from the intended purpose of the diagram, which is to show the inner workings of the Model component.
Definition of a High severity bug: A flaw that affects most users and causes major problems for users.i.e., makes the product almost unusable for most users.
Our team believes that this bug would be a High severity documentation bug only if it would result in the reader to be completely misinformed about the Model component, causing the diagram to be almost unusable for most readers. (e.g. by having completely incorrect multiplicity labels)
We think a fairer severity of this bug would be Low as the Height and Weight attributes are mentioned and explained in their relevant areas. In this specific diagram, we think the omission of those attributes would only be a minor inconvenience to the reader.
A possible improvement would be to add a note clearly explaining the omission of such nitty-gritty details. (e.g. Not all attributes of a Person are shown)
As such, we have accepted the bug but reduced the severity from High --> Low.
Items for the Tester to Verify
:question: Issue severity
Team chose [severity.Low]
Originally [severity.High]
- [x] I disagree
Reason for disagreement: "Omission of a few Person attributes would not hinder the reader from the intended purpose of the diagram, which is to show the inner workings of the Model component."
I agree with this statement, however, height and weight are key components within FitBook, with one of the key promised functionality of FitBook being that of the tracking of these parameters. It can also be argued that neglecting such key classes would cause major problems for developers using the guide.
"A possible improvement would be to add a note clearly explaining the omission of such nitty-gritty details. (e.g. Not all attributes of a Person are shown)"
I strongly disagree with this statement. I do not believe that integral classes that represent one of your key promised functionality are "nitty-gritty details" and I believe we should not dismiss it as such.
"Our team believes that this bug would be a High severity documentation bug only if it would result in the reader to be completely misinformed about the Model component, causing the diagram to be almost unusable for most readers."
I believe in the context of the DG, especially given that it is being used by individuals with the perspective of a developer, the lack of recording of such key components should be something of a high severity, given that as a developer his purpose of use would be to understand the structure of the project. With reference to page 57 of the textbook,
"The software architecture shows the overall organization of the system and can be viewed as a very high-level design. It usually consists of a set of interacting components that fit together to achieve the required functionality. "
I understand considering all classes might be unnecessary and unfeasible at times, but I would still like to drive the argument that these are core classes to your final application. This is also mirrored within your UG, where you explicitly mentioned that main components are in consideration within the diagram, with the section starting with
"Given below is a quick overview of main components and how they interact with each other."
Additionally I have checked through the DG again, there are mentioned of the ability of Height & Weight to be tracked by the application, as well as how it interacts with the user, but this is in the MSS (which should leave out implementation details). The DG does not show where height and weight is involved within the application structure. With this in mind it could even be argued that the rest of the DG is confusing, from the perspective of the developer, I now know that this app can do something with height or weight, but I do not have the slightest clue where it's doing it, given that all classes related to this functionality is left unrecorded in the architecture diagrams.
This goes against the core purpose of a DG as given by textbook page 87 (2).
The person model in your repo seems to have some other associated attributes/classes such as Height, Weight. This is not properly reflected in the UML diagram. Given below.
Will be elevating this to high since it seems to be quite a large oversight.