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.

Figure 1: ACME Questionnaire

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 Figure 1).

•  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.

2.1  Metamodel

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)

2.2  Concrete Syntax

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, and reflect 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).

Figure 2: Q5 Validation Error

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.

package  g ;

class  Graph   {

val  Node [ * ]   nodes ;

val  Edge [ * ]   edges ;

}

class  Node  {

a t t r   String   l a b e l ;

r e f   Edge [ *] # source   outgoi ng ;

r e f   Edge [ *] # t a r g e t   incoming ;

}

class  Edge  {

a t t r   String   l a b e l ;

r e f   Node# outg oing   source ;

r e f   Node# incoming   t a r g e t ;

}

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.

Figure 3: ACME Questionnaire Dependency Graph

Note: Figure 3 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)

3 Submission Instructions

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