AY1819 Sem 2 Q1 - How to represent ambiguous descriptions in class diagrams?

[iamjamestan]

In the question below, the second bullet point tells us that ActionFactory creates ActionX and ActionY objects, and adds them to the History object. However, this description is rather vague and does not give us information about whether ActionFactory has a direct association to ActionX, ActionX, or History. In such cases, how do we represent the relationship between these classes? In my answer below, I have assumed that there are no direct associations and have represented them as dependencies (dotted arrows). Would this be acceptable?

Also, I would greatly appreciate any feedback or areas of improvement for my diagram above. Thank you!

[GeNiaaz]

The way I see it, I think there should be a direct association between them. Action factory is directly involved with creating those objects and should have a strong association with them, I would say to the extent of aggregation. But since we're discouraged from using them in our diagrams, my opinion is that a solid one way association is sufficient.

That's opposed to a situation where it uses a piece of data from the Action, then sure I would use the dotted lines too.

[iamjamestan]

Likewise, in AY1718 Q1, it is unclear what "Manages" mean in the first two bullet points. In my answer, I have decided to represent them as associations.

As for the Data Facade class (as mentioned in the third bullet point), I was also unsure as to whether the Data class should be associated to all other classes or only some of them. In my answer, I have design it to have an association to ProjectManager and StaffManager, since access to them would give access to the other classes. In such cases, is the design flexible and totally up to us or is there an ideal solution that we are supposed to follow? Thank you!

[GeNiaaz]

Again in this question, I think yours is correct, bar from the fact that I think it should be an aggregation. But again since we're discouraged from using that notation, I think what you did was correct.

Aa for your decision to limit the facade class to those 2 classes, that seems to make the most sense in this situation to reduce coupling but maintain control over other aspects too.

[CodyChew]

In the question below, the second bullet point tells us that ActionFactory creates ActionX and ActionY objects, and adds them to the History object. However, this description is rather vague and does not give us information about whether ActionFactory has a direct association to ActionX, ActionX, or History. In such cases, how do we represent the relationship between these classes? In my answer below, I have assumed that there are no direct associations and have represented them as dependencies (dotted arrows). Would this be acceptable?

Also, I would greatly appreciate any feedback or areas of improvement for my diagram above. Thank you!

For this question, I think it is correct that ActionFactory has a dependency on ActionY and ActionX since it creates those objects but it doesn't say it keeps those objects. However ActionFactory should have an association to the History object since it adds objects to History, suggesting that there's a reference to it. You can take a look at week 8 topics which covers this solution in one of the videos.

[iamjamestan]

For this question, I think it is correct that ActionFactory has a dependency on ActionY and ActionX since it creates those objects but it doesn't say it keeps those objects. However ActionFactory should have an association to the History object since it adds objects to History, suggesting that there's a reference to it. You can take a look at week 8 topics which covers this solution in one of the videos.

Thanks for the explanation, this makes sense! And also thanks for informing me about the video for the solution :)

[damithc]

In my answer below, I have assumed that there are no direct associations and have represented them as dependencies (dotted arrows). Would this be acceptable?

Yes, this is acceptable as well.