nus-se-bot
commented
1 year ago Team's Response
Thank you for the suggestion. In this case, I respectfully disagree that a color coded class diagram is necessary.
The intention of this class diagram is actually to focus on the relationships between specific classes relevant to the gamification feature's implementation, not the packaging of these classes. Color coding the packages would actually shift the focus away from the relationships and to the individual packages/classes themselves, which are already explained in other sections of the DeveloperGuide. As such, we elect not to support color coding of the class diagram.
Nonetheless, we appreciate your advice.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: On the contrary, I believe that color coding is an improvement to what you have currently.
The intention of this class diagram is actually to focus on the relationships between specific classes relevant to the gamification feature's implementation, not the packaging of these classes.
If you want to emphasize on the relationships between classes that are relevant to the implementation of the gamification, it is more beneficial for the developer to understand where these classes come from. To elaborate on my point, from just this class diagram, one would think that all these classes are in the same package gamification. However in reality GamificationTokenizer is from another package instead. A picture speaks a thousand words. This could lead to some inconvenience where the developer taking up your application might make false assumptions regarding the location of various classes. This lead me to my next point.
Color coding the packages would actually shift the focus away from the relationships and to the individual packages/classes themselves, which are already explained in other sections of the DeveloperGuide.
I respectfully disagree with this statement. In fact I strongly believe that color coding does not shift the focus away but instead emphasize the relationship between classes and it becomes clearer to them how different classes from different packages work together in your implementation.
One example is the DG of AB3. They started off giving a high level overview of their architecture using different colors to show different components of the application.
They then followed up by showing how each component works. Related classes are colored in the same color.
The different colors present makes it easier for developers to identify which components handles which aspect of the implementation of certain features allowing them to understand the UML diagrams easier.
Therefore I believe my suggestion is valid and since this is a purely cosmetic issue, the severity chosen is correct.
To make your UML diagrams clearer, i suggest using color coded class diagrams so indicate objects from the same package etc.