Open lestersimjj opened 2 years ago
Duplicate. Software limitation. Severity should be VeryLow as this should not affect reader's understanding of the flow.
[The team marked this bug as a duplicate of the following bug]
Some activation bars are too long
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.
I think the activation bars should only begin when the method call arrives.
[original: nus-cs2113-AY2122S2/pe-interim#604] [original labels: severity.Medium type.DocumentationBug]
[This is the team's response to the above 'original' bug]
The activation bar was high up because I was unable to move the rectangle down due to software limitation, but was trying to reflect that the UpdateCommand object only gets created at that point in the sequence diagram. This is a unavoidable cosmetic flaw given the software limitations, and it should not cause problems to reader in understanding the flow, so severity should be VeryLow.
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
Reason for disagreement: [replace this with your explanation]
Team chose [severity.VeryLow
]
Originally [severity.High
]
Reason for disagreement: I disagree that this is due to software limitations. Reading the team's Github, they use Visual Paradigm tool to create sequence diagrams. However, on the Visual Paradigm website docs, they mentioned the ability for constructors (Create messages) and the ability to activate/de-active elements to represent the period during which an element is performing an operation. The URL and sample images from Visual Paradigm below:
https://online.visual-paradigm.com/diagrams/tutorials/sequence-diagram-tutorial/
The team can revert to the proposed UML tool by the module textbook (eg. PlantUML) if the team felt that a software limitation was causing their diagrams to be inaccurate,
A developer reading the DG might think that the UpdateCommand was already instantiated beforehand and be confused when it is the Parser that instantiates an UpdateCommand.
Describe the bug
When the parser calls the constructor for UpdateCommand (arrow 1.3), then only UpdateCommand should be active (an a constructor bar shown). However in the DG, the UpdateCommand was already active from the beginning.
Screenshots