Model Driven Development

Software Process Engineering

Giovanni Ciatto — giovanni.ciatto@unibo.it

Compiled on: 2026-10-15 — printable version

back

Lecture goals

• Understand metamodelling
• Understand domain specific languages
• Discuss the role of DSLs and code generators in the LLM era
• Practice with model driven development in Xtext

Outline

1. Meta-modelling: models, meta-models, meta-meta-models, Ecore, abstract vs. concrete syntax
2. Model-driven development: modelling first, automation of implementation
3. Domain-specific languages: what they are, examples, DSL vs. GPL
4. DSL engineering: semantics, translation vs. interpretation, internal vs. external DSLs
5. DSLs in the LLM era: LLMs vs. code generators, DSLs as targets for LLMs
6. MDD in practice: tools, LSP, Xtext
7. Running example: Sheduler: grammar, validation, scoping, execution engine, generator, interpreter
   • each exercise has its solution in a vertical sub-section (press down to see it, right to skip it)

Main references: Völter et al., DSL Engineering, 2013, Fowler, Domain-Specific Languages, 2010

Meta-modelling nomenclature

0. (Abstract) Language $\approx$ (abstract) syntax + semantics

1. Model $\approx$ an abstract description of the possible entities involved in a domain, and their relations

   • the model abstracts a number of similar systems rooted in the domain
   • each system is an instance of the model it has been designed from
   • a model is a template for several systems

2. In which language is the model expressed?

   • Meta-model $\approx$ the definition of the concepts (and rules) available for writing models in a given language
   • for instance UML is a modelling language commonly used to describe object-oriented designs
     • its meta-model defines concepts such as class, attribute, operation, association
     • UML $\equiv$ Unified Modeling Language

3. In which language is the meta-model expressed?

   • Meta-meta-model $\approx$ the language by which we describe meta-models
   • for instance, according to OMG, the meta-model of UML is defined in MOF
     • MOF $\equiv$ Meta-Object Facility
     • OMG $\equiv$ Object Management Group

Meta-model hierarchy

Meta-model hierarchy example

Instance of vs. conforms to

• Between adjacent layers there are two different relations, which are easy to confuse:

  1. instance of: an element of a layer is an instance of an element of the layer above
     • e.g. the class Customer (M1) is an instance of the meta-class Class (M2)
     • e.g. the object john (M0) is an instance of the class Customer (M1)
  2. conforms to: a whole model conforms to a whole meta-model
     • i.e. every element is an instance of some meta-element, and all the meta-model’s rules are respected
     • e.g. multiplicities, types of references, uniqueness of names, etc.

• Checking conformance is a mechanical activity

  • this is precisely what parsers and validators do (we will write one in Exercise 1)

• The top layer is reflexive: MOF conforms to MOF

  • this is what stops the tower at M3 (no M4 is needed)
  • same trick as a compiler for language $L$ written in $L$

Inside a meta-meta-model: Ecore

• MOF is large: its practical core is EMOF (Essential MOF)
• Ecore is the Eclipse Modeling Framework (EMF) implementation of (roughly) EMOF
  • it is what Xtext uses under the hood
• Few concepts suffice to write any meta-model:
  • EPackage: a namespace of meta-classes, identified by an URI
  • EClass: a concept of the domain, possibly with super-types
  • EAttribute: a property whose value is a datum (string, int, enum)
  • EReference: a property whose value is another model element
    • containment: the referenced element is part of the container (a tree)
    • cross-reference: the referenced element lives elsewhere (a graph)
  • lowerBound / upperBound: multiplicities (0..1, 1, *)
  • EEnum: a finite set of literals

Abstract vs. concrete syntax

• A meta-model defines the abstract syntax of a language

  • which concepts exist, and how they can be related
  • it says nothing about how models are written down

• The concrete syntax is the notation users actually read / write

  • textual (e.g. via Xtext), graphical (e.g. via Sirius), tabular, tree-based, …
  • there may be several concrete syntaxes for the same meta-model

