Q1:

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

• In 1(d) there were lots of possible answers. Most likely advantages were: standardisation prevented tool lock-in, enabled labour mobility. Most likely disadvantages: bloated/complex, imprecise semantics. I have a note that I only gave 1 mark for disadvantages if both were different ways of saying "big".
• In 1(f) MODA is from the paper A Hitchhiker's Guide to Model-Driven Engineering for Data-Centric Systems by Benoit Combemale et al, which was required reading that year (but optional in 2023/24)

Q2:

(a)-(c) were straightforward if you knew your patterns (if not, this was a bad choice of question!)

For (d) the expected principles were Single Responsibility Principle (Decorator allows functionality to be divided between classes with unique areas of concern) and Open-Closed Principle (Decorator allows the functionality of a class to be extended without being modified). Note "briefly" - you didn't need to write more than that as explanation. By the way, when you are asked for a certain number of things, e.g. 2 here, it's lovely if you number them, bullet point them, or otherwise make them distinct - it saves the tired marker working out where one ends and the other begins, and makes it a tiny bit faster and easier for the marker to give you full marks and move on which is what you both want!

Sensible points to make included that multiple inheritance may sometimes be useful e.g. as it enables typechecking, but the dynamic nature of Decorator lets it do things multiple inheritance can’t, e.g. add responsibilities at runtime. Your example needed to support your points about the advantages of Decorator (but most would!)

Q3:

(a) Both grammars and metamodels are used to express the syntax of a domain-specific language. A grammar is used to define a textual language and includes the concrete syntax, while a metamodel can also be used to express a graphical syntax, but only the abstract syntax not the concrete syntax.

(b) various solutions were possible - you'd typically have metaclasses for Person, Grant, Interest and attributes for Name, Job title, with sensible associations. There's an issue about how best to model Institution - you could do it either as metaclass or as attribute, and a sensible comment about needing to know more about how much we have to know about Institution was a good way to get the marks for what more we needed to know.

(c) The metamodel won't need to change - that's the point of it expressing abstract, not concrete, syntax.

(d) This was very open-ended and marks could be got in various ways. E.g.: she could use model-to-text tools e.g. EGL to generate other/partial representations of the data, e.g., list people by research interests; use a model query language to check for people with no grants, or only grants that are coming to an end, or for people with interests in a particular area; use a model-to-model transformation (e.g. in ETL) to generate a graphical representation of interests of staff members and the associated grants.

(e) There are fundamentally two options: redesign this DSL to exclude the information about grants and PIs so that the two languages are orthogonal; or keep the DSL as-is, and think about the consistency that needs to be maintained between the two information sources. The latter was an invitation to mention the idea of using a bidirectional transformation to maintain consistency - you could also get marks for pointing out the difficulties of that approach e.g. lack of mature usable tools and languages for bidirectional transformations.