An Integrated Framework to Specify Domain-Speciﬁc Modeling

Languages

∗

Bahram Zarrin and Hubert Baumeister

DTU Compute, Technical University of Denmark, Kgs Lyngby, 2800, Denmark

Keywords:

Domain-Speciﬁc Modeling Languages, Formal Approach, Semantics Speciﬁcation, DSL-Tools, FORMULA.

Abstract:

In this paper, we propose an integrated framework that can be used by DSL designers to implement their de-

sired graphical domain-speciﬁc languages. This framework relies on Microsoft DSL Tools, a meta-modeling

framework to build graphical domain-speciﬁc languages, and an extension of ForSpec, a logic-based speciﬁ-

cation language. The drawback of MS DSL Tools is it does not provide a formal and rigorous approach for

semantics speciﬁcations. In this framework, we use Microsoft DSL Tools to deﬁne the metamodel and graphi-

cal notations of DSLs, and an extended version of ForSpec as a formal language to deﬁne their semantics.

Integrating these technologies under the umbrella of Microsoft Visual Studio IDE allows DSL designers to

utilize a single development environment for developing their desired domain-speciﬁc languages.

1 INTRODUCTION

Domain-speciﬁc modeling languages (DSMLs) are

specialized languages for a particular application

area, which use the concepts and notations establis-

hed in the ﬁeld. Therefore, they allow domain ex-

perts, who are usually non-programmers, to directly

employ their domain knowledge about what a system

under development should do. Domain-speciﬁc mo-

deling languages (DSMLs) not only increase the pro-

ductivity of the domain experts to specify a problem

domain in a manageable and analyzable way but also

improve the readability and understandability of the

problem speciﬁcations as well. Furthermore, they uti-

lize the domain rules as constraints to disallow the

speciﬁcation of illegal or incorrect models in the pro-

blem domain.

Since the development of DSMLs is expensive in

terms of time and cost, a proper framework can help

to reduce the development time and cost. There are

a number of language tools and frameworks to deve-

lop DSMLs such as EMF, MetaEdit+, MS DSL-tools,

Onion, Rascal, Xtext, SugarJ, and MPS. Most of these

tools and frameworks provide enough support for spe-

cifying the abstract and concrete syntax of DSMLs.

Based on these speciﬁcations, they automatically ge-

nerate graphical or textual editors with a set of IDE

∗

This research has been partially sponsored by the IR-

MAR project funded by Danish Council for Strategic Rese-

arch.

features, e.g. syntax coloring, synthetic compilation,

for the DSML under the development.

Abstract syntax and concrete syntax do not pro-

vide any information about what the concepts in a

language actually mean. Therefore, deﬁning the se-

mantics of a language is important in order to be clear

about what the language describes and means. If the

language semantics are not deﬁned clearly and preci-

sely, the language will be open to incorrect use and

misinterpretation. Therefore it is essential to capture

the semantics in a way that is precise and useful to

the user of the language. Formal methods provide the

required rigidity and precision for semantic speciﬁca-

tions (Gargantini et al., 2009). They provide an unam-

biguous and precise speciﬁcation of the language and

aid reasoning about the properties of the language by

utilizing the tools of mathematical logic. In addition,

formal speciﬁcations can facilitate an automated ge-

neration of language editors, interpreters, compilers,

debuggers and other related tools. Although most of

the aforementioned tools provide generative approa-

ches, e.g., model-to-model and model-to-text trans-

formation, to specify the semantics of DSMLs, they

do not provide a rigorous or formal approach for se-

mantics speciﬁcations.

In this paper, we propose an integrated framework

to formally specify the syntax and the semantics of

DSMLs. We combine MS DSL-Tools and an exten-

ded version of ForSpec (Simko et al., 2013), a logic-

based speciﬁcation language which is an extension of

Zarrin, B. and Baumeister, H.

An Integrated Framework to Specify Domain-Speciﬁc Modeling Languages.

DOI: 10.5220/0006555800830094

In Proceedings of the 6th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2018), pages 83-94

ISBN: 978-989-758-283-7

FORMULA (Jackson and Sztipanovits, 2009) deve-

loped at Microsoft Research, under the Visual Stu-

dio umbrella. This work is motivated by the lack of

supporting a formal approach by DSL Tools for spe-

cifying the semantics of the DSML proposed in an

experience paper (Zarrin and Baumeister, 2014).

Our work in this paper is inspired by the appro-

ach presented at (Lindecker et al., 2015). The aut-

hors utilize FORMULA for specifying the semantics

of DSMLs, and they provide a transformation tool

to convert metamodels and models speciﬁed within

Generic Modeling Environment (GME) (L

edeczi et

al., 2001) to FORMULA for analyzing the seman-

tics of the models. The drawback of their appro-

ach is switching between different programming tools

and development environments. In this paper, we

combine the aforementioned technologies under the

umbrella of Microsoft Visual Studio IDE to facili-

tate the development of DSMLs within a single en-

vironment. Furthermore, we employ our extension

of ForSpec instead of FORMULA that offers better

support for semantic speciﬁcations. We also provide

some language tools, as Visual Studio’s extensions

for ForSpec, such as code editor, command window,

and L

Xgenerator for pretty-printing speciﬁcations,

which has been used to generate the speciﬁcations

presented in this paper.

The remainder of this paper is organized as fol-

lows: in Sec. 2, we give a brief introduction to

domain-speciﬁc modeling languages, we also discuss

some of the approaches and existing formal langua-

ges for specifying the semantics of domain-speciﬁc

languages. Afterwards, in Sec. 3 and Sec. 4, we in-

troduce FORMULA and ForSpec. In Sec. 5, we pre-

sent our extension of ForSpec. Finally in Sec. 6, we

propose our integrated framework to design domain-

speciﬁc modeling languages, illustrated via an exam-

ple. We evaluate and conclude the paper in Sec. 7.

2 DOMAIN-SPECIFIC

MODELING LANGUAGES

Modeling languages, regardless of their general or

domain-speciﬁc nature, are formally deﬁned (Clark et

al., 2001) as a ﬁve-tuple: L =

A, C, S, M

, M

where

• A is the abstract syntax of the language.

• C is the concrete syntax of the language.

• S is the semantic domain of the language.

• M

is the mapping from concrete syntax to the