title: Domain-Specific Languages
year: 2010
authors:
  - name: Martin Fowler
  - name: Rebecca Parsons

<book title="Domain-Specific Languages" year="2010">
  <author name="Martin Fowler"/>
  <author name="Rebecca Parsons"/>
</book>

• Different notations, same abstract structure: both conform to the meta-model on the left

What a meta-model cannot say: static semantics

• Structural meta-models only capture types and multiplicities

• Many rules of a domain are not structural, e.g.:

  • “two authors of the same book cannot have the same name”
  • “the title of a book cannot be empty”
  • “a book cannot be published in the future”

• These are called static semantics (or well-formedness rules)

  • OMG’s way: constraints written in OCL (Object Constraint Language), attached to the meta-model

    context Book
    inv uniqueAuthorNames: self.authors->isUnique(a | a.name)
    inv nonEmptyTitle: self.title.size() > 0
    

  • Xtext’s way: validation rules written in a GPL (Java), see Exercise 1

• Takeaway: meta-model + well-formedness rules = what it means for a model to be correct

  • dynamic semantics (what a correct model does when executed) comes later, from the execution engine

Why are meta-models important?

• Meta-models are the very first thing you should try to identify whenever approaching a new technology

• If you grasp the meta-model, you grasp the essence of the technology

  • which may be the same for many other technologies

• E.g. after you learned the basics of OOP (classes, methods, objects, etc.) you may easily learn any other OOP language

  • by simply asking yourself how each meta-model element is expressed in the new language
    • e.g. how are classes / methods / objects expressed in the new language?

• When you model a domain (e.g. with DDD) you are always exploiting some meta-model

  • whether you are aware of it or not

Model-driven whatever

• Several slightly similar names may create confusion

  • e.g. model-driven engineering / development / architecture / etc.

• Please read Martin Fowler’s article on Model Driven Architecture to clarify

• Despite the name, the key ideas can be summarised as follows:

  1. software engineering workflow should start by modelling the domain at hand carefully

     • e.g. with DDD
     • as opposed to focussing on algorithms and data structures

  2. the production of a runnable implementation should be automated as much as possible

     • e.g. by generating code from models
     • as opposed to writing code by hand

About code generation from models

• Assumption: the model is expressed by means of some formal language

• Formal language $\approx$ interpretable by a machine

• Formality is a prerequisite for automation

  1. the model is parsed by a machine
  2. the model is transformed into another formal language (e.g. OO programming language)
  3. the transformed model is rendered into a file (e.g. source code)

• Is UML adequate? Is it the only choice? Any alternative?

  • UML has a formal syntax and semantics (reified into graphical representation rules)
  • rarely enforced by software tools
  • furthermore UML is focussing on software
    • only practical for software engineers

Benefits of adopting DSL

1. To communicate with domain experts in their own language

   • e.g. Gherkin is a language that can be understood by both engineers and stakeholders

2. To let domain experts write the specifications (i.e. the model) of the system they want

   • hence reducing ambiguities among stakeholders and engineers

3. To focus on the domain rather than on the implementation

4. To hide the implementation details from the domain experts

   • e.g. exposing only business-related concepts, at the domain level

DSL vs. GPL

• DSLs are not a replacement for GPLs

  • they are complementary

• Yet the difference is fuzzy, so let’s try to clarify (cf. Völter et al., DSL Engineering, 2013):

DSL Engineering

Semantics of DSL

• Most often, the focus is on the syntax of the DSL

  • as that’s how users will perceive it

• Yet, the semantics of the DSL is equally important

  • that dictates how the DSL works
  • and this is what engineers (DSL implementers) focus upon

• Intuitively, semantics is given to languages by writing the machinery supporting their execution

  • three main aspects:
    1. conversion into runnable code (e.g. translation or interpretation) …
    2. … leveraging an execution engine (i.e. library functionalities supporting the runnable code) …
    3. … in turn relying on a software platform (e.g. JVM, .NET, etc.)

