1c) Most people correctly said Composite and Decorator which is what I expected; Visitor was also a fine answer. Quite a few people said Abstract Factory, which is wrong; I'm not sure why it was a popular answer, unless just because one of the patterns most prominent in the course, and hence a name that came to mind.
1e) I expected a diagram with superstates On and Off, with On having substates Red and Green, or similar, and appropriate use of a history state. Other answers were possible - e.g. some people gave an unnested solution, which was also fine if it was fully correct (quite a few people did get full marks for such a solution, but there were noticeably more submissions with basic errors like wrong shapes or wrong notation for start markers among this group than among submissions that used nested states and history states).
Part (c) could be answered at a basic level by taking CQS and fluent interfaces literally, and discussing the strengths of each. One of the best points to make is that, while adhering or not to CQS is a yes/no question, so you can definitely decide to adhere to CQS if you wish and check mechanically that you have done so, there is no purely technical definition of what it is to be a fluent interface; writing an interface whose users will perceive it as fluent requires considerable skill. The best answers also considered the rationale behind CQS and argued that it is possible for an API to obey the spirit of CQS, if not the letter, and still return an object in a way useful to method chaining in the spirit of fluent interfaces.
Part (d) was deliberately challenging and open-ended; nevertheless there were some excellent answers. The key basic point is that Tell don't Ask is encouraging design that encapsulates data within an object (in terms of CQS, not using too many Qs). Many people successully related it to the SOLID principles, especially SRP; relating to LSP was also plausible though fewer people did that. Fewer people related it to the Law of Demeter, or to pattern use.
In (a) it was important to answer with relation to defining a DSML - some people wrote only about writing constraints in UML models.
(b) A matter of knowing the OCL constructs and then keeping your head straight. Many people drew class diagram fragments to help explain what context they were assuming: though not required, this was sensible, and often went with good answers. E.g. (ii) means "There is at least one object, linked to self by rolename w, that has at least one object linked to it by rolename p".
(c) An opportunity to demonstrate that you understood this part of the course material and could apply it. For the list of things you would like to find out, it was fine to use technical things (e.g. what properties does the language ensure will hold of every bx written in it, e.g. does it guarantee correctness and hippocraticness?) non-technical things (who's supporting this language, is its software open source, is there decent documentation?) or a mixture.