Defining DSLs for modeling and simulation can be cumbersome, especially in the case of divergent evolution between the language specification and the underlying meta-model.

The MOODs framework (short for Modeling and OO Design for Simulation) leverages MOGs, ASL and GrammarTraits to describe both the language and the underlying model via Blueprints, Domains and Modelers. These abstractions ease the work of DSL designers and domain experts, keeping both the DSL and its meta-model in sync by construction.

Moreover MOODs allows for both structural and value-level validation of the compiled models, incorporating model-checking in the very definition of DSLs.

For showcasing MOODs we have ported and enhanced a subset of the Geranium DSL currently in use in Computational Geography (see a live session of the Geranium system here).


Our first example from Urban Geography defines the statistical characteristics of an urban area and its building profiles. These are used in an energy-consumption simulation under various urban conditions (structural, sociological, climatological etc). Here is a small subset of the language inside Lan.d.s:


Note that in this computational domain, geographical coordinates and statistical distributions (normal, categorical, uniform etc) are so frequently used in the models that defining specific syntax, semantics and validation for them is warranted:


The Geranium DSL is defined in Lan.d.s thourgh 3 key abstractions: Domains, Blueprints and Modelers. Here are their definitions and their relationship with what we have seen so far (in terms of GrammarTraits, Parsers and Recognizers):

Parsing MOODs Description
MOG GrammarTrait Blueprint A Blueprint is a GrammarTrait that describes a DSL entitiy. It allows annotating MOG Rules with meta-model descriptions about state
ASL GrammarTrait BlueprintModeler A BlueprintModeler is a GrammarTrait that allows annotating parsing actions of DSL entities, with model validation methods
Recognizer Domain A Domain is a Recognizer of a DSL comprised of one or several Blueprints
Parser DomainModeler A DomainModeler is a Parser for a DSL comprised of one or several BlueprintModelers. It parses the DSL into models conforming to an automatically generated meta-model from its description

From the above definitions note the extention of GrammarTraits to allow for state and validation annotations, plus the ability of the DomainModeler to automatically generate the meta-model from the annotated descriptions. These two features allow MOODs to keep both the DSL and its meta-model in sync by construction (since they are both generated from a single source), while incorporating model-checking in the very definition of the DSLs through the Blueprint annotations.

Here are the definitions of GeoDomain and GeoModeler for Geranium:

moodsDomainsBlueprintsGeo moodsDomainsModelersGeo

as we saw above the Domain and DomainModeler of our DSLs comprise of one or more Blueprints and BlueprintModelers. Since these are GrammarTraits (extented with state and validation annotations) any conflicts arising from the composition can be easily handled through Trait operators.

Let’s now have a closer look at the Blueprint defining the StatScenario entity of Geranium and especially the rule describing coordinates:


Here you can see in its simplest form a state annotation (marked by the leading @) for the MOG rule of the coordinates parameter. This annotation will later inform the modeler that the rule is describing part of the state of the resulting meta-model. Thus all intermediate values resulting from evaluating the action of this rule will be further processed and stored.

In the BlueprintModeler of the StatScenarion entity now, we can find a keyword method of the same name (ie coordinates: cDict) in addition to the normal ASL actions for the rule:


The existance of this keyword method (using the same name as the annotated MOG Rule) signals to the DomainModeler the need to further validate any intermediate values produced by the rule, using the logic described by the method. In this particular case the method validates that coordinates are within the accepted ranges for longitude (-180.0 to 180.0) and latitude (-90.0 to 90.0) on top of being consistent (North > South and East > West).

Similary for the UrbanProfile entity of the DSL, we define a Blueprint and BlueprintModeler with state and validation annotations. Here is for e.g. the definition of the surface parameter:


and its accompanying validation for statistical distributions (normal and uniform):


Making sure that ranges, averages and standard deviations of the defined distributions are mutually consistent.

Repeating this process for all entities and parameters of our DSL is all we need ! No need for a seperate definition and validation of the meta-model. MOODs will keep both the DSL and its meta-model in sync by construction (since they are both generated from a single source), while incorporating model-checking in the very definition of the language.