14/15S2 paper pointtracker class diagram

[nicktohzyu]

Example answer given: My answer:

Design choices which were different: person is abstract facade has direct navigability to teams tutorial slot is an attribute of team, not the other way round (could be bidirectional?) team is a composition of students. I chose this because teams do not change for the semester and the app only tracks the current semester. there are no individual tasks or other reason to track students outside of teams

Would appreciate any feedback on my design choices or explanations to why i'm wrong

Besides this, multiplicity for aspects such as number of teams in a class were not specified by the question, hence for similar cases should I use * as given in the answer or would it be better to leave it unstated?

[damithc]

team is a composition of students. I chose this because teams do not change for the semester and the app only tracks the current semester. there are no individual tasks or other reason to track students outside of teams

Team -- Member is a common example for aggregation, not composition. This is a container-containee relationship, not a whole-part relationship.

Besides this, multiplicity for aspects such as number of teams in a class were not specified by the question, hence for similar cases should I use * as given in the answer or would it be better to leave it unstated?

It is better to leave as unspecified unless the context implies a * multiplicity. For grading purposes, either is fine.

[nicktohzyu]

thanks. I would argue that this would be composition, ie student does not exist outside of team for the purposes of this app, because there are no individual tasks or other reason to track students outside of teams.

would it be ok to have facade have direct navigability to teams, and to have a bidirectional association between tutorial slot and team?

[GeNiaaz]

I would argue that this would be composition, the student does not exist outside of team for the purposes of this app, because there are no individual tasks or other reason to track students outside of teams.

I don't exactly know the context of this app, but if say the student was transferred from one team to another? Or if the team is deleted and the student is added to another team? If composition is applied here, there is no flexibility, the new team to replace would have to copy over all details of the students from scratch and instantiate them instead of reusing them from the old team. It just makes more practical sense to me here to employ aggregation.

would it be ok to have facade have direct navigability to teams, and to have a bidirectional association between tutorial slot and team?

I mean that works but you should limit access to the team. It is something which can be accessed by tut slot and assessment, and to do it your way would increase coupling too much unnecessarily.

Also what benefit would the team having access to tutorial slot serve?

[damithc]

does not need outside is not a sufficient condition for composition. If that is the case, every facade class will result in composition, and very class that contains the main method too. Composition is used to indicate a situation where something that is normally a single entity (i.e., the whole) has been split into parts for the ease of managing the internal design.

Anyway, it's more of a consensus rather than a strict rule. By applying a narrow definition, we ensure it appears only in some very special cases. If you have it all over the place, it becomes less useful and becomes just eye candy.

[nicktohzyu]

thanks!