Q1:

Mostly straightforward, nothing much to say. Except...

(b) gave some people trouble. I wanted you to identify that the only clause in LoD that could apply here was the one about the message recipient being directly accessible from the sender, i.e. the value of an attribute, and deduce that classes Bill and Item must be associated (bidirectionally in fact) and that a and i must be objects linked by that association.

(f) note that the question isn't what these things are, but what their role is in MDE. I marked this pretty generously, but if your sentence convined me you knew what the thing was but didn't convince me you knew anything about how it might be used, you only got 1 of the 2 marks. This was common for DSML where for 2 marks you had to e.g. say that it helps with expressing decisions naturally in a particular domain, or that it allows stakeholders in MDE to work in a language that met their needs, not just expand the acronym.

Q2:

Not many people chose this question (three times as many picked Q3) and, with some honourable exceptions, most of those who did this one didn't do very well - perhaps Q3 was a lot more attractive and most people who felt they could have tackled either gravitated to Q3?

(a) Use case, Class (or Interface was also fine), Dependency

(b) Although I'd rather laboured related issues in the Q&A/discussion sessions, this part was not well done. The key point here is the difference between "id = "Something"" which is setting the value of an attribute id from the meta-level above this class to Something, and "id : Something" which is specifying that id is an ownedAttribute of this class, of type Something. So in (i), any class named Master Cylinder Efficacy with any attribute (and correct UML syntax of course) got the marks; it was sensible to name the attribute "id" but you didn't have to. (Many people named their attribute ownedAttribute, which was technically possible and got the marks if the rest of your syntax was correct, but suggested confusion about what was going on.) In (ii) you got a mark if you pointed out the contrast between "=" in the diagram in the question and ":" in your diagram from (i). Subsequent marks were given generously for any correct explanation, such as that it's a question of meta-level: in the SysML diagram id and text are metaattributes of some metaclass in the SysML metamodel, of which Master System Efficacy is an instance. That might be Requirement or AbstractRequirement, we can't tell.

The digital twin part of the question was better done. In particular it was good to see that most people who attempted the challenging c(iii) had sensible things to say. Note that 100 words is really not much! Writing a lot more than that did not get more marks.

Q3:

(a) was bookwork. For (b), most people correctly explained that as pop() both changes the state and returns a value it violates CQS. "Comment on your answer" required you to say something else, such as that the stack interface is well-known and changing it would be confusing, or that the point of CQS is not to have unexpected state changes and everyone expects pop to change the state so there's no serious problem here, or that you could if you wanted rewrite the interface to separate the returning of the top of the stack from the deletion of the top element of the stack.

(c) various solutions were possible. I was surprised how many people wrote things like elements -> size() -> notEmpty() though - a number can't be non-empty!

(d) lots of high scores here - but also quite a lot of long, repetitious answers and even some word salad (this was a good example of something discussed in the revision Q&A/discussion session - longer answers don't always get more marks!). A common problem was making points that didn't address using DbC and CQS together but were just advantages of one or the other - there were no marks for such things (and note you'd already had marks for advantages of DbC in q1(d), so it would be exam-savvy to deduce that there probably wouldn't be more marks for the same points here). Some points that did get marks were: CQS makes DbC easier to follow, because method contracts tend to be simpler when a method is either a command, or a query, but not both [I had hoped that giving you the difficult task of writing a contract for something that was both, in (c), would prime you to say this!]; following CQS tends to ensure there will be a sensible set of queries in a class's interface, and these can then be used freely in other contracts, making DbC easier; DbC makes CQS easier to follow, because the contracts document what a method must do and in particular can specify that it doesn't change the object's data. It was also possible to get some marks by saying things about how they were both pulling in the same direction, towards clear correct maintainable code - but it was hard to make several distinct points, if you didn't write about how DbC and CQS support one another. Some people thought of CQS as all methods being setters or getters, and hence said it ensured that all methods were very simple - for the usual notion of "setter", that's wrong. The computation has to go somewhere! The commands and queries in CQS can get arbitrarily complex; CQS is just about their overall types.

(e) was generally very well done. 100 words is not many though, there was (for most people's handwriting) no need to fill the page! One point is that the meaning of "contract" in DbyC and in Agile's "contract negotiation" is really not the same, so naively using this to say DbyC didn't go with agile wasn't quite right. (Agile is talking about legal contracts between customers and software developers, not technical contracts between software elements, and these are really different things.) There was a mark specifically for answering the question ("good, ugly or something else?") - you got it regardless of your answer (even a fence-sitting answer!), provided your answer was reasonably well supported by what you'd said. Most people didn't think much of the combination - generally speaking more highly of the likelihood of CQS fitting in than of DbyC doing so - and I tend to agree, but all the same marks were available if you wanted to argue for it.