CloudMDE 2015 presentation

1. 1
Code Generation as a Service
Robert Crocombe, Dimitris Kolovos
Department of Computer Science
University of York

2. 2Motivation
• Model-Driven Engineering
– Steep learning curve
– Non-trivial tools with lots of dependencies
• Lowering the entry barrier for developers
– Allow developers to model with spreadsheets,
annotated drawings, XML etc.
• Lowering the entry barrier for users
– Simplify distribution and use

3. 3Scenario
• Team of (non-MDE) developers
• Company/client has a bespoke data
persistence architecture
– e.g. system maintains multiple versions of the
data / authorisation through an external system
• Large legacy code-base
– Rewriting all of it using a new framework not an
option
• New code amenable to generation

4. 4
$ orm –model m.uml –lang java –o /temp

6. 6Objectives
• Simplify distribution of code generators
– Minimise effort for generator developers and
users
• Ensure that all members of the team are
always working with the latest version of
the generator

7. 7
$ xgen orm –model m.uml –lang java –o /temp

8. 8
=

9. 9
<project>
...
<property name="model" description="A valid UML model"/>
<property name="lang"
description="Output language: java or python"/>
<epsilon.emf.loadModel name="UML" file="${model}" ... />
<epsilon.evl src="orm.evl"> <!-- validation -->
<model ref="UML"/>
</epsilon.evl>
<epsilon.egl src="orm-${lang}.egx"> <!-- generation -->
<model ref="UML"/>
</epsilon.egl>
...
</project>
build.xml

10. 10
<project>
<!-- #file -->
<property name="model" description="A valid UML model"/>
<!-- #string -->
<property name="lang"
description="Output language: java or python"/>
<epsilon.emf.loadModel name="UML" file="${model}" ... />
<epsilon.evl src="orm.evl"> <!-- validation -->
<model ref="UML"/>
</epsilon.evl>
<epsilon.egl src="orm-${lang}.egx"> <!-- generation -->
<model ref="UML"/>
</epsilon.egl>
...
</project>
build.xml

11. 11
$ xgen orm –model m.uml –lang java –o /temp

12. 12Asynchronous Execution
• When xgen is executed:
– the server schedules a new generation job;
– returns the scheduled job's id
• xgen can then query the server for the status of
that job
– Waiting
– Running
– Compressing
– Success (separate call to retrieve output)
– Error (+log)
– Cancel
• Jobs can be cancelled

13. 13
$ xgen orm –model m.uml –lang java –o /temp

14. 14
$ xgen dk/orm –model m.uml –lang java –o /temp

15. 15Pros/Cons
• Pros
– Simplifies generator deployment
– Users only need to install a thin client
– Don't have to reveal the generation logic
• Cons
– Network latency
– Generation server can become a bottleneck
– Confidentiality

16. 16Future Work
• Support other back-ends (e.g. GitLab)
• Private generator repositories
• Synchronous execution (for small jobs)
• Sandboxing
• Job management
– e.g. kill long-running jobs
• Deploy a publicly-accessible version of the
generation server
– e.g. on Google AppEngine