It was common to answer just this question, not question 2. As discussed in q&a/discussion, the choice between reuse by inheritance and reuse by composition is a classic issue in OO design. Composition is usually preferable, because inheritance gives tighter coupling between the classes. For example, where WasherDryer inherits from Washer, clients of WasherDryer will automatically be able to invoke all methods of Washer, even if some are irrelevant to WasherDryer. On the other hand if WasherDryer contains a Washer, it is possible to control which methods are made available (e.g. via one line wrapper methods containing lines like return myWasher.someMethod()). I gave marks for arguing either way, though, provided that you made a sensible argument. (E.g., you might say that in this particular case it is implausible that there is anything in the interface to Washer or to Dryer that you do not wish clients to have access to.) This being part C, though, I marked hard, and you needed to be clear and precise to get marks. Well done those who did!
Many people correctly found p202 (someone did find an earlier page in which the notation was being explained to the reader of the UML standard, rather than as part of UML, and that was ok too!)
This was getting hard because even once you found the right part of the specification it wasn't that easy to understand. For full marks you needed to have both a quotation and an explanation in your own words that applied the standard to the given example. A common issue was confusing owning the association end (e.g., having control over a reference represented by it) and owning the class at that association end (e.g. being in charge of creation/deletion of its objects) - these are not the same and we're talking about the former here. Well done to anyone who got any marks.
public class Node {
}
public class Edge {
Node source;
Node target;
}
- for full marks, you also had to explain what was forced, in this case the
presence of attributes source and target in Edge.
Lots of scope for different sensible things to say here. You needed to start by saying that you'd expect to see navigability arrows in place of the blobs. As Bran Selic's note Getting it Right on the Dot explains, the difference between navigability and association end ownership is pretty subtle where what you're modelling is something like a Java system, which is at least what most people are doing when they first learn UML; so few people who were used to using the earlier navigability notation will have found a strong motivation to change practice. Moreover the navigability was well established in tools, books and training material before the split between it and association end ownership was introduced. I think inertia is the rest of the explanation - this just never seemed important enough, to most people, to make the switch into beginning to use blobs. I have to confess that I never updated my book Using UML to explain them, and haven't had reason to regret that.