The role of DSL engineers mostly focuses on steps 1 & 2 (besides defining the syntax)

Converting DSL into runnable code

Two main approaches:

• Translation: translates a DSL script into a language for which an execution engine on a given target platform exists

  • a.k.a. code generation or transpilation if the target language is high-level (e.g. Java, JS, or C#)
    • e.g. Xtend, or TypeScript, despite being GPL, are transpiled into Java and JS respectively
  • a.k.a. compilation if the target language is low-level (e.g. assembly, JVM bytecode, CIL, etc.)
    • e.g. Java is compiled into JVM bytecode (despite being a GPL)

• Interpretation: the execution engine is able to parse and execute the DSL script directly

  • a.k.a. runtime interpretation or runtime compilation if the execution engine is able to compile the DSL script into runnable code
    • e.g. 2P-Kt is a GPL interpreted by a custom execution engine, written in Kotlin, running on the JVM

In both cases, there are technical prerequisites:

• a parser for the actual syntax of the DSL should exist / be generated
• the execution engine for the target platform should exist

DSLs in the LLM era

Isn’t an LLM just a better code generator?

• Large Language Models (LLMs) generate code from natural language prompts

  • so, why bother writing grammars, validators, and generators?

• Because the two kinds of “code generators” have different guarantees:

• Non-determinism is measurable: same prompt, different programs, even at temperature 0

  • cf. Ouyang et al., An Empirical Study of the Non-determinism of ChatGPT in Code Generation, ACM TOSEM

• Martin Fowler (2025) frames LLMs as moving programming up the abstraction levels and, at the same time, sideways into non-determinism

DSLs as a target for LLMs

• The two approaches can be combined: let the LLM write the model, not the code

  • natural language $\xrightarrow{\text{LLM}}$ DSL script $\xrightarrow{\text{parse + validate}}$ model $\xrightarrow{\text{generator}}$ code
  • if validation fails, the errors are sent back to the LLM, which repairs the script (repair loop)

• Benefits:

  • the output space is small and constrained (few constructs, no Turing-complete escape hatches)
  • validators catch wrong outputs, and their messages can be fed back to the LLM to repair them
  • the DSL script is reviewable by domain experts, the generated code need not be
  • the deterministic part (generator + execution engine) is tested once
  • a grammar can even be used to constrain decoding, so that only syntactically valid scripts are produced
    • cf. Poesia et al., Synchromesh, ICLR 2022, Wang et al., Grammar Prompting for DSL Generation with LLMs, NeurIPS 2023

• Caveat: LLMs know little about your DSL, as it is absent from their training data

  • LLMs are known to perform worse on low-resource languages (cf. Cassano et al., 2023)
  • practical mitigation: put the grammar, a few examples, and the validator’s errors into the prompt

Meta-models are everywhere in LLM tooling

• Many mechanisms of LLM-based systems are meta-modelling in disguise:

  • JSON Schema for structured outputs $\rightarrow$ a meta-model the LLM’s answer must conform to
  • tool / function definitions (e.g. in the Model Context Protocol) $\rightarrow$ typed signatures, i.e. a meta-model of the admissible calls
  • OpenAPI specifications $\rightarrow$ a DSL describing HTTP APIs, from which clients / servers are generated

• Same concepts as in this lecture:

  • abstract syntax (the schema) vs. concrete syntax (JSON text)
  • conformance checking (schema validation) before execution (tool call)

• Takeaway: the ability to design a precise vocabulary for a domain did not lose value

  • it is what makes LLM outputs checkable

When is a DSL worth it, today?

• Likely worth it when:

  • the domain is stable and many models will be written over time
  • domain experts must read or write the specifications (e.g. finance, hardware, regulations)
  • guarantees matter: the same model must always produce the same behaviour
  • the same model must be turned into several artifacts (code, docs, configurations, tests)

• Likely not worth it when:

  • the code is one-off glue, with a single user
  • the domain is still unclear or changing fast
  • an internal DSL or a plain library in a GPL is enough

• LLMs also lower the cost of building DSL tooling (grammars, validators, generators are well-known patterns)

  • whether this changes the trade-off in practice is still an open question: the tooling must be maintained anyway

MDD in Practice

Tools for MDD

• Language Server Protocol (LSP): relevant for any of the above, see next slide

• Maturity note: Xtext is mature and widely used, yet its own release notes for 2.44 (Aug. 2026) state that its future maintenance is at risk due to declining contributions (cf. discussion)

Key idea behind LSP

• de-facto standard protocol among IDEs

• providing various IDE-like capabilities as-a-service

• making it easier to support multiple IDEs for the same language

• must-have feature for any MDD tool we may consider for our DSL

About Xtext

• A framework for MDD and, in particular, external DSL

• Xtext provides a language for defining languages…

• … which is also a meta-modelling language

• Meta-modelling and DSL definition are done simultaneously

• It automatically generates the full language infrastructure, including

  • model interfaces / classes (EMF compliant)
  • parser
  • validator (with pluggable rules)
  • transpiler stub
  • scoping (with pluggable rules)
  • IDE support via LSP
  • syntax colouring
  • test stubs
  • etc.

• Exercises and examples about MDD will be based on Xtext

Running example: the task scheduling domain

• Users may want to schedule custom tasks on a machine

• Task $\equiv$ running any command available on the OS

  • via some shell (e.g. bash, cmd, powershell, etc.) of choice

• Scheduling implies defining when the task should be executed

  • relative to now: e.g. in 5 minutes, in 1 hour, etc.
  • absolutely: e.g. today at 10:00, tomorrow at 12:00, on 2023/11/23 at 13:16 etc.
  • before or after some other task
  • periodically: e.g. every 5 minutes, every 48 hours, etc.

• Notice that tasks may be inter-dependent (e.g. because of before/after relations)

Running example: the Sheduler DSL (pt. 1)

Sheduler $\equiv$ Shell + Scheduler

¯\(ツ)/¯

1. We shall use Xtext’s meta-modelling language to define the domain of task scheduling

2. Simultaneously, we will define the syntax of the DSL

3. We will then add scoping and validation rules to the DSL, via the Xtext framework

4. The next step is designing and implementing the execution engine for the DSL

   • we shall exploit Java’s ScheduledExecutorServices for this purpose

5. Finally, we will create a code generator creating Java code from the DSL

Running example: the Sheduler DSL (pt. 2)

Code: https://github.com/unibo-spe/sheduler-lang

1. Clone with Git the exercises branch

2. The cloned repository is an Eclipse project

   • please install Eclipse for DSL developers from Xtext’s website

3. In Eclipse, import the repository root directory as a Gradle project

4. You may also use IntelliJ; in that case just import the repository root directory as a Gradle project

   • no syntax colouring or Xtext support on IntelliJ or VSCode

Running example: how to work on the exercises

• The exercises branch contains placeholders for each exercise:

  • TODO Ex N.M comments break exercise N into small steps M (most IDEs list them in a TODO view)
  • unimplemented methods throw UnsupportedOperationException("TODO Ex N.M: ...")

• Each exercise has tests in it.unibo.spe.mdd.sheduler/src/test/java, marked as @Disabled("TODO Ex N.M ...")

  • remove the annotation once you are done, then run ./gradlew build

• The execution engine (runtime/ShedulerRuntime.java, runtime/ShedulerTask.java) is given, except for Exercise 5

  • a copy of both classes lives in src/main/resources/.../generator/*.java.template, for the code generator
  • RuntimeTemplatesSyncTest checks that the copies are identical: if you edit the classes, copy them over

• Solutions:

  • on the master branch of the repository
  • in these slides, in a vertical sub-section after each exercise (press down to see it, right to skip it)

Let’s model a bit

grammar it.unibo.spe.mdd.sheduler.Sheduler with org.eclipse.xtext.common.Terminals

generate sheduler "http://www.unibo.it/spe/mdd/sheduler/Sheduler"

TaskPoolSet: pools+=TaskPool+ ;

TaskPool: 'pool' name=ID? '{' tasks+=Task+ '}' ;

Task:
    'schedule' ('task' name=ID)? '{'
        'command' command=STRING
        ('entry' 'point' entrypoint=STRING)?
        (
            'in' relative=RelativeTime |
            'at' absolute=AbsoluteTime |
            'before' before=[Task] |            // square brackets denote references to other model elements
            'after' after=[Task]
        )
        ('repeat' 'every' period=RelativeTime)?
    '}'
;

AbsoluteTime: date=Date time=ClockTime ;

Date: year=INT '/' month=INT '/' day=INT;

ClockTime: hour=INT ':' minute=INT (':' second=INT (':' millisecond=INT (':' nanosecond=INT)?)?)? ;

RelativeTime: timeSpans += TimeSpan (('and' | ',' | '+') timeSpans += TimeSpan)* ;

TimeSpan: duration=INT unit=(TimeUnit|LongTimeUnit);

enum TimeUnit: NANOSECONDS = 'ns' | MILLISECONDS = 'ms' | SECONDS = 's' | MINUTES = 'm' | HOURS = 'h' | DAYS = 'd' | WEEKS = 'w' | 	YEARS = 'y' ;

enum LongTimeUnit returns TimeUnit:
    NANOSECONDS = 'nanoseconds' |
    MILLISECONDS = 'milliseconds' |
    SECONDS = 'seconds' |
    MINUTES = 'minutes' |
    HOURS = 'hours' |
    DAYS = 'days' |
    WEEKS = 'weeks' |
    YEARS = 'years' ;

From grammar to meta-model

Xtext infers an Ecore meta-model from the grammar, following a few rules:

• Alternatives ('in' ... | 'at' ...) become optional features: “exactly one is set” is guaranteed by the parser, not by the meta-model

The inferred meta-model

Sheduler across the four layers

• Each row conforms to the row above it:

  • Sheduler.xtext is written by you (DSL engineer)
  • .shed files are written by users (domain experts)
  • M0 is produced by the execution engine (via generated code, or via an interpreter)

• The same M3 is shared by all EMF-based languages

  • hence generic tools (editors, serialisers, comparators, transformations) work for any of them

Try the syntax

• Run task jettyRun to start the web playground

• Open http://localhost:8080

• Copy-paste the following example program:

  pool {
      schedule task greetWorldFrequently {
          command "echo hello"
          entry point "/bin/sh -c"
          in 5 minutes
          repeat every 1 hours
      }
  }
  

• What you should see (press Ctrl+Space to see the auto-completion menu)

The language pipeline

• Every tool for external DSLs implements (a variant of) this pipeline
• Xtext generates stage 1 entirely, and gives default implementations for stages 2 and 3
• The exercises below customise stages 2–3, and implement stage 4 and the engine

About validation rules (pt. 1)

• Validation rules are defined in the ShedulerValidator class

  • package: it.unibo.spe.mdd.sheduler.validation
  • Gradle sub-project: sheduler-lang/it.unibo.spe.mdd.sheduler

• Stub class is generated by Xtext when running the generateXtextLanguage task

  • which simply triggers the execution of the GenerateSheduler.mwe2 file

• Content of the stub and validation rule example:

  package it.unibo.spe.mdd.sheduler.validation;
  import it.unibo.spe.mdd.sheduler.sheduler.*;
  import org.eclipse.xtext.validation.Check;
  import org.eclipse.xtext.validation.CheckType;
  
  public class ShedulerValidator extends AbstractShedulerValidator {
      @Check(CheckType.FAST)
      public void ensureDateIsValid(Date date) {
          if (date.getYear() < 0) {
              error("Year must be positive", date, ShedulerPackage.Literals.DATE__YEAR, 0);
          }
          if (date.getMonth() < 1 || date.getMonth() > 12) {
              error("Month must be between 1 and 12", date, ShedulerPackage.Literals.DATE__MONTH, 0);
          }
          if (date.getDay() < 1 || date.getDay() > 31) {
              error("Day must be between 1 and 31", date, ShedulerPackage.Literals.DATE__DAY, 0);
          }
      }
  }
  

  • documentation here: https://eclipse.dev/Xtext/documentation/303_runtime_concepts.html#validation

About validation rules (pt. 2): what to notice

• the name of the validation method is meaningless
• only the type of the parameter matters, plus the presence of the @Check annotation
  • Xtext walks the whole model, and calls each @Check method on every object of the matching type
  • e.g. ensureDateIsValid(Date) is called once per Date in the file
• the CheckType argument of @Check is optional, and defaults to CheckType.NORMAL
  • FAST checks run whenever a file is modified
  • NORMAL checks run when saving the file
  • EXPENSIVE checks run when explicitly validating the file via the menu option
• error(message, object, feature, ...) reports a problem on a specific feature of a specific object
  • ShedulerPackage.Literals.DATE__MONTH is the meta-model element for Date.month (M2 used at run time!)
  • this is what makes the editor underline exactly the month, rather than the whole date
• error(...) may be replaced by warning(...) (or info(...)) for minor issues
  • errors mean the model is not well-formed, so it must not be executed; warnings are advice
• the validator only sees parsed models: syntax errors are reported by the parser, before validation

Exercise 1: custom validation rules (pt. 1)

Write custom validation rules covering the following constraints:

1. Warning if attempting to represent some RelativeTime as java.time.Duration object would result in an overflow

   • cf. the utility methods in class TimeUtils

2. Warning if attempting to represent some AbsoluteTime as java.time.LocalDateTime object would result in an overflow

   • cf. the utility methods in class TimeUtils

3. Warning if some AbsoluteTime is in the past or in the present (only future admitted)

   • cf. the utility methods in class TimeUtils
   • cf. LocalDateTime.now()
   • cf. LocalDateTime.isBefore()

4. Error if some ClockTime is invalid

   • hour must be between 0 and 23
   • minute must be between 0 and 59
   • second must be between 0 and 59
   • millisecond must be between 0 and 999
   • nanosecond must be between 0 and 999

About scoping rules

• Scoping rules are defined in the ShedulerScopeProvider class

  • package: it.unibo.spe.mdd.sheduler.scoping
  • Gradle sub-project: sheduler-lang/it.unibo.spe.mdd.sheduler

• Stub class is generated by Xtext when running the generateXtextLanguage task

• Content of the stub and scoping rule example:

  public class ShedulerScopeProvider extends AbstractShedulerScopeProvider {
      @Override
      public IScope getScope(EObject context, EReference reference) {
          return super.getScope(context, reference);
      }
  }
  

  • Documentation here: https://eclipse.dev/Xtext/documentation/303_runtime_concepts.html#scoping

• Remarks

  • only one method should be overridden
  • it should return an IScope object, for each EObject containing some EReference
  • in our case, this could only happen in Tasks’ before and after properties
  • the scope is essentially a container of EObjects, which are the possible values for the EReference
    • the implementer of the scope provider should select which EObjects to include in the scope

Giving semantics to the language

• Two approaches:

  • interpretation: the DSL is interpreted by some execution engine
  • translation: the DSL is translated into some executable code, leveraging the API of some execution engine

• Both approaches require the definition of an execution engine

  • i.e. a library providing the functionalities of the DSL

Focus on the execution engine

1. Is there functionality in the JDK which supports the scheduling of tasks in the future?

   • if yes: let’s use it! otherwise, let’s look for some third-party library, or implement it ourselves
   • luckily, we may use ScheduledExecutorServices !

2. Same question for the execution of custom commands via some shell?

   • luckily, we may use ProcessBuilders!

3. Design insights:

   1. we may define some custom notion of ShedulerTask encapsulating:
      • the command to be executed
      • optionally, the shell to be used
      • the initial delay
      • optionally, the period
      • optionally, the tasks to be executed before/after
      • the functionalities for executing the command via ProcessBuilders
   2. we may define some custom notion of ShedulerRuntime
      • leveraging the ScheduledExecutorService API…
      • … to schedule the ShedulerTasks for execution

Example: the ShedulerRuntime and ShedulerTask classes

Given in package it.unibo.spe.mdd.sheduler.runtime (ShedulerTask shown before Exercise 5):

public class ShedulerRuntime {
    private final ScheduledExecutorService delegate;

    public ShedulerRuntime(ScheduledExecutorService delegate) {
        this.delegate = Objects.requireNonNull(delegate);
    }

    public void schedule(ShedulerTask task) {
        if (task.isPeriodic()) {
            delegate.scheduleAtFixedRate(
                task.asRunnable(),
                task.getDelay().toMillis(),
                task.getPeriod().toMillis(),
                TimeUnit.MILLISECONDS
            );
        } else {
            delegate.schedule(
                task.asRunnable(),
                task.getDelay().toMillis(),
                TimeUnit.MILLISECONDS
            );
        }
    }
}

public class ShedulerTask {
    private ShedulerTask(String name, String command, String entrypoint, Duration delay) { /*...*/ }

    public String getName() { /*...*/ }
    public String getCommand() { /*...*/ }
    public String getEntrypoint() { /*...*/ }
    public Duration getPeriod() { /*...*/ }
    public boolean isPeriodic() { /*...*/ }
    public ShedulerTask setPeriod(Duration period) { /*...*/ }
    public Duration getDelay() { /*...*/ }

    public Process executeAsync() throws IOException {
        List<String> cmd = new ArrayList<>(List.of(entrypoint.trim().split("\\s+")));
        cmd.add(command); // e.g. ["/bin/sh", "-c", "echo hello"]
        return new ProcessBuilder(cmd).inheritIO().start();
    }

    public Runnable asRunnable() {
        return () -> {
            try {
                executeAsync();
            } catch (IOException e) {
                e.printStackTrace();
            }
        };
    }

    public static ShedulerTask in(String name, String command, String entrypoint, Duration delay) { /*...*/ }
    public static ShedulerTask in(String command, String entrypoint, Duration delay) { /*...*/ }

    public static ShedulerTask at(String name, String command, String entrypoint, LocalDateTime dateTime) { /*...*/ }
    public static ShedulerTask at(String command, String entrypoint, LocalDateTime dateTime) { /*...*/ }
}

