代写Model-Driven Engineering Coursework Specification

日期：2024-02-28 09:09

Model-Driven Engineering

Coursework Specification

Overview

MDE is about technologies and methodologies for increasing the level of abstraction and automation

in software development and enabling non-programmer domain experts to contribute to the devel-

opment of software. Domain-specific modelling languages (DSMLs) and the underpinning infrastruc-

ture of IDE support, model transformations, code generation… are essential to this.

In class, you have learned about many of these technologies, and have applied them in a small way to

a fairly small language. In this piece of coursework, we challenge you to go larger: pick a domain-

specific language of your choice and build infrastructure for it. We provide you with three specific

examples of languages and you can choose any of them (see Section “Proposed Languages” at the

end).

In any case, you need to develop the following pieces of the language’s infrastructure:

1. A working editor with syntax highlighting, code completion etc. for textual languages and ef-

ficient edition support for graphical languages;

2. Validation support both for syntax, static semantics (well-formedness), and at least one ad-

vanced semantic check (dynamic semantics or some form of type checking, static verification

/ validation);

3. Language semantics to enable some form of execution either through analysis (simulation

based or other) or actual execution (interpreted or compiled) depending on the type of lan-

guage. For some existing languages, this may be easiest to do by building an improved version

of the existing language and writing a transformation that translates to the original language.

Think carefully about what validation and semantics are most useful for your chosen language. This

will be different for different languages. In fact, even when two students have chosen the same lan-

guage you may still end up focusing on different validation and semantics, depending on the purpose

you are considering most important.

What and how to submit

Remember, this is an official assessment. As such, the usual College rules about collusion and plagia-

rism apply. You must work on this coursework in pairs. Please ensure you clearly indicate in your sub-

mission who the members of the pair are.

This coursework comes with one deadline:

1. The final submission of report and implementation is due end on the 25th of April 2024.

You can find more detail on each deadline below.

Report and Implementation

This coursework accounts for 30% of your overall mark for the module. You are asked to submit the

coursework in two parts:

1. A Git repository – using the GitHub Classroom repository provided to you via the link on KEATS

– with the implementation of your language, including a README file indicating how to use

the language infrastructure and an example project that can be used to demonstrate the

Coursework

© King’s College London 2/4

capabilities of your language and infrastructure. It is your responsibility to ensure that the

instructions in the README file can be used on a fresh machine (Windows or Linux) to explore

the capabilities of your language at least in the context of the example project.

2. A PDF report (max. 7 pages) explaining your language design in detail. While you may wish to

include select screenshots and source code materials, be very careful about selecting what

you need to include and where you can reference the actual material in the Git repository

directly. Include a title page with the name of your language, your name and student ID (for

both members of your pair).1

In your report, include answers to the following questions (you may wish to add sub-headings

for each of these questions):

a. What is the language / domain you have chosen? Give a brief overview.

b. Why did you choose this language / domain? Why and how would an MDD approach

help in this domain? What is the purpose of your implemented MDD approach?

c. What is the syntax of your language? Is it a textual or a graphical language? Why?

d. What validations have you implemented? What techniques did you use for imple-

menting them? Why did you choose to implement these particular validations (why

are they the most important ones)? Which other validations could be implemented?

e. What execution have you implemented? What techniques did you use for implement-

ing it? Why did you choose to implement this particular execution (why is it the most

fit for purpose)?

f. Considering the fact that this language would be maintained by a team performing

peer work, how would the team perform the maintenance of the language? Discuss

and suggest different features of the DSML that would facilitate peer work in the

maintenance of your language and models.

g. What changes, if any, would you make to the existing language’s syntax (abstract or

concrete) and semantics and why? If you are not proposing any changes, how well is

the language aligned to its purpose?

(Where you are not building on an existing language: How did you choose the pro-

posed syntax and semantics and what did you do to ensure the language is fit for

purpose?)

Things to consider for a good submission.

You have most of the term to work on this, but you can already start your work in the first week. Do

not underestimate this coursework project: it will take a good amount of your time and you need to

