SDM 2023: Lab Assessment Part C notes

Lots of people omitted parts 1 and 2 of this question and jumped in at part 3. For part 1 the first step was to know what an object diagram is! It's an instance diagram for a class diagram - in this case, you needed to have a collection of instances of the metaclasses in the given metamodel. Instances in UML use the same shapes as the corresponding classifiers, but they are labelled differently: using instanceName : ClassifierName, the whole thing being underlined.

Your collection need to conform to the metamodel, e.g., obeying the multiplicities given, and it needed to represent the given sequence diagram. The first part is mechanical; e.g., your instance of Message had to be linked to two instances of Object by source and target, and to one instance of Operation by is invocation of. (You didn't necessarily need to name the links, but they had to be there.) Representing the given sequence diagram is where it gets a little interesting. E.g. you see two arrows representing communications in the sequence diagram, one message call and one reply, but since according to the metamodel any Message must be an invocation of an Operation, what must be going on is that those two graphical elements are represented by the same semantic element, Message, in the metamodel. This is an interesting example of how there doesn't necessarily need to be a 1-1 correspondence between visually identifiable elements in the diagram and notional elements having semantics in the metamodel. In UML, of course, Lifeline is another example...
This part would have been easier if I had given you rolenames in the metamodel rather than association names - indeed I did at some point intend to change the diagram so that I did, but forgot. So this part was a little harder than I really intended; the ideal answer would have commented on the fact that my "source" and "target" are nouns, hence clearly intended to be rolenames not association names, but misplaced; it would then have gone on to use them as rolenames. I don't think I saw any ideal answer. Some were close though. Notionally what you're doing here is saying that the metamodel diagram must commute in the appropriate sense. With some comment about the need to interpret "target" as a role name, you might have written: context Message inv: self.target.class.operation->includes(self.operation) for full marks. In other words, the class of the object that is the target of this message must have a set of operations that includes the operation of which this message is an invocation.
Lifeline - nothing else was acceptable.
Fig. 17.6. You got partial credit for Fig. 17.18, because that is an abstract syntax diagram that mentions Lifeline, but it's really not the relevant one to understanding what a Lifeline is. You did not get anything for Fig. 17.25 because that's not an abstract syntax diagram.
There were very few attempts at this and they were rather general, amounting to that UML is much more complicated than the simple fragment shown here. In an ideal world, you'd have connected this to the earlier parts and understood what Lifeline is about - it's trying to find a way of modelling part of the behaviour of an object in a particular role, which turns out to be more subtle than at first appears. We may ask ourselves, if the head of the lifeline is an object, which object, e.g., with exactly what attribute values, and what happens if we pick wrong so that it wouldn't behave exactly as in the sequence diagram? But if it's a class, then what's special about this particular scenario? Still, it was good to be able to give any marks at all in this part - well done those who attempted it.