The execution engine: what to notice

• The engine is a thin layer over the JDK: it knows nothing about Xtext, EMF, or the grammar

  • it is an ordinary library, which could be used (and tested) without the DSL
  • it speaks the language of the domain (in, at, period), not the one of the platform (ScheduledExecutorService)

• ShedulerTask has a private constructor and static factories named after the DSL keywords (in, at)

  • the generated code will read almost like the DSL script (see next slide)
  • at(...) turns an absolute time into a delay, computed when the task is created
  • a null entry point (it is optional in the DSL) is replaced by ShedulerTask.DEFAULT_ENTRYPOINT, i.e. /bin/sh -c

• scheduleAtFixedRate vs. scheduleWithFixedDelay: “repeat every 1 hours” means a fixed rate

  • i.e. a run starts every hour, regardless of how long the previous one took

• ProcessBuilder does not use a shell: the entry point (e.g. /bin/sh -c) must be split into separate arguments

  • otherwise the OS looks for an executable literally named “/bin/sh -c”

• executeAsync does not wait for the process to terminate

  • fine for independent tasks, not enough for dependencies (see Exercise 5)

Usage example

pool myPool {
    schedule task greetFrequently {
        command "echo hello"
        entry point "/bin/sh -c"
        in 5 minutes
        repeat every 1 hours
    }
    schedule task greetOnce {
        command "echo hello"
        entry point "/bin/bash -c"
        at 2030/10/11 12:13
    }
}
pool otherPool {
    schedule task shutdownAfter1Day {
        command "sudo shutdown now"
        entry point "/bin/zsh -c"
        in 1 days
    }
}