abstract syntax.

• M

is the mapping from abstract syntax to the se-

mantic domain.

The abstract syntax (A) deﬁnes the language con-

cepts, their relationships, and well-formlessness rules

that state how the concepts may be legally combined.

It is important to highlight that the abstract syntax of

a language is independent of the concrete syntax (C)

of the language. The syntax only deﬁnes the form

and structure of concepts in a language without dea-

ling with their presentation or meaning. The concrete

syntax (C) deﬁnes the notations that are used for re-

presenting programs or models. There are two main

types of concrete syntax; textual syntax and graphical

syntax. A textual syntax presents a model or program

in a structured textual form which typically consists of

a mixture of declarations and expressions. A signiﬁ-

cant advantage to them is their ability to capture com-

plex expressions. A graphical syntax presents a mo-

del or program as a diagram consisting of a number

of graphical icons and arrows that represent the mo-

del elements and their relationships. The main beneﬁt

of these is their ability of expressing a large amount

of details in an understandable and intuitive form.

The syntactic mapping, M

: C → A, provides a

realization of the abstract syntax, by mapping the ele-

ments of the concrete syntax to corresponding ele-

ments of the abstract syntax. The semantics of a lan-

guage are deﬁned by choosing a semantic domain S

and deﬁning a semantic mapping M

: A → S which

relates the concepts and terms of its abstract syntax to

corresponding elements of the semantic domain.

In contrast to traditional programming languages,

modeling languages are speciﬁed with the aid of me-

tamodels, which describe graph structures, therefore

instead of static semantics, they have structural se-

mantics (Chen et al., 2005). Similar to static seman-

tics, they deﬁne the well-formedness rules of the mo-

deling language, which categorize the model instan-

ces into well-formed or ill-formed models. Their be-

havioral semantics declares the dynamic behavior of

modeling languages as a mapping of the language’s

instances into a semantic domain that is rich enough

for capturing essential aspects of the execution beha-

vior of the modeling language (Chen et al., 2008).

The semantic domain and the semantic mapping can

be deﬁned by different approaches. We will discuss

some of them in detail in the following section.

2.1 Formal Approaches for Semantics

Speciﬁcations of Modeling

Languages

A number of formal approaches have been proposed

for specifying the semantics of modeling languages.

They can be classiﬁed into rewriting, weaving, and

translational approaches.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

In the rewriting approaches (Karsai et al., 2003;

Agrawal et al., 2004; Balasubramanian et al., 2007;

Wachsmuth, 2008), the behavior of a modeling lan-

guage is speciﬁed by a set of rewriting rules, which

deﬁne a mapping from the left-hand side of the rule

to its right-hand side. Matching a speciﬁcation phrase

with the left-hand side of a rule triggers substituting

it with the right-hand side of the rule. Substituting

ends when there are no more applicable rules. The

advantage of this approach is that the behavioral spe-

ciﬁcation is directly deﬁned in terms of the metamo-

del. This approach is more suitable for modeling lan-

guages where their behavior can be speciﬁed in the

operational semantic style.

In the weaving approaches (Montages, 2007;

Scheidgen and Fischer, 2007; Gargantini et al., 2009;

Ducasse et al., 2009; Mayerhofer et al., 2013), in-

spired from the UML action semantics (Semantics,

2001), the behavioral semantics of a modeling lan-

guage are speciﬁed directly in the metamodel of the

underlying language by attaching operations to the

meta-classes and employing a meta-language, e.g.

xOCL (Montages, 2007), QVT (QVT, 2008), for the

behavioral speciﬁcation of these operations. These

meta-languages are usually a set of primitive actions,

e.g. assignment, declaration, conditions, loops, and

object manipulations, to specify the behavior of the

language. The advantage of this approach is that syn-

tactical and semantical speciﬁcations of the language

are encapsulated. Its main drawback is that some of

these meta-languages are simpliﬁed versions of tradi-

tional programming languages. Therefore the seman-

tic speciﬁcations written with these languages have

the same complexity as the speciﬁcation written in

a conventional programming language (Gargantini et

al., 2009).

In the translational approaches (Chen et al., 2005;

Di Ruscio et al., 2006; Romero et al., 2007; Gar-

gantini et al., 2009; Sadilek and Wachsmuth, 2009;

Simko et al., 2012; Simko, 2014), the semantics of a

modeling language are speciﬁed as a mapping from

the metamodel of the underlying language to a meta-

model of another language which already has a wel-

lknown semantics, e.g. abstract state machines (Gu-

revich, 1995). The beneﬁt of this approach is that the

available tools of the target language can be used for

performing formal analysis. Its disadvantage is that

the DSL designer should have knowledge of the tar-

get language in order to specify and understand the

semantics of the underlying language.

The approach utilized in this paper is the continu-

ation of (Balasubramanian and Jackson, 2009; Simko

et al., 2012; Simko, 2014), in which the metamo-

del of the underlying modeling language is translated

into a formal speciﬁcation language, e.g. FORMULA

and ForSpec, and its behavioral semantics are speci-

ﬁed using the constructs of the speciﬁcation language.

Therefore, in the following, we describe these speci-

ﬁcation languages in more details.

3 FORMULA

FORMULA (Jackson et al., 2010) is a speciﬁca-

tion language based on Constraint Logic Program-

ming (Jaffar and Lassez, 1987; Fr

uhwirth et al., 1992)

which is the combination of the declarativity of logic

programming and the efﬁciency of constraint solving.

Each program in FORMULA consists of several

constructs called “module”s. Different kinds of mo-

dules are deﬁned in this language, of which the most

important ones are “domain”, “model”, and “trans-

form”. The domain module is a blueprint for a set

of models which are composed of type deﬁnitions,

data constructors, rules, and queries. The other mo-

dule called “model” is a model of a domain that con-

sists of a set of facts that are deﬁned through the

data constructors of the domain. Accordingly, given

a model and its related domain, FORMULA is able

to deduce a set of ﬁnal facts which provide the mini-

mum ﬁxed-point solution for the initial speciﬁcations

in the model. FORMULA leveraging Microsoft’s Z3

(e.g. an SMT solver), therefore, for any given partial

model i.e. a model with some underspeciﬁed facts

and a set of constraints, it can search for a solution

