Additional practice questions for part 2 (part (a) and (b))

[dominopizzaaaa]

Hi! This is my diagram for Additional practice questions for part 2 (part (a) and (b)):

Is there anything incorrect, or do any parts need changes or improvements?

[zaidansani]

I think you're missing out the underline for the class-level method capacity in Section.

I also believe the access modifiers in Handout are wrong? isFull should be # (protected), and I think by default since there's no declared modifier heading is ~ (package-private)

For the Handout to Brochure and Sections, I think the aggregation symbol can be used? Since it's a list of Brochure and Sections.

[dominopizzaaaa]

Thanks a lot! I changed it to this! Do you know how to show the private list of sections? or do we not need to show that?

[emmannyyy]

Not entirely sure but I had some variations

For the class diagram

• I think that the line from Countable to Readable should be a solid line, since it is an interface extending another interface, not implementing it.
• Also, composition should be a filled diamond. Hollow diamonds are for aggregation
• The method for +capacity(Handout) should also be underlined because it is a class level (static) member.
• the closest and cover should be association roles, not association labels.
• I don't think there any composition from handout to brochure

For the object diagram

• you could also show composition on the object diagram

Here was my attempt:

[dominopizzaaaa]

i think your references by arrow is the wrong direction? in the questions it says:

A Handout can be referenced by the text in any number of Brochures.

the arrow should be the other way?

@emmannyyy

[damithc]

Here was my attempt:

@emmannyyy Mostly correct.

Navigability between Handout and Section missing A dependency between Handout and Section missing (this is a tough one to spot though)

[damithc]

i think your references by arrow is the wrong direction? in the questions it says:

A Handout can be referenced by the text in any number of Brochures.

the arrow should be the other way?

@dominopizzaaaa That doesn't necessarily mean Brochure is tracking the relationship. As per the code, it is the Handout that is keeping track of this relationship.

[emmannyyy]

Thanks for the input Prof @damithc

I now spot the missing navigability from the handout to the section class.

May I clarify what you meant about the dependency? I thought that we only illustrate dependencies for classes that do not have direct associations. My thought process was that since there was already composition, it implies a direct association, and hence there should not be another dependency line drawn from Handout to Section.

[cth06-Github]

@emmannyyy If I may input: You are right that we only illustrate dependencies for classes that do not have direct associations. However, for the class diagram required of that question, the direct association is from Handout class to Section class, and not from Section class to Handout class. Without the dependency drawn in the class diagram, we will not know that Section class depends on Handout class.

Let's say if the Section class contains the class-level method as public static void capacity() (don't have the parameter required), then Section class does not depend on Handout class because Handout did not appear anywhere in the code for Section class.

As the Section class contains the class-level method as public static void capacity(Handout h) where the parameter h must belong to Handout class, it means that Section class depends on Handout class, i.e. a relationship from Section to Handout. As stated earlier, there is no association from Section to Handout, thus dependency needs to be included.

[emmannyyy]

Legend... Thanks for the help!! I get it now @cth06-Github 💯

[ZweZeya]

Can we use a bidirectional arrow between Brochure and Handout?

[LemonDrew]

I think we can add since each Brochure has only 1 Handout and it seems that both are referring to each other (eg the same entity). But I wouldn't add it unless they stated it clearly that the references are to the same entities