Reference no: EM133049638
CO4217 Agile Cloud Automation - University of Leicester
Project Part - Agile Cloud Automation
Introduction
In this mini project, your group is asked to develop a low-code development platform for a domain-specific language using the technologies discussed in the module.
This miniproject directly draws on the contents practised in the programming exercises of the second part of the module and its structure is similar to the first mini project.
Below you will find a brief description of what is expected in each exercise, together with the expected duration for each section and the mark breakdown. The accompanying rubric details the marking criteria for each exercise adding detail on what is expected and how each exercise is going to be marked.
Project supervision
Each group will be allocated a project supervisor and all communications regarding your project should be addressed to them. Our project supervisors have been trained to assist you in project tasks and teamwork. During the project before the submission date, there will be two important communications with your supervisor:
THE TOPIC PROPOSAL FORM with the following information
Title for the mini project, which represents the project topic. For example: a DSL for generating test cases for Cloud services.
The AIM of your project: the chosen problem domain and the scope of the project (the part of the problem to be considered). For example: Generation of test cases in Groovy from a Gherkin- like language. The DSL will support definition of features and scenarios with given/when/clause keywords. The skeleton of test cases will be generated using Junit. We are planning to consider advanced features like rules and scenario outlines. The when clause will contain a placeholder for linking the test with an actual implementation, like a call to REST service.
The METHODOLOGY to be used in your project: what examples you are going to consider in the modelling process and the different stages to be used (see week 16's modelling process). [max 100 words]
Initial individual contributions, uploading the spreadsheet of individual contributions if these are not even.
During the mini-project focus week (6-10 December), you should have a meeting of up to 25' with your project supervisor.
Before this meeting you should have tried the video submission procedure explained below by submitting a bogus video (skip if the person coordinating the submission has done it already in their first mini-project).
1. Individual contribution declarations
There are two options:
1. All members of the group are working on the project sensibly: exercise marks will be added up and the group mark will correspond to your individual mark. There is no need to report anything.
2. Members contributed unevenly (e.g., there are team members who did not contribute, etc): please fill in a copy of the contribution helper spreadsheet, stating your individual contributions as explained in THIS VIDEO (18') (from minute 3:05). This spreadsheet needs to be submitted via the THE GROUP PREFERENCES FORM used to propose your mini-project topic. IMPORTANT: Google sends an email once the submission is done. Please update the submission your group made already. DO NOT create a new submission.
2. Presentation Video
In groups, do the presentation online using Blackboard Collaborate or Microsoft Teams and record it (this video shows how to do it on MS Teams). The presentation can be put together in one single slide deck and a team member can share the screen. Then each team member explains their part as the slides are turned over.
Then download the video, check that it has been recorded correctly. Upload it by following the guide to submit a video assignment. The final step is to click on Write Submission and choose the video that must have been uploaded to Panopto previously.
3. Zipped file
The contents of the zipped file should be:
A document explaining your self-evaluation of the work done in the project according to the rubric. For each exercise in the worksheet you should propose a mark and a justification of that mark, according to the rubric, by showing how your presentation and software project addresses the main points in the rubric. Please be as specific as possible, giving pointers to examples and slides
number/paragraph. You should try to get feedback early during the mini-project focus week and your self-evaluation will be the justification of the mark. Your justification will be checked and, if it is sound, it will be your mark. Otherwise, we will mark the mini-project.
The Gradle project including all software artifacts involved in the project, after executing ./gradlew clean. Please execute this command before zipping contents.
A document explaining where the software artefacts can be located (presentation slides, software artifacts, test files, libraries) in the project folder, how to parse examples and how to compile them, where the results are obtained. Appropriate references to web pages, bibliography or additional resources that have been used need to be made, explaining what parts are reused and what parts are new.
Presentation slides: in the presentation slides: add the username of the presenter in the footnote of each slide used by that presenter.
Exercise 0: Project management (presentation, code, self- assessment) and submission
Exercise 1: Problem Domain (15 marks, max. 3 minutes)
Find a problem domain related to cloud technologies or cloud-inpired problems where automation of tasks can bring benefits, usually by generating code from concise scripts written using a DSL. The target code can be used for documenting a system (for example, by producing graphical representations of the system), for implementing (parts of) a system or for testing (parts of) a system, or for simulating a system.
Choose an appropriate DSL for that domain from the resources provided below (feel free to do research in a problem domain of your choice).
In the presentation, explain:
the aim of the project: the chosen problem domain and the scope of project (the part of the problem domain to be considered). For example: Generation of test cases in Groovy from a Gherkin-like language. The DSL will support definition of features and scenarios with given/when/clause keywords. The skeleton of test cases will be generated using Junit. We are planning to consider advanced features like rules and scenario outlines. The when clause will contain a placeholder for linking the test with an actual implementation, like a call to REST service.
the objectives of the project: the tasks to be automated;
some examples illustrating examples and potential benefits of such automation with a domain-specific language;
methodology to be used to design the DSL: this part can be regarded as a table of contents of the rest of the presentation and it can be expanded with methodology aspects discussed in taught units and tutorials.
A list of example DSLs that can be used for inspiration or as example can be found in the companion document. The examples illustrate different levels of academic achievement. Also please see the rubric for further information on how the worksheet will be marked.
Exercise 2: Metamodel (max. 2 minutes)
Provide a model of the problem domain in the form of a metamodel (using class diagram notation), characterising the scope of your DSL. Also include examples using object diagram notation.
In the presentation, explain:
An enumeration of key concepts and their intrinsic and extrinsic properties. The metamodel of the DSL capturing those concepts.
The examples shown in Exercise 1 can be modelled using object diagram notation.
Exercise 3: DSL Design (max. 3 minutes)
In the presentation, explain the design of your DSL, focussing on: Grammar of your DSL using Xtext notation.
Examples used in Exercises 1 and 2 written using the DSL.
How the tool ecosystem that Xtext generates can help your DSL users (domain experts).
Exercise 4: Code Automation (max. 5 minutes)
In the presentation, explain the model compiler (or interpreter) that you have built for your low-code development platform by:
Explaining the code patterns used, including the traversal strategy and an outline of code templates. Showing the code generated from the examples in exercise 3.
How that code can be used, for example by illustrating how the target code is executed or used in third-party tools.
Exercise 5: Critical Analysis and Conclusions (max. 2 minutes)
Wrap up your presentation with:
Summary of functionality in the current low-code development platform, and current limitations (e.g. known issues, lack of expressivity).
Evaluation performed with examples, either by enumerating the examples used or by describing a test suite.
Lessons learnt in designing and developing the DSL and its model compiler that are worth remembering for developing other DSLs.
Future work: how you would continue the development of the DSL in order to address identified limitations.
Attachment:- Agile Cloud Automation.rar