i.e. a completion of the model, where all the con-

straints are satisﬁed. If such a solution is not feasible,

it returns “unsatisﬁable” which indicates that the ex-

pected solution does not exist. FORMULA beneﬁts

from some important features; for example, bounded

model checking is supported, model ﬁnding tools are

provided, and ﬁnally FORMULA provides metamo-

dels and straightforward representation of models. It

has been used in several research works such as (Jack-

son and Sztipanovits, 2009; Jackson et al., 2009) to

specify the structural semantics of DSMLs. In addi-

tion, some core components of Windows 8.0, e.g. the

USB 3.0 stack, were built using DSLs speciﬁed with

this language (Jackson, 2014). In the following we

explain the notations of FORMULA, with some ex-

amples, that are used in this paper. A more detailed

description of this language can be found in (Jackson

et al., 2011; Jackson et al., 2010).

The “DirectedGraph” domain presented in the fol-

lowing example formalizes the metamodel of a sim-

ple directed graph language, and represents a model

of this domain. Two data types called “Node” and

“Edge” are used to specify the elements of the graph,

An Integrated Framework to Specify Domain-Speciﬁc Modeling Languages

and also a union type called “Element” is used to refer

to these elements.

domain DirectedGraph {

Node ::= new ( label : String ).

Edge ::= new ( src : Node, dst : Node ).

Element ::= Node + Edge.

conforms no { n.label | n : Node , m :

Node , n.label = m.label , m != n }. }

model simple graph of DirectedGraph {

node1 is Node ( "a" ).

node2 is Node ( "b" ).

edge1 is Edge ( node1 , node2 ).}

A query called “conforms” deﬁned at the end of

the domain deﬁnition guarantees the uniqueness of

the node’s labels in a graph. Queries are Boolean ex-

pressions that use the same constraint logic expressi-

ons as rules. Queries can also be deﬁned as conjuncti-

ons, disjunctions, and negations of other queries. The

“conforms” keyword denotes a special query that is

used to distinguish between the well-formed models

and ill-formed models of the domain.

Domain composition is supported by the “ex-

tends” and “includes” keywords. Both denote the in-

heritance of all types (data constructors and rules).

While “A extends B” ensures that all the well-formed

models of A are well-formed models of B, “A inclu-

des B” may contain well-formed models in A, which

are ill-formed models of B. The domains represented

in the following example formalize the metamodels of

a directed acyclic graph and a tree languages. These

domains illustrate how domains can be extended and,

particularly, how queries can be used in domains to

specify the structural semantics of these simple lan-

guages.

domain DAG extends DirectedGraph {

Path ::= ( Node , Node ).

Path ( u , w ) :- Edge ( u , w ) ; Edge ( u

, v ) , Path ( v , w ).

conforms no Path ( u , u ). }

domain Tree extends DAG {

conforms no { w | Edge ( u , w ) , Edge ( v

, w ) , u != v }. }

FORMULA supports relational constraints, such

as equality of ground terms, and arithmetic con-

straints over real and integer data types. A special

data type called Data in FORMULA refers to all the

data types deﬁned in the domain. The special sym-

bol “ ” denotes an anonymous variable that cannot be

referenced anywhere else.

FORMULA also supports model transformation

using transform modules. This module consists of ru-

les for deriving initial facts in an output model from

initial and derived facts in an input model as well as

input parameters. The rules are the same as they are in

domains, except that the left-hand side contains facts

in the output model and the right-hand side contains

facts from the input and output models. The trans-

form modules can also contain data constructors and

type declarations for transform-local derived facts and

union types. The following speciﬁcations transforms

a given graph to a complete graph by adding all the

possible edges between the given graph’s nodes.

transform Complete ( GraphIn :: DAG )

returns ( GraphOut :: DAG ) {

GraphOut.Node ( x ) :- GraphIn.Node ( x ).

GraphOut.Edge ( x , y ) :- GraphIn.Node ( x

) , GraphIn.Node ( y ) , x != y. }

Name-spaces are used for handling multiple deﬁ-

nitions with the same name in different ancestor dom-

ains. For example, domain “GraphIn :: DAG” uses

the name GraphIn for referring to elements of DAG.

We can refer to the elements of GraphIn by inserting

a dotted qualiﬁcation “GraphIn.” in front of the type

identiﬁers deﬁned in the domain.

4 ForSpec LANGUAGE

ForSpec is an extended version of FORMULA, pro-

posed by Gabor Simko (Simko, 2014) to support

the structural and behavioral semantics speciﬁcati-

ons of modeling languages for cyber-physical sys-

tems. ForSpec extends FORMULA with goal-driven

and functional terms, semantic functions and seman-

tic equations to provide support for operational, de-

notational and translational style speciﬁcations. For-

Spec also has been used to specify the denotational

semantics of a bond graph language, which is a phy-

sical modeling language (Simko et al., 2012), and to

specify the structural and behavioral semantics of a

cyber-physical system modeling language (Simko et

al., 2013). In the following, we brieﬂy introduce these

extensions. For a more detailed description of the lan-

guage see (Simko, 2014).

4.1 Functional Terms

Functions are very important in order to deﬁne com-

putations within any system. Despite this, a set of

function that mostly deﬁne the type of the relati-

ons between the data types (e.g. one-to-one, one-to-

many, and etc.) deﬁned within a domain, FORMULA

does not provide means to specify a function, e.g. a

function to sum up two numbers, as we know it in

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

other programming languages. The following speci-

ﬁcation is the conventional way to deﬁne a function

called Add. In this example, two data types “Add” and

“Add triger” are deﬁned. The ﬁrst data type speciﬁes

the input parameters and the output parameter of the

function as a three-tuple. The second data type speci-

ﬁes only the input arguments of the function. In addi-

tion, a rule is deﬁned to specify the computation. This

rule has a predicate to check if the function should be

computed. These speciﬁcations will be more compli-

cated if a function needs to use another function to do

a part of its computation.

domain Equation {

Add ::= (Integer, Integer, Integer).

Add trigger ::= (Integer, Integer).

Add (x, y, z) :- z = x + y, Add trigger (x,

y). }

ForSpec addresses this deﬁciency by introducing

functional terms. The function mentioned above can

be deﬁned in ForSpec as follows:

