Open nus-pe-bot opened 3 years ago
We do acknowledge that literal concurrency in the form of Java Threading was not used.
Our justification is for reject: based on our implementation, all creation of these specified objects are independent from one another and will not fail (which would cause in interruption affecting sequential creates thanks to input checking). Moreover, a number of them are optional and will not be invoked thus not requiring a direct activity arrow to some of them. And can be honestly threaded due to how independent the creation are less the complicated object i.e. Contact, Template which follows the "all parallel paths should be complete before the execution can start on the outgoing control flow of the join." definition of https://nus-cs2103-ay2122s1.github.io/website/se-book-adapted/chapters/uml.html#parallel-paths-2.
For reducing severity: The order of which object is created is not important for these smaller objects (as they are independent). Thus, even if it they were in the conventional linear activity flow, the logic of the command is unaffected and could be misleading that they are reliant of a previous object when they are in fact not. But we do acknowledge that for a 'simpler' representation of the activity, a linear flow would be more beginner friendly.
--
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.
From this UML diagram it seems like you are doing the creation of Email, Phone etc. in parallel, but I think you are not using Threads or anything of that sort right?
Pardon me if I am wrong. If you are using threads and stuff, then you guys are strong programmers, hats off to you, and please just reject this bug if that is the case. Sorry
[original: nus-cs2103-AY2122S1/pe-interim#368] [original labels: severity.Medium type.DocumentationBug]