Additional practice questions for part 2 cross check

[kiwibang]

Hi everyone, as per the title, I would like to cross check and discuss answers for the additional practice questions!

Here is my answers (apologies for the messy diagrams, was trying to finish within the 20 minute window):

(a) and (b)

(c)

(d)

[GohTengFong]

Q1(a) How did you know that heading is a package private visibility? Other than this, my diagram is similar to yours Q1(b) Instead of 2 arrows, mine is drawn as composition (similar to 1(a)). I also added 2 more reference (dotted) arrows from each Section object to the Handout object Q1(c) I did not have an [else] condition in my alt box. Other than that, my diagram is similar

[damithc]

@kiwibang thanks for sharing your answers (and @GohTengFong for inputs). I'll leave you all to discuss and figure out the correct answer. If there are still unresolved points after discussion, let me know so that I can pitch in.

[damithc]

On a related note, recommended to follow the given layout for the class diagram. It will help when you match your diagram with diagram choices given in exam part 3.

[jannnice]

I share the same question as @GohTengFong, how do we decide on when to put package private? Is it correct for me to say that any attributes without visibility will be considered as package private? For example: String heading -> ~heading:String public String heading -> +heading:String

Another question is, do we only draw the composition relationship when the question gives the "explicit keywords"?

[damithc]

Another question is, do we only draw the composition relationship when the question gives the "explicit keywords"?

@jannnice If composition is expected, there will be an additional hint to nudge you towards it. So, you can first figure out which associations are likely to be composition, and look for the hint to confirm.

[kiwibang]

Q1(a) How did you know that heading is a package private visibility?

heading does not have any access modifier. In Java, any field without an access modifier is package-private by default as per the official Java documentation.

Here is a screenshot of the relevant portion of the Handout class for easier reference:

Q1(b) Instead of 2 arrows, mine is drawn as composition (similar to 1(a)). I also added 2 more reference (dotted) arrows from each Section object to the Handout object

I think I should have added those for more detail. Thanks for pointing that out!

Q1(c) I did not have an [else] condition in my alt box. Other than that, my diagram is similar

I think omitting the [else] is acceptable in activity diagrams. Page 155 of the textbook does mention this:

[aexolate]

For 1d, will the 'place hand' at the [else] branch be extra?

e.g. Place Hand on Reader -> verification failed -[else]-> Place hand -> Place Hand on Reader -> ...

[TeeRenJing]

I was thinking of an activity diagram like this instead.

[Elijah5399]

For the activity diagram question, I agree with @TeeRenJing 's implementation of the if-else portion. I think it makes more sense to have 3 different cases:

1. Where p1, p2 and p3 are all positive,
2. There are 3 consecutive failures, and
3. Else

However, I also added a box containing "user prompted to place hand again" to the else line. I feel like @kiwibang 's way of representing the if-else statements is inaccurate. According to his diagram, 3 failures causes the user to be prompted to place their hand again, followed by the door being disabled, which doesn't make sense.

In response to @GohTengFong 's comment, I believe including the dotted arrows in the object diagram is incorrect, as the Handout depended on by the Section object may not be the same Handout object which it composes.

With regards to the sequence diagram, within the [alt] block, I believe an empty [else] block is necessary. To my understanding, inside the [alt] block, exactly one scenario has to be chosen.

[richiehx]

@Elijah5399 From the textbook, it is ok for none of the alt blocks to be taken, so I believe an empty else block is not necessary.

[ktzy0305]

Q1(a) How did you know that heading is a package private visibility? Other than this, my diagram is similar to yours Q1(b) Instead of 2 arrows, mine is drawn as composition (similar to 1(a)). I also added 2 more reference (dotted) arrows from each Section object to the Handout object Q1(c) I did not have an [else] condition in my alt box. Other than that, my diagram is similar

@GohTengFong I don't think there is a need to add the 2 reference arrows for the object diagram.

[ktzy0305]

Either way here are my answers

(a)

(b)

(c) There is a mistake where I missed out the final partition [else] in the alt frame. Other than that its mostly the same as @kiwibang.

(d)

[jianrong7]

I realise that the code in part c does not have break statements in the switch-case block. Will this affect the sequence diagram? Because if status == 2, the code will execute f.increase(2), then it will fallthrough to f.increase(3).

[damithc]

I realise that the code in part c does not have break statements in the switch-case block. Will this affect the sequence diagram? Because if status == 2, the code will execute f.increase(2), then it will fallthrough to f.increase(3).

Good catch @aexolate The omission of the break; was unintentional. I've uploaded a new version with break; added.

[A1WAYSD]

@damithc Hi Prof, may I ask