domain Equation {

Add ::= [Integer, Integer ⇒ Integer].

Add (x, y) ⇒ (z) :- z = x + y. }

Given these speciﬁcations, ForSpec automatically

generates the required data types and adds the requi-

red predicates to trigger the related rules. Therefore,

the above speciﬁcation will be converted into the fol-

lowing speciﬁcations by the ForSpec compiler (# is

a reserved character in ForSpec which is used by its

compiler).

Add ::= (Integer, Integer, Integer).

#Add ::= (Integer, Integer).

Add (x, y, z) :- z = x + y, #Add (x, y).

4.2 Semantic Functions

ForSpec introduces syntactic elements for deﬁning

semantic functions. The following example speciﬁes

a simple equation language and provides its denotati-

onal semantics by using a semantic function and a set

of semantic equations.

Exp ::= Plus + Mult + Minus + Real.

Mult ::= new ( lhs : Exp , rhs : Exp ).

Plus ::= new ( lhs : Exp , rhs : Exp ).

Minus ::= new ( lhs : Exp , rhs : Exp ).

E : Exp → Real.

E JPlusK = addition where addition =

E JPlus.lhsK + E JPlus.rhsK.

E JMultK = multiplication where

multiplication = E JMult.lhsK * E JMult.rhsK.

E JMinusK = subtraction where subtraction =

E JMinus.lhsK - E JMinus.rhsK.

The semantic function ﬁrst declares a data type

of the same name. Secondly, it creates rules for ex-

tracting information from the semantic functions. For

example, the semantic function “E : Exp − > Real”

declares a data type equivalent to “E ::= [Exp =>

Real]”, and the generated rules extract every possible

instant of the Exp over which the function ranges in a

concrete model (Simko, 2014).

4.3 Union Type Extension

Union types are supported well in ForSpec. This al-

lows extending the existing union type declarations

with additional data types. This is essential in the

modular development of modeling languages, since

it facilitates the language composition (Jackson and

Sztipanovits, 2009). The following example speciﬁes

a simple language for deﬁning arithmetic equations:

domain Equations {

Exp ::= Real + Operation.

Operation ::= BinOp + UniOp.

UniOp ::= Neg.

Neg ::= new (any Exp).

BinOp ::= Plus + Minus + Mult.

Plus ::= new (any Exp, any Exp).

Minus ::= new (any Exp, any Exp).

Mult ::= new (any Exp, any Exp). }

If we need to reuse this language and extend it to

support relational expressions, the extended domain

can be speciﬁed in ForSpec as follows:

domain AdvancedEquations extends Equations {

Exp += Boolean.

BinOp + = LT + LET + GT + GET + EQ + NotEQ.

LT ::= new (any Exp, any Exp).

LET ::= new (any Exp, any Exp).

GT ::= new (any Exp, any Exp).

GET ::= new (any Exp, any Exp).

EQ ::= new (any Exp, any Exp).

NotEQ ::= new (any Exp, any Exp).

UniOp += Not.

Not ::= new (any Exp). }

As presented in this example, we can extend Exp,

BinOp, and UniOp data types in the base domain with

the new data types introduced in the extended domain.

This is a useful feature in ForSpec which can help

avoid code duplication by using union type extension.

An Integrated Framework to Specify Domain-Speciﬁc Modeling Languages

5 EXTENDING ForSpec

ForSpec provides essential means for the structural

and behavioral speciﬁcations of DSMLs. However,

it has some limitations for specifying the semantics

of the DSML proposed in the experience paper (Zar-

rin and Baumeister, 2014). In this section, we address

these limitations and extend ForSpec to support these

deﬁciencies.

5.1 List Data Type

ForSpec does not support List data types explicitly.

The following example shows how a list can be deﬁ-

ned at the moment in ForSpec. It speciﬁes a domain

which includes a type called Substance and a list cal-

led SubstanceList. The elements of the list are the

type of Substance. A model is deﬁned as an instance

of this domain, and it describes three substances and

one list that includes them.

domain Material {

Substance ::= new (name:String, value:Real).

SubstanceList ::= new ( hd : Substance ,

tail : {SubstanceList + Nil}). }

model material of Material {

CH4 is Substance ("CH4", 0.23).

H2 is Substance ("H2", 2.44).

SubstanceList(H2, SubstanceList(CH4, Nil)).}

Although we are able to deﬁne a list structure im-

plicitly as above, this will require more effort when

we need to apply operations on the lists, e.g. add

elements, or remove elements. To this end, we ex-

tend ForSpec syntax to support List as a primitive data

type. The following example presents the same spe-

ciﬁcation as the example given above but using our

explicit list construct.

domain Material {

Substance ::= new (name:String, value:Real).

SubstanceList ::= list < Substance >. }

model material of Material {

CO is Substance ("CO", 0.23).

H2 is Substance ("H2", 2.44).

CH4 is Substance ("CH4", 1.03).

SubstanceList <CO, H2, CH4> }

The extension provides a syntactic sugar to expli-

citly deﬁne a list data type in ForSpec, and it trans-

fers the list data type in the ﬁrst speciﬁcations to the

equivalent speciﬁcation in the second speciﬁcations.

Therefore, head and tail of a list can be obtained by

accessing the structural ﬁelds of the list, e.g. “hd” and

“tail”. We also extend the built-in functions of For-

Spec with some list operation functions as follows:

• append (list1, list2): this function appends list1

and list2 and returns the result as a list.

• count (list): this function counts the number of

elements in the list.

• isin (element , list): this function indicates whet-

her or not the list contains the given element. It

can also provide information on whether or not

the list contains an item with the value of a par-

ticular ﬁeld of the item matches with the given

element. The syntax to do this is isin(element,

list[ﬁeld

name]). The following speciﬁcations

count the number of SubstanceList that contains

a Substance named “CO” in the model.

NoSubstanceListForCO ::= new ( Integer ).

NoSubstanceListForCO ( n ) :-

n = count ( { sl | sl is SubstanceList ,

isin ("CO", sl[name]) } ).

5.2 Set Comprehensions

Set comprehensions in ForSpec are deﬁned as {head |

body}, and they are used by built-in functions count

and toList. Count computes the number of elements

in the set and toList stores the items in the set in a list

data structure as presented earlier. We extend the to-

List function to accept the data type of the list as the

