1

Code Generation as a Service

Robert Crocombe, Dimitris Kolovos Department of Computer Science

University of York

2 Motivation

•  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 Scenario

•  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

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

6 Objectives

•  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

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

8

=  

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 <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

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

12 Asynchronous 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

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

14

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

15 Pros/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 Future 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