carefully plan how to fit it around your other responsibilities. Make a careful plan of what you will do

and when and ensure you know what you will not do. It is OK not to implement support for every

feature of an existing language, if you can argue in your report that you have covered the most im-

portant features.

Here are some general suggestions for making good submissions:

- Many past reports let the submission down. There are several points that most reports would benefit

from:

1 The title page does not count towards the page limit.

Coursework

© King’s College London 3/4

o Often reports do not provide a clear description of who the target users of their language would

be and what purpose they would aim to achieve with this language. This is important even where

you have “invented” the language: you may not have actual data on target users and their pur-

pose, but you should at least make your assumptions explicit. These are essential in understand-

ing the rationale for your language design choices.

o Many reports do reasonably well in describing the language developed, but lack in providing ra-

tionale for why the language looks the way it does, why the specific validations have been chosen

etc. But that’s exactly where you can show us that you have understood more than just the tech-

nical details.

o Many reports lack technical detail: how were validations implemented? what were key design

decisions in the language design and what were the alternatives? Clearly, you need to show us

that you have understood the technology.

o Make sure to include references. In particular, where you implement support for an existing lan-

guage, we would expect to see some references to link back to the original language definitions.

- Language designs can fall short where they don’t consider the language’s purpose well enough:

o Where an existing language is the basis for the coursework, choosing to implement the language

exactly as is, is often a missed opportunity. Thinking of a specific purpose for your language would

enable you to think about a higher-level abstraction that then translates into the existing lan-

guage. For example, consider a language like SBML: XML is not really fit for human consumption,

don’t miss the opportunity to remove the XML from the concrete syntax and replace it with some-

thing more easily readable.

o Advanced validations can be tricky to come up with. Again, this goes back to thinking about pur-

pose: what are things that would go wrong most typically for language users? How can an auto-

mated validation catch those cases?

- There are many ways in which you can make it easier for us to assess your implementation effec-

tively:

o Make sure we don’t have to fiddle with the Eclipse projects just to get them to work. There

shouldn’t be any issues with settings for the Java VM, file encodings, missing (empty) folders, etc.

Often, we will be able to fix these issues, and test and run the submission, but it won’t make us

happy. We suggest that you test your implementation in a fresh workspace and from a fresh Git

checkout before submitting.

o It helps, if you can include an example project for us to test out.

o Not including any automated tests for the language developed is not a smart move in a software-

engineering module.

Coursework

© King’s College London 4/4

Proposed Language: Video editing language

Video editing is an ardoise task that requires strong efforts from the graphics cards to show real time

edition. However, in multiple cases, this can be automated with enough knowledge about the “Edit

Decisions” files that provide all the editing session. Although these files are very complete, from a

high-level perspective, they are difficult to understand and edit. We propose to create a DSML to edit

short videos (up to 100 seconds) by editing these files.

There are two main formats that you can use, which are EDL: Edit Decision Lists, and XML: Final Cut

Pro format, although we recommend using EDL. The outputs need to be compatible with the

OpenShot Video Editor:

https://www.openshot.org/

You can find more information about the two formats and compatibility here. Considerate all of the

potential limitations, for instance, none of them is compatible with transitions:

https://www.openshot.org/static/files/user-guide/import_export.html

For the language, you will need to provide a specific language that translates to these formats and

create models corresponding to video editing sessions.

The problems that you might want to solve with your language are:

1) Make sure your language is more human readable than the original format

2) A model for EDL can create and coordinate multiple EDL files for each of the different tracks

(audio and video could go into separate tracks).

3) Audio could be repeated in a loop for base sound.

4) Try to simplify some of the different supported features (but not all) of the standard docu-

mentation. Choose the ones that you would like to specialise. For instance, for EDL, check the

documentation provided in:

http://www.edlmax.com/EdlMaxHelp/Edl/maxguide.html

As part of the evaluation, provide a video editing session with a specific model created with your

DSML, describe it in the documentation. Do not forget to include test cases in the test section of your

project.