arguments. The extended function stores the elements

of the set comprehension in an instance of the given

list, and it uses constant value Nil to represents the end

of the list. For example, the following example spe-

ciﬁes a list of all the substances which have positive

values.

PositiveSubstance ::= new ( SubstanceList ).

PositiveSubstance (sl) :-

sl = toList ( SubstanceList , { s | s is

Substance , s.value > 0 } ).

Furthermore, we also extend ForSpec by provi-

ding syntax to iterate the list elements within set com-

prehensions. This extension allows ForSpec to sup-

port some list operations, e.g. ﬁlter(), map(), and re-

duce(), which are quite useful in functional program-

ming. The following speciﬁcations deﬁnes a function

that rescales a SubstanceList. It maps each element of

a given SubstanceList to the rescaled element in the

list, called result. The list iterator is deﬁned as e ← sl

where sl is the given list, and e is a variable represen-

ting an element of the list.

RescaleSubstanceList ::= [ SubstanceList ,

Integer ⇒ SubstanceList ].

RescaleSubstanceList (sl, n) ⇒ (result) :-

result = toList (SubstanceList,

{Substance(e.name, e.value * n) | e ← sl}).

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

Given the above speciﬁcations, the extension au-

tomatically generates a data type called #iterator and

the required rules to iterate the list elements. There-

fore, the following speciﬁcations present the ForSpec

translation of the given example:

RescaleSubstanceList ::= [ SubstanceList ,

Integer ⇒ SubstanceList ].

RescaleSubstanceList (sl , n) ⇒ (result):-

