6CCS3MDE/7CCSMMDD Coursework 02/12/2022 © King’s College London 1/4 6CCS3MDE/7CCSMMDD – Model-Driven Development Coursework Specification Overview 6CCS3MDE/7CCSMMDD 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 development of software. Domain-specific modelling languages (DSMLs) and the underpinning infrastructure 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. You can pick any existing domain- specific language—either a technical language like Docker or jHipster, or a language addressing concerns in a non-technical domain (e.g., SBML from biological modelling, or public space patterns from urban modelling). Don’t know where to start? Here is a great conversation on Twitter, where many people have suggested their favourite languages. If you really want to impress us, you can pick a domain for which there isn’t yet a language.1 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 efficient edition support for graphical languages; 2. Validation support both for syntax, static semantics (well-formedness), and at least one advanced 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 language. 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 language you may still end up focusing on different validation and semantics, depending on the purpose you are considering most important. For example, for a jHipster implementation you may choose to focus on generating running application implementations (different from those already generated by the existing jHipster infrastructure) or, alternatively, may provide analysis of potential performance bottlenecks in the modelled application. You may also choose to build a better 1 Though this is likely to make the coursework substantially more challenging, but will not give you extra marks, we will definitely be impressed and may even find a congratulatory chocolate bar. 6CCS3MDE/7CCSMMDD Coursework 02/12/2022 © King’s College London 2/4 jHipster and translate down to jHipster. Or why not translate from webmachine to jHipster? What and how to submit Remember, this is an official assessment. As such, the usual College rules about collusion and plagiarism apply. You must work on this coursework in pairs. Please ensure you clearly indicate in your submission who the members of the pair are. This coursework comes with two deadlines: 1. To support you in deciding on a good DSML to implement, we ask that you submit an overview plan by the end of Week 5 of teaching (just before reading week). 2. The final submission of report and implementation is due end of term (see precise deadline on KEATS). You can find more detail on each deadline below. Overview plan For the overview plan, please submit a 1-page report in PDF format. This should describe: 1. The DSML you plan on implementing and briefly why you have chosen this. 2. Your plans for the syntax, validations, and semantics / execution that you are hoping to implement and why you believe these will be useful. Note that you will not be able to provide a lot of technical detail. This is on purpose: the goal of this report is not to describe your final solution, but to give us an idea of what you’re aiming to achieve so we can provide feedback on whether this is a good direction to go in or whether you should consider adjusting your project in some way. This is a formative part of the overall coursework – you will receive feedback but no mark. You will not be able to submit an MCF if you miss the deadline. Not submitting the report by the deadline will simply mean you miss the opportunity to receive feedback on your early ideas – so we strongly encourage you to make sure you submit something. Report and Implementation This coursework accounts for 30% of your overall mark for 6CCS3MDE/7CCSMMDD. 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 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. 6CCS3MDE/7CCSMMDD Coursework 02/12/2022 © King’s College London 3/4 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).2 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 implementing 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 implementing it? Why did you choose to implement this particular execution (why is it the most fit for purpose)? f. 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 proposed 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 important 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: 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 purpose, but you should at least make your assumptions explicit. These are essential in understanding the rationale for your language design choices. 2 The title page does not count towards the page limit. 6CCS3MDE/7CCSMMDD Coursework 02/12/2022 © King’s College London 4/4 o Many reports do reasonably well in describing the language developed, but lack in providing rationale 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 technical 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 language, 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 language. 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 something more easily readable. o Advanced validations can be tricky to come up with. Again, this goes back to thinking about purpose: what are things that would go wrong most typically for language users? How can an automated validation catch those cases? - There are many ways in which you can make it easier for us to assess your implementation effectively: 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.
欢迎咨询51作业君