1. In (a) can we show the dependency from Section to Handout even if there's an association between them? Since textbook mentioned "we need not show that as a dependency arrow in the class diagram if the association is already indicated in the diagram", but here the navigability is from Handout to Section so drawing the dash line from Section to Handout does add extra value?
2. Can we show dependency in Object diagram?
3. In (c) where target object of run() is not specified, how can we name the target object?

Thank you!

[kiwibang]

For the activity diagram question, I agree with @TeeRenJing 's implementation of the if-else portion. I think it makes more sense to have 3 different cases:

1. Where p1, p2 and p3 are all positive,
2. There are 3 consecutive failures, and
3. Else

However, I also added a box containing "user prompted to place hand again" to the else line. I feel like @kiwibang 's way of representing the if-else statements is inaccurate. According to his diagram, 3 failures causes the user to be prompted to place their hand again, followed by the door being disabled, which doesn't make sense.

Yep, agreed. Mine seems to be rather convoluted and perhaps wrong.

With regards to the sequence diagram, within the [alt] block, I believe an empty [else] block is necessary. To my understanding, inside the [alt] block, exactly one scenario has to be chosen.

Agreed, I feel that there should be an empty else block to handle the scenarios where status is neither 2 nor 3.

Thanks for the valuable inputs! 👍

[kiwibang]

@ktzy0305 I have some questions regarding some parts of your diagram. Could you help to clarify them? TIA!

(a)

• For the association between Brochure and Handout, should it be 2 arrows instead? I feel that this association is not bi-directional but rather 2 uni-directional associations. Not very sure though
• For the dependency from Section to Handout, do we need to draw this? The notes say that if there is already an association between the two classes, then the dependency arrow is redundant and thus can be omitted. However, the association between the Section to Handout is in a different direction. In such a case, do we have to draw the dependency arrow like your diagram and mine, or can we omit it?

(b)

• Do we need to show the composition relationship in an object diagram? Or can that be omitted?
• Is there a strict rule as to whether we can give names to unamed objects?

(c)

• Is there supposed to be a self-invocation in the activation bar for your pad method? Since the pad method calls the increase method, both of which are methods of the same Factory class

(d)

• Perhaps the corners of each activity can be rounded more? It seems to be a little pointy

Other than that, I see no issues! These are really nicely drawn diagrams that I could never hope to achieve! 👍

[damithc]

• In (a) can we show the dependency from Section to Handout even if there's an association between them? Since textbook mentioned "we need not show that as a dependency arrow in the class diagram if the association is already indicated in the diagram", but here the navigability is from Handout to Section so drawing the dash line from Section to Handout does add extra value?

@A1WAYSD The association is in the other direction. So, it doesn't imply this dependency.

• Can we show dependency in Object diagram?

Dependencies exist between classes, not objects.

• In (c) where target object of run() is not specified, how can we name the target object?

You can give it any name or keep it empty. It will not appear in answer options in part 3 of the exam.

[damithc]

• Do we need to show the composition relationship in an object diagram? Or can that be omitted?

@kiwibang good to show, as it adds value.

• Is there a strict rule as to whether we can give names to unamed objects?

No. You can give names if it adds value e.g., if you need to refer to each object from elsewhere.

[damithc]

@ktzy0305 there's a minor notation error in the below:

[A1WAYSD]

@damithc Thanks Prof for bringing up that dependencies only exist between classes:D

[ktzy0305]

@damithc Thanks prof! Didn't realise I drew an extra set of curly braces.

@ktzy0305 there's a minor notation error in the below:

[ktzy0305]

Thank you prof @damithc for clarifying!!

(a)

• For the association between Brochure and Handout, should it be 2 arrows instead? I feel that this association is not bi-directional but rather 2 uni-directional associations. Not very sure though

I am not very sure of the context of this question. It would seem like having two uni-directional associations would be correct too. If the question mentioned that when a Brochure is referenced by a Handout object, the Brochure object's cover page is not necessarily the same Handout, then it would be definitely 2 uni-directional associations.

(c)

• Is there supposed to be a self-invocation in the activation bar for your pad method? Since the pad method calls the increase method, both of which are methods of the same Factory class

@kiwibang You're right, I am missing a self invocation for increase(5) in the f:Factory object.

[A1WAYSD]

@Elijah5399 From the textbook, it is ok for none of the alt blocks to be taken, so I believe an empty else block is not necessary.

@damithc Hi Prof, just to clarify for alt path in sequence diagram here, is it okay to skip all of the path as mentioned here, or one of the path in alt must be executed? Thank you!

[s-peiran]

I have some general questions

if there are two arrows in the case above, would it matter which arrow i label the multiplicity at?

Would it be optional to write the return value here?

[damithc]

if there are two arrows in the case above, would it matter which arrow i label the multiplicity at?

@s-peiran Yes, it should be given at the line that represents the corresponding association.

Would it be optional to write the return value here?

Optional in the case of constructors (as it is already known the constructor returns the new object).