result = toList(SubstanceList,

{Substance(e.name, e.value * n) |

#iterator 0x0 (e , )}).

#iterator 0x0 ::= new ( value : Substance ,

seq : SubstanceList ).

#iterator 0x0 ( sl.hd , sl.tail ) :-

#iterator 0x0 ( , sl ) , sl != Nil.

#iterator 0x0 ( sl.hd , sl.tail) :-

#RescaleSubstanceList ( sl , ).

We also provide support for union and intersection

operators for the set comprehensions. The following

example speciﬁes a function that merges two sub-

stance lists.

MergeSubstanceList ::= [SubstanceList ,

SubstanceList ⇒ SubstanceList + {Nil}].

MergeSubstanceList ( l1 , l2 ) ⇒ ( l3 ) :-

l3 = toList ( SubstanceList ,

{ Substance ( e1.name , e1.value + e2.value

) | e1 ← l1 , e2 ← l2 , e1.name = e2.name}

union {e1 | e1 ← l1 , e1.name 6∈ l2[name]}

union {e2 | e2 ← l2 , e2.name 6∈ l1[name]}).

5.3 Reduce Function

In functional programming, reduce refers to a

function that operates on a list or any recursive data

structure to collapse or accumulate its elements into a

single element or value by applying the same compu-

tation to each element. In this work, we extend For-

Spec to be able to specify the reduce function.

The following example deﬁnes a reduce function

called MergeSubstanceLists to aggregate the substan-

ces of a list of SubstanceList:

SubstanceLists ::= list < SubstanceList >.

MergeSubstanceLists ::= [SubstanceLists >>

MergeSubstanceList >> SubstanceList].

The following example deﬁnes a reduce function

called Sum to calculate the sum of the numbers in the

given list:

NumberList ::= list <Real>.

Add ::= [ Real , Real ⇒ Real ].

Add ( x , y ) ⇒ ( z ) :- z = x + y.

Sum ::= [ NumberList >> Add >> Real].

5.4 Typed Union Type

FORMULA and ForSpec allow us to freely combine

different types e.g. built-in types, composite types,

and union types. The current limitation is that they

do not provide any mechanism to deﬁne constraints

on the components of a union type. This is essen-

tial when a union type should be extended from other

domain modules by using union type extension, since

any arbitrary types can be added to the components

of the union type. For instance, in the Equations ex-

ample the BinOp union type can be extended in the

extended domain by any type, which may not be a bi-

nary operation anymore. Therefore, we need to spe-

cify that any binary operator should have at least a

left and right ﬁelds of type Exp. To support this, we

introduce a new built-in type to ForSpec that allows

deﬁning a type for the union types. This data type can

be considered as the equivalent of interfaces in object

oriented paradigm.

The syntax to deﬁne a typed union is the same

as the syntax to deﬁne a composite type. The main

difference is using “:;=” instead of “::=”. This helps

us to distinguish between the deﬁnition of these two

built-in types. A typed union is a particular union type

which can declare the new keyword and a set of na-

med ﬁelds. It enforces a set of type checking rules to

ensure that all of the components of the typed union

match this common declaration. The rules of the type

checking is as follows:

• If the typed union has the new keyword in its deﬁ-

nition, then all of its components should have the

new keyword in their declaration.

• All the ﬁelds deﬁned in the typed union deﬁnition

should have a unique name.

• For each ﬁeld speciﬁed in the typed union declara-

tion, all the components of the typed union should

have the same ﬁeld with the same type (not neces-

sarily the same order) in their declaration.

Union type extension “+=” can be used to add a

type component to a typed union type. It can be used

both within the same domain that contains the decla-

ration or within other domains modules extending the

domain.

A typed union type cannot be used to generate a

fact either via rules or constructors within a model of

a domain. But its signature can be used as a compo-

site type to match the facts of the type of its compo-

nents in the knowledge base of the ForSpec interpre-

ter. There is a difference between matching a compo-

site type and a typed union type. For the composite

type, the matching is done by comparing the argu-

ments of the fact and matching terms in the sequence,

An Integrated Framework to Specify Domain-Speciﬁc Modeling Languages

and comparing the type of the fact with the type of

matching term. While in the typed union the argu-

ment matching is done according to the name of the

ﬁelds and not their position in the constructor (same

ﬁelds should have the same value and the type mat-

ching is done according to the type of component.

The following example utilizes a typed union type

to deﬁne an interface for a type of Component. This

type has been extended with a type of Network using a

union type extension operator in another domain cal-

led “Network”. The typed union type is also used to

match the facts of the type of Component to check if

they have ports with duplicated name.

domain Core {

InPort ::= new (id: String, type: String).

OutPort ::= new (id: String, type: String).

Port ::= InPort + OutPort.

PortList ::= list < Port >.

Component :;= new (id: String, ports:

PortList).

...

InvalidComponent ::= ( String ).

InvalidComponent ( id ) :-

Component ( id , ports ),

no { x | x ← ports , y ← ports , x != y ,

x.id = y.id }. }

domain Network extends Core {

Component += Network.

Network ::= new ( id : String , ports :

PortList, ... ).

... }

6 INTEGRATION WITH

MICROSOFT DSL TOOLS

The Visualization and Modeling Software Develop-

ment Kit (VMSDK) is a meta-modeling framework to

build powerful graphical domain-speciﬁc languages

that can be integrated into Microsoft Visual Studio.

The core of Visualization and Modeling Software De-

velopment Kit (VMSDK) is a DSL deﬁnition diagram

for specifying both the metamodel and the graphical

notations of a domain-speciﬁc language. The deﬁni-

tion diagram is used by the framework to generate a

graphic editor for the VMSDK, so that modelers can

edit and view the whole or parts of the model, seriali-

zation objects which store the models in XML for-

mat, model transformation commands, mechanisms

for generating code or other artifacts from the mo-

del by using text templates, customized Visual Studio

Shell, and APIs to interact with the shell (Microsoft,

2014).

In this paper, we use a simple example to explain

Expression

Subtract

Multiple

Sum

Binary Operator

Constant

Value : Real

Input

Value : Real

Output

DataFlowGraph

Name

Element

Name : String

0 - n

1 exp

1 right

1 left

Figure 1: Metamodel of a simple data ﬂow language.

the integration of these tools. More complex DSLs,

e.g., domain speciﬁc language for modeling waste

management systems, developed within this frame-

work can be found in (Zarrin, 2016).

Figure 1 presents the metamodel of a simple data-

ﬂow language. This language is composed of input,

output, constant, and three binary operators including

sum, multiply, and subtract. By this simple language,

a modeler can specify the computation of a simple

arithmetic expression, e.g. Z = 5 ∗ X + 6 ∗ Y. In the

following, we brieﬂy introduce MS DSL Tools and

specify the metamodel and concrete syntax of this

language. Afterwards, we explain our approach for

transferring the metamodel and the models of this lan-

guage to ForSpec speciﬁcation. At the end, we pro-

vide an operational semantics of this language.

6.1 Deﬁning the Proposed DSL

The DSL deﬁnition diagram for the proposed DSL in

Visual Studio is illustrated in Figure 2. The diagram

has two swim lanes, one of which is used to show the

domain classes and their relationships (abstract syn-

tax) and the other of which is used to show the dia-

gram notations (concrete syntax). The domain classes

are used to deﬁne the model elements and the domain

relationships are used to deﬁne the relationships bet-

ween the elements. The appearance of the model ele-

ments in the diagram is deﬁned by using shape classes

and connectors.

Domain classes can be deﬁned as abstract or non-

abstract classes, and they can be inherited from each

other to deﬁne the model elements. Model elements

can be linked to each other by using relationships.

These links are binary and they precisely connect two

elements of the model, while each element of the mo-

del can be linked to multiple elements. There are two

different kinds of domain relationships; embedding

relationships and reference relationships.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

Figure 2: DSL deﬁnition diagram for a simple data ﬂow language.

As presented in Figure 2, a domain class called

DataFlowGraph is used as the root element of the

diagram representing the language. An embedded

relationship, representing the composite relationship

in the metamodel, is deﬁned from the root element

to an abstract domain class called Element, which is

the base class of all of the model elements. Accor-

ding to the metamodel presented in Figure 1, the ot-

her domain classes are deﬁned and inherited from the

Element class. The left and right relationship of the

An Integrated Framework to Specify Domain-Speciﬁc Modeling Languages

binary operators and the exp relationship of the out-

put elements are deﬁned as reference relationships,

which provide connectivity between the model ele-

ments. Finally, for all of the non-abstract domain

classes, which should appear as an element in the

DSL diagram, a shape class is deﬁned to describe the

concrete syntax of the element in the model diagram.

6.2 Generating ForSpec Speciﬁcations

VMSDK generates code for domain classes, connec-

tors, shapes, diagram editor, model explorer, valida-

tions, and other artifacts based on the DSL deﬁnition

ﬁle (.dsl). The code generation is done by using a set

of text templates ﬁles (.tt) located in a folder, within a

DSL project, called Generated Code.

We use the same method to generate ForSpec

speciﬁcations for the metamodel speciﬁed within the

DSL deﬁnition ﬁle and its corresponding models. To

this end, we extend the DSL project template to in-

clude two additional text template ﬁles in the Genera-

ted Code folder, for whenever DSL developers create

a new DSL project. These text template ﬁles, along

with the other templates located in the folder, rege-

nerate the required code automatically whenever the

DSL deﬁnition ﬁle is changed. One of these ﬁles is

used to generate the ForSpec speciﬁcation for the me-

tamodel of the DSL. This template directly generates

a ForSpec ﬁle (.4sp) which contains a domain module

equivalent to the metamodel. Therefore, the speciﬁ-

cations are available at the design time of the DSL,

and the DSL developer can extend these speciﬁcati-

ons with the DSL semantics. The following ForSpec

speciﬁcation is generated for the metamodel of the

language deﬁned in the DSL deﬁnition diagram pre-

sented in Figure 2.

domain SimpleLanguage {

DataFlowGraph::= new (Elements:ElementList).

Element :;= new (name: String).

Element += Output + Expression.

Input ::= new (value:Single, name:String).

Output ::= new (name: String, Expression:

Expression).

Constant::= new (value:Single, name:String).

Expression :;= new (name: String).

Expression += Input + Constant +

BinaryOperator.

BinaryOperator :;= new (name: String, Left:

Expression, Right: Expression).

BinaryOperator += Sum + Multiple + Subtract.

Sum ::= new (name: String, Left:

Expression, Right: Expression).

Multiple ::= new (name: String, Left:

Expression, Right: Expression).

Figure 3: A a model to compute Z = 6 ∗ Y + 5 ∗ X.

Subtract ::= new (name: String, Left:

Expression, Right: Expression).

ElementList ::= list < Element >. }

The ForSpec speciﬁcation is generated according

to the following procedures: For each non-abstract

domain class ( e.g. Sum), a data type with the same

name will be generated. The parameters of the data

type include all the domain properties explicitly de-

ﬁned for the domain class and its base classes (e.g.

name are deﬁned in the Element domain class). In ad-

dition, for each domain relationship with which their

source is associated, the domain class or its base clas-

ses (e.g. the Left and Right domain relationship as-

sociated to the BinaryOperator), a parameter will be

generated. The type of parameter is deﬁned accor-

ding to the multiplicity of the relationship. For one

to one relationships, the type is the same as the type

of the domain class associated with the target of the

relationship. For the one to many relationships, the

type is deﬁned as a list of the type of the domain class

targeting the relationship. For each abstract class (e.g.

Element), depending on its domain properties, a union

type or a typed union type is generated. The ﬁrst is

generated if the class does not have any domain pro-

perty. The later is generated if the class or its base

class has one or more domain properties. In both ca-

ses, the classes inherited from the abstract class are

added to the union deﬁnition.

The other template is used for generating ForSpec

speciﬁcations for the model instances of the DSL. To

this end, it generates, e.g. C#, VB, code for an adapter

that can transfer the model instances of the DSL to

ForSpec. This adapter can be used by applications or

within another text template ﬁle in Visual Studio IDE.

Figure 3 illustrates a concrete model of the language,

designed with the diagram editor of the language, to

model Z = 6 ∗Y + 5 ∗ X. The following speciﬁcations

are produced for this model by the adapter generated

for the language.

model simple exp of SimpleLanguage {

Constant1 is Constant (5, "Constant1").

Constant2 is Constant (6, "Constant2").

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development

X is Input (5, "X").

Y is Input (2, "Y").

Multiple1 is Multiple ("Multiple1",

Constant1 , X ).

Multiple2 is Multiple ("Multiple2",

Constant2 , Y).

Sum1 is Sum ("Sum1", Multiple2, Multiple1).

Z is Output ("Z", Sum1).

DataFlowGraph (ElementList<Constant1,

Constant2, Y, Multiple1, X, Sum1, Multiple2,

Z>). }

To make this language executable, we extend the

domain with the semantic speciﬁcations. For this ex-

ample, we ﬁrst deﬁne a semantic domain for the lan-

guage, which has a data type and the required functi-

ons over this data type. Then, we use denotational se-

mantics to specify the mapping from the syntactic ele-

ments to the semantic elements. Although we could

use integer as the semantic domain here, we choose

to use a simple semantic domain to show the general

approach.

domain ExecutableSimpleLanguage extends

SimpleLanguage {

// Semantic domain :

SD ::= Mult + Add + Sub + Val.

Val ::= new (Integer).

Mult ::=[ Val , Val ⇒ Val ].

Mult ( Val ( a ) , Val ( b ) ) ⇒ ( Val ( c

) ) :- c = a * b.

Add ::=[ Val , Val ⇒ Val ].

Add ( Val ( a ) , Val ( b ) ) ⇒ ( Val ( c )

) :- c = a + b.

Sub ::= [ Val , Val ⇒ Val ].

Sub ( Val ( a ) , Val ( b ) ) ⇒ ( Val ( c )

) :- c = a - b.

// Semantics functions :

G : DataFlowGraph → SD.

E : Element → SD.

G JDataFlowGraphK = value where

e ← DataFlowGraph.Elements , e : Output

, E JeK = value.

E JConstantK = Val (Constant.value).

E JInputK = Val (Input.value).

E JOutputK = value where

E JOutput.ExpressionK = value.

E JSumK = value where

E JSum.LeftK = l , E JSum.RightK = r , Add (

l , r ) ⇒ (value).

E JSubtractK = value where

E JSubtract.LeftK = l , E JSubtract.RightK =

r , Sub ( l , r ) ⇒ (value).

E JMultipleK = value where

E JMultiple.LeftK = l , E JMultiple.RightK =

r , Mult ( l , r ) ⇒ (value). }

According to the given semantics and the metamo-

del, we can execute the given model in ForSpec. The

result of the expression speciﬁed in the model is com-

puted by the semantic function G which is evaluated

to 37 for the expression.

7 CONCLUSIONS

The integrated framework presented in this paper can

be used to specify graphical domain-speciﬁc langua-

ges. In this framework, DSL Tools are used to for-

mally deﬁne the concrete syntax and ForSpec is used

to specify the semantics of domain-speciﬁc langua-

ges. We extended ForSpec with list datatypes, union

operators, iterators, map and reduce functions, and

typed union datatype which helps write more com-

plicated speciﬁcations within the language. We com-

bined ForSpec with Microsoft DSL Tools under the

umbrella of Microsoft Visual Studio IDE. This allows

DSL designers to utilize a single development envi-

ronment to develop their desired domain-speciﬁc lan-

guages. Since we developed this framework based on

existing technologies and languages, the users do not

need to learn new programming languages or tools to

develop DSLs.

One of the drawbacks of function calls in ForSpec

is that it executes functions through a set of rules,

which means that for each call it adds the facts ge-

nerated during the execution to the knowledge-base.

These facts will stay there forever, even after the

function returns. This makes the execution slower and

slower after each function call, due to increasing the

number of facts in the knowledge-base. This could be

addressed by proposing a mechanism which allows to

remove facts from the ForSpec’s knowledge-base.

The integrated framework presented in this paper

is not suitable for developing none graphical DSLs.

Combining this framework with other language deve-

lopment tools for developing textual languages such

as Microsoft Irony is our future work.

REFERENCES

Agrawal, A., Simon, G., and Karsai, G. (2004). Semantic

translation of simulink/stateﬂow models to hybrid au-

tomata using graph transformations. Electronic Notes

in Theoretical Computer Science.

Balasubramanian, D. and Jackson, E. K. (2009). Lost in

translation: Forgetful semantic anchoring. In Pro-

ceedings of the 2009 IEEE/ACM International Confe-

An Integrated Framework to Specify Domain-Speciﬁc Modeling Languages

rence on Automated Software Engineering, ASE ’09.

IEEE Computer Society.

Balasubramanian, D., Narayanan, A., van Buskirk, C., and

Karsai, G. (2007). The graph rewriting and transfor-

mation language: Great. Electronic Communications

of the EASST.

Chen, K., Sztipanovits, J., Abdelwalhed, S., and Jackson, E.

(2005). Semantic anchoring with model transformati-

ons. In Model Driven Architecture–Foundations and

Applications. Springer.

Chen, K., Sztipanovits, J., and Neema, S. (2008). Compo-

sitional speciﬁcation of behavioral semantics. In De-

sign, Automation, and Test in Europe, pages 253–265.

Springer Netherlands.

Clark, T., Evans, A., Kent, S., and Sammut, P. (2001). The

MMF Approach to Engineering Object-Oriented De-

sign Languages. In Proceedings of the First Works-

hop on Language Descriptions, Tools and Applicati-

ons, LDTA 2001. Middlesex University.

Di Ruscio, D., Jouault, F., Kurtev, I., B

ezivin, J., and Pie-

rantonio, A. (2006). Extending amma for supporting

dynamic semantics speciﬁcations of dsls. Technical

report, LINA Research Report.

Ducasse, S., Girba, T., Kuhn, A., and Renggli, L.

(2009). Meta-environment and executable meta-lang-

uage using smalltalk: an experience report. Software

& Systems Modeling, 8(1):5–19.

uhwirth, T., Herold, A., K

uchenhoff, V., Le Provost, T.,

Lim, P., Monfroy, E., and Wallace, M. (1992). Con-

straint logic programming. Springer.

Gargantini, A., Riccobene, E., and Scandurra, P. (2009). A

semantic framework for metamodel-based languages.

Automated Software Engineering, 16(3-4):415–454.

Gurevich, Y. (1995). Evolving algebras 1993: Lipari guide.

Speciﬁcation and validation methods, pages 9–36.

Jackson, E., Porter, J., and Sztipanovits, J. (2009). Seman-

tics of domain speciﬁc modeling languages. Model-

Based Design of Heterogeneous Embedded Systems.

Jackson, E. and Sztipanovits, J. (2009). Formalizing the

structural semantics of domain-speciﬁc modeling lan-

guages. Software and Systems Modeling, 8(4).

Jackson, E. K. (2014). A module system for domain-

speciﬁc languages. Theory and Practice of Logic Pro-

gramming, 14(4-5).

Jackson, E. K., Bjørner, N., and Schulte, W. (2011). Ca-

nonical regular types. ICLP (Technical Communicati-

ons).

Jackson, E. K., Kang, E., Dahlweid, M., Seifert, D., and

Santen, T. (2010). Components, platforms and possi-

bilities: towards generic automation for mda. In Pro-

ceedings of the tenth ACM international conference

on Embedded software. ACM.

Jaffar, J. and Lassez, J.-L. (1987). Constraint logic pro-

gramming. In Proceedings of the 14th ACM SIGACT-

SIGPLAN Symposium on Principles of Programming

Languages, POPL ’87, pages 111–119. ACM.

Karsai, G., Agrawal, A., Shi, F., and Sprinkle, J. (2003).

On the use of graph transformation in the formal spe-

ciﬁcation of model interpreters. Journal of Universal

Computer Science, 9(11).

edeczi,

A., Bakay, A., Maroti, M., Volgyesi, P., Nord-

strom, G., Sprinkle, J., and Karsai, G. (2001). Compo-

sing domain-speciﬁc design environments. Computer,

34(11):44–51.

Lindecker, D., Simko, G., Levendovszky, T., Madari, I., and

Sztipanovits, J. (2015). Validating transformations for

semantic anchoring. Journal of Object Technology.

Mayerhofer, T., Langer, P., Wimmer, M., and Kappel, G.

(2013). xMOF: Executable DSMLs Based on fUML.

Springer International Publishing.

Microsoft (2014). Visualization and Modeling SDK

— Domain-Speciﬁc Languages. http://msdn.

microsoft.com/en-us/library/bb126259.aspx.

Montages (2007). xocl: executable ocl.

QVT (2008). Omg. mof 2.0 query/view/transformation

(qvt). OMG Document - formal/08-04-03.

Romero, J. R., Rivera, J. E., Dur

an, F., and Vallecillo, A.

(2007). Formal and tool support for model driven en-

gineering with maude. Journal of Object Technology.

Sadilek, D. and Wachsmuth, G. (2009). Using grammar-

ware languages to deﬁne operational semantics of mo-

delled languages. In International Conference on Ob-

jects, Components, Models and Patterns, pages 348–

356. Springer.

Scheidgen, M. and Fischer, J. (2007). Human comprehensi-

ble and machine processable speciﬁcations of opera-

tional semantics. In Proceedings of the 3rd European

Conference on Model Driven Architecture Foundati-

ons and Applications. Springer-Verlag.

Semantics, A. (2001). The action semantics consortium for

the uml. OMG Document - formal/2001-03-01.

Simko, G. (2014). Formal Semantic Speciﬁcation of

Domain-Speciﬁc Modeling Languages for Cyber-

Physical Systems. PhD thesis, Vanderbilt University.

Simko, G., Levendovszky, T., Neema, S., Jackson, E.,

Bapty, T., Porter, J., and Sztipanovits, J. (2012).

Foundation for model integration: Semantic back-

plane. In ASME 2012 International Design Engineer-

ing Technical Conferences and Computers and Infor-

mation in Engineering Conference. American Society

of Mechanical Engineers.

Simko, G., Lindecker, D., Levendovszky, T., Neema,

S., and Sztipanovits, J. (2013). Speciﬁcation of

cyber-physical components with formal semantics–

integration and composition. In Model-Driven Engi-

neering Languages and Systems. Springer.

Wachsmuth, G. (2008). Modelling the operational seman-

tics of domain-speciﬁc modelling languages. In Ge-

nerative and Transformational Techniques in Software

Engineering II. Springer.

Zarrin, B. (2016). Domain Speciﬁc Language for Modeling

Waste Management Systems. PhD thesis, Technical

University of Denmark.

Zarrin, B. and Baumeister, H. (2014). Design of a domain-

speciﬁc language for material ﬂow analysis using mi-

crosoft dsl tools: An experience paper. In Proceedings

of the 14th Workshop on Domain-Speciﬁc Modeling,

DSM ’14, pages 23–28. ACM.

MODELSWARD 2018 - 6th International Conference on Model-Driven Engineering and Software Development