public static void main(String[] args) {
    ShedulerRuntime runtime = new ShedulerRuntime(
        Executors.newScheduledThreadPool(Runtime.getRuntime().availableProcessors()));
    pool_myPool(runtime);
    pool_otherPool(runtime);
}

private static void pool_myPool(ShedulerRuntime runtime) {
    ShedulerTask task0 = ShedulerTask.in("greetFrequently", "echo hello", "/bin/sh -c", Duration.parse("PT5M"));
    task0.setPeriod(Duration.parse("PT1H"));
    ShedulerTask task1 = ShedulerTask.at("greetOnce", "echo hello", "/bin/bash -c", LocalDateTime.parse("2030-10-11T12:13"));
    runtime.schedule(task0);
    runtime.schedule(task1);
}

private static void pool_otherPool(ShedulerRuntime runtime) {
    ShedulerTask task0 = ShedulerTask.in("shutdownAfter1Day", "sudo shutdown now", "/bin/zsh -c", Duration.parse("PT24H"));
    runtime.schedule(task0);
}

• Notice the structural correspondence: one method per pool, one variable per task, one statement per clause
• Times are converted at generation time into ISO-8601 literals (in 1 days $\rightarrow$ PT24H), parsed back at run time
• Java variables are named by position (task0, task1), as DSL names are optional and may clash with Java keywords

