Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Engineering 2: Automated Software Engineering (ENG2)
Open Individual Assessment
Rubric:
Your submission should include a report and an implementation. You must submit a single zip file containing your report in PDF format, and your implementation files. The report should use single-spaced lines using a sans-serif 11-point font (e.g. Arial). Submissions in a different format (e.g. a Microsoft Word document in a RAR archive), will be penalised. Note the page limits: parts of answers that go beyond the page limit may not be marked. Use IEEE citation and referencing: references must be listed at the end of the document and do not count towards the page limit.
2.2 Part 2: Application of Model-driven Engineering [40 marks]
2.2.1 Metamodel
Use Emfatic/Ecore to define a metamodel for the domain-specific language described in Section 1.2. 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. [8 marks] (max 2 pages)
2.2.2 Graphical Concrete Syntax
Use Eclipse Sirius or Picto to define and implement a graphical concrete syntax for the metamodel you defined in Question 2.2.1. Design the model of your architecture in your language, provide a screenshot of the model in your concrete syntax, discuss and justify your syntax design and implementation decisions, and reflect on the strengths and weaknesses of the selected concrete syntax compared to alternatives. [12 marks] (max 2 pages)
2.2.3 Model Validation
Use the Epsilon Validation Language to implement any validation constraints specified in Section 1.2, which cannot be expressed in the metamodel itself. Briefly explain the rationale and implementation of each constraint. [5 marks] (max 1 page)
2.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 DSML, and produces some of the code that you wrote manually in Part 1. Here are some suggestions:
• Scaffolds for the implementations of the microservices and the clients, with clear
separation between automatically generated code, and hand-written customisations to write the detailed behaviour.
• Custom message beans for Kafka, implementing your events.
• Container orchestration for your application (e.g. Docker Compose files).
Discuss the model-to-text transformations and justify the organisation of the generated code. [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)
• microservices (a directory containing your microservices implementation)
– docker-compose.yml (should be able to bring up your system with a single docker compose up command)
– video-microservice (a directory with your VM implementation)
– trending-microservice (a directory with your THM implementation)
– subscription-microservice (a directory with your SM implementation)
– client (a directory with your command-line client(s) for the microservices)
• modeling (a directory containing your application of model-driven engineering)
– metamodel (a directory containing your metamodel files and any Sirius/Picto-related files)
* Y1234.emf or Y1234.ecore (your metamodel, in Emfatic/Ecore)
· The name and namespace URI of the root package of your metamodel should also be Y1234.
* Y1234.evl (your EVL validation constraints)
– 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)
– models (a directory containing your models)
* acme.aird or acme.model or acme.Y1234 or acme.flexmi (your model of your system)
* 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 transformations)
* Use the naming convention “Y1234-Description.launch”
* You should generate the code directly into the relevant microservices subfolder: it is recommended to organise your microservices code to clearly separate manually-written and generated code (e.g. by keeping them in separate folders)