COM00111M Model-Driven Engineering (MODE) 2022–23
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit
COM00111M
MSc, MEng and MMath Degree Examinations 2022–23
DEPARTMENT OF COMPUTER SCIENCE
Model-Driven Engineering (MODE)
Open Individual Assessment
1 The Exercise
You are to develop and document a domain-specific language (DSL) and supporting tools for designing and implementing questionnaires, such as the one in Figure 1.
Each questionnaire can consist of multiple questions, grouped into sections. Three types of questions must be supported:
• Yes/no questions (like Q1 and Q4 in the example of Figure1).
• Multiple-choice questions (like Q2 and Q6).
• Free-text questions where users can type in their answer (like Q3 and Q5).
Questions can be mandatory (like Q1, Q4 and Q5, which are marked with a red star) or optional. Two types of multiple-choice questions must be supported: one where users can select only up to one option (like Q2) and one where users can potentially select more than one option (like
Q6).
The DSL must also support conditional visibility of questions and sections. That is, questions (or entire sections) can be shown/hidden, depending on the answer of the user to another question. For example:
• Unless the user selects “Yes” in Q1, all other questions in the questionnaire must be hidden.
• Unless the user selects “Yes” in Q4, Section 2 and both of its questions must be hidden.
• Q3 must only become visible when the user selects “Other” in Q2.
For a questionnaire model to be valid, the following properties must hold:
• Questions start with an uppercase letter.
• A section must not contain more than 5 questions.
• Options in multiple-choice questions must not be substrings of other options in the same question (e.g. there cannot be both “Games” and “Toys and Games” options in Q6 as the
former is a substring of the latter).
• The visibility of a mandatory question cannot be conditional upon the answer of the user to an optional question. For example, the visibility of the (mandatory) Q4 question cannot depend on the response of the user to the (optional) Q2 question.
• Circular dependencies between questions/sections must not be allowed. For example, if the visibility of QA is conditional upon the user’s answer to QB , the visibility of QB cannot be (directly or indirectly) conditional upon the user’s answer to QA .
2 Questions
Answer all questions. Note the page limits for each question. Parts of answers that go beyond the page limit will not be marked. References must be listed at the end of the document and do not count towards page limits.
Use Emfatic/Ecore to define a metamodel for the domain-specific language described in Section 1. Include a class diagram of the metamodel in your report, discuss the metamodel, state any assumptions you have made, and explain any alternative design decisions that you have
considered and discounted. [15 marks] (max 2 pages)
Use any of the technologies presented during the module’s lectures and practicals
(GMF/Eugenia, Sirius, Xtext or Picto) to define and implement a concrete (graphical or textual) syntax for the metamodel you defined in Question 2.1. Design the model of the questionnaire of Figure 1 using the concrete syntax of your language, provide a screenshot of the model in your editor/viewer, discuss and justify your syntax design and editor/viewer implementation decisions, andreflect on the strengths and weaknesses of the selected concrete syntax compared to
alternatives. [15 marks] (max 3 pages)
2.3 Model Validation
Use the Epsilon Validation Language to implement any validation constraints specified in Section
1, which cannot be expressed in the metamodel itself. Briefly explain the rationale and implementation of each constraint. [15 marks] (max 1 page)
2.4 Model-to-Text Transformation
Use the Epsilon Generation Language to implement a model-to-text transformation that
consumes a model that conforms to your DSL, and generates an implementation of the
respective questionnaire (including the conditional visibility behaviour described above) in the form of either a web page (using HTML, CSS, and JavaScript) or a desktop GUI application (using Java 11). The implementation of the questionnaire must include a “Check” button that
checks that all visible mandatory questions have been answered and displays an error message otherwise. The model-to-text transformation must automatically generate all the code of the questionnaire implementation. Discuss the model-to-text transformation, and justify the organisation of the generated code. [25 marks] (max 3 pages)
2.5 Application Implementation
Generate an implementation of the questionnaire from the model you developed in Question 2.2, using the model-to-text transformation you developed in Question 2.4. Extend the generated
implementation of the questionnaire’s “Check” button with hand-crafted code that also checks that the value entered in Q5 is an integer and displays an error message otherwise, as shown in Figure 2. Re-running the model-to-text transformation must not delete/overwrite your
hand-crafted validation code for Q5. Present the hand-crafted code that implements this
additional validation behaviour and discuss your implementation choices and any alternatives considered [15 marks] (max 2 pages).
2.6 Model-to-Model Transformation
Using the Epsilon Transformation Language, implement a model-to-model transformation that transforms a questionnaire model into a graph model that conforms to the metamodel of Listing 1 and captures visibility dependencies between questions. The generated model must contain:
• One node for each question in the model. The label of the node must be equal to the ordinal number of the question prefixed by “Q” .
• One edge for each conditionally-visible question in the model. The label of the edge must be equal to the text of the option that the user should select for the question to become
visible.
class Graph {
val Node [ * ] nodes ;
val Edge [ * ] edges ;
}
class Node {
at t r String la be l ;
ref Edge [ * ] # source outgoing ;
ref Edge [ * ] # ta rget incoming ;
}
class Edge {
at t r String la be l ;
ref Node# outgoing source ;
ref Node# incoming ta rget ;
}
Listing 1: Metamodel of the target model of the model-to-model transformation
Figure 3 illustrates the graph model that your transformation should produce from the model of the questionnaire in Figure 1. In the expected graph model:
• Nodes Q2 and Q4 depend on Q1 because questions Q2 and Q4 are only visible when the user selects “Yes” in question Q1.
• Node Q3 depends on Q2 because question Q3 is only visible when the user selects “Other” in question Q2.
• Nodes Q5 and Q6 depend on Q4 because the entire Section 2 of the questionnaire is only visible when the user selects “Yes” in question Q2.
Note: Figure3 is only provided to help explain the expected functionality of the model-to-model transformation. You are not required to produce a graphical representation of the target graph model for this assessment.
Discuss the model-to-model transformation, your implementation choices and any alternatives considered. [15 marks] (max 2 pages)
You must submit a single zip file containing your report in PDF and your implementation files. You must not identify yourself. For example, you must not name files with your IT services (or any other) username!
When expanded, your zip file should contain folders and files matching the structure and naming conventions described below. You must replace “Y1234” with your own examination candidate number:
• Y1234.pdf (your report)
• metamodel (a directory containing your metamodel files and any
Eugenia/GMF/Sirius-related files, if you choose to use GMF/Eugenia or Sirius for your graphical editor)
– Y1234.emf (your metamodel, in Emfatic)
* The name and namespace URI of the root package of your metamodel should also be Y1234.
– Y1234.evl (your EVL validation constraints)
• picto (optional, a directory containing your visualisation model-to-text transformation, if you choose to use Picto)
• m2t (a directory containing your model-to-text transformation)
– Y1234.egl or Y1234.egx (the entry point for your model-to-text transformation)
– *.egl (any other templates for your model-to-text transformation)
• m2m (a directory containing your model-to-model transformation)
– Y1234.etl (your model-to-model transformation)
• models (a directory containing your models)
– acme.model or acme.Y1234 or acme.flexmi (your model of the ACME questionnaire)
– any other models you may have developed to test your editor, viewer, constraints or transformations
• configs (a directory containing stored launch configurations for your model validation constraints, and your model-to-text and model-to model transformations)
– Use the naming convention “Y1234-Description.launch”
– See the section titled “Epsilon launch configurations” on the following webpage for some guidance on how to persist launch configurations:
http://www.eclipse.org/epsilon/doc/articles/minimal-examples/
• src-gen (a directory containing the code generated by your model-to-text transformation for the ACME questionnaire in Question 2.5)
• src (a directory containing any hand-crafted code files you may need to implement the Q5 validation behaviour of the ACME questionnaire in Question 2.5)
Note that if you choose to implement a dedicated graphical or textual editor for your DSL, your editor should process models with an extension that matches your examination candidate
number (i.e, in place of “Y1234” in the above structure).
2023-06-16