Exercise 4: write an interpreter for the Sheduler DSL

• No code generation, just a main (interpreter/ShedulerInterpreter.java, run via ./gradlew runInterpreter --args=...): parse and validate the DSL, convert each Task (model) into a ShedulerTask (engine), schedule it via ShedulerRuntime

  • the engine classes are the same ones used by the generated code (package runtime)

• Parsing, validation, and scheduling are given: the key part is writing toShedulerTask (see TODO Ex 4.*):

public class ShedulerInterpreter {
    public static void main(String[] args) {
        // checks args, then:
        Injector injector = new ShedulerStandaloneSetup().createInjectorAndDoEMFRegistration();
        injector.getInstance(ShedulerInterpreter.class).runFile(args[0]);
    }

    @Inject private Provider<ResourceSet> resourceSetProvider;
    @Inject private IResourceValidator validator;

    protected void runFile(String string) {
        // 1. parse: load the file as an EMF resource, whose root is the TaskPoolSet
        ResourceSet set = resourceSetProvider.get();
        Resource resource = set.getResource(URI.createFileURI(string), true);
        // 2. validate: warnings are printed, errors stop us
        List<Issue> issues = validator.validate(resource, CheckMode.ALL, CancelIndicator.NullImpl);
        issues.forEach(System.err::println);
        if (issues.stream().anyMatch(i -> i.getSeverity() == Severity.ERROR)) {
            return;
        }
        // 3. execute: turn each Task (model) into a ShedulerTask (runtime), then schedule it
        TaskPoolSet taskPools = (TaskPoolSet) resource.getContents().get(0);
        ShedulerRuntime runtime = new ShedulerRuntime(Executors.newScheduledThreadPool(Runtime.getRuntime().availableProcessors()));
        for (TaskPool pool : taskPools.getPools()) {
            for (Task task : pool.getTasks()) {
                runtime.schedule(toShedulerTask(task));
            }
        }
    }

    static ShedulerTask toShedulerTask(Task task) {
        throw new UnsupportedOperationException("TODO Ex 4.1: convert a Task (model) into a ShedulerTask (runtime)");
    }
}

Lecture is Over

Compiled on: 2026-10-15 — printable version

back to ToC