LCL

A Graphical Meta-Language for Speciﬁcation of Language Constraints

Terje Gjøsæter

Department of ICT, University of Agder, Grimstad, Norway

Keywords:

Meta-languages, Meta-modelling, Language Constraints.

Abstract:

The Object Constraint Language (OCL) is commonly used for constraints in meta-model-based language spec-

iﬁcations. However, it may be advantageous to have a domain-speciﬁc constraint meta-language optimised for

language speciﬁcations. A survey of OCL usage in language speciﬁcations has been performed, in order to

gain an understanding of common constraint patterns. This is used as a starting point for deﬁning a new

meta-language for language constraints, Language Constraint Language (LCL), that has an intuitive graphical

syntax.

1 INTRODUCTION

There has recently been much focus on domain-

speciﬁc languages (DSLs) - computer languages fo-

cusing on a particular problem domain, that can be

rapidly created and deployed (Kelly and Tolvanen,

2008). This puts strong demands on the efﬁciency and

usability of tools and technologies for creating com-

puter languages. A popular approach is to generate

language tools from language speciﬁcations. Com-

puter language speciﬁcations are (more or less) for-

mal and complete descriptions of a computer lan-

guage. They can be used as blueprints for manually

developing tools for handling the language, or if a

speciﬁcation is sufﬁciently formal and complete, it

may be used for automatically generating language

tools. These tools may for example be code or dia-

gram editors, and interpreters, compilers or code gen-

erators for executing the statements in the language

instance or transforming them into executable form.

There are different approaches to creating tools for

computer languages. Compiler theory concerns de-

veloping compilers, i.e. tools for turning a language

instance into another (usually executable) form. It

has its strength in deﬁning optimised compilers for

large textual general purpose languages. On the other

hand, the focus among language designers is shifting

towards creating small DSLs. These languages may

have a graphical or textual presentation (concrete syn-

tax), and they are often based on existing languages

and may be preprocessed / embedded / transformed

into other languages for execution, instead of being

compiled with a traditional compiler. This new trend

requires new approaches, therefore speed of tool de-

velopment and agile approaches to language develop-

ment are increasingly important. Model-driven ar-

chitecture (MDA) is a general modelling approach,

that also has some advantages when it comes to deﬁn-

ing DSLs. An important advantage of MDA for lan-

guage development is that it provides the language de-

signer with support for rapid development and auto-

matic prototyping of language support tools, and al-

lows for working on a high level of abstraction. This

approach allows the language designer to focus on the

language being developed, while still being able to

use the deﬁnition for generating tools such as editors,

validators and code generators.

Following the MDA approach to language devel-

opment, it is important that the technologies used are

well suited to the language development domain, and

that they allow the language designer to operate on

a high level of abstraction. In the following sec-

tions, we will examine technologies that are being

used for deﬁning constraints in language speciﬁca-

tions, and in particular the most commonly used of

these that is the Object Constraint Language (OCL)

(OMG, 2005). Based on our ﬁndings on the usage

of constraints in language speciﬁcations, we will pro-

pose an alternative approach to deﬁning constraints

that is customised for language design.

The rest of the article is organised as follows: Sec-

tion 2 covers general background of language speci-

ﬁcation, and Section 3 covers constraints in more de-

tail. In section 4, we describe a survey on usage of

329

Gjøsæter T..

LCL - A Graphical Meta-Language for Speciﬁcation of Language Constraints.

DOI: 10.5220/0005250603290337

In Proceedings of the 3rd International Conference on Model-Driven Engineering and Software Development (MODELSWARD-2015), pages 329-337

ISBN: 978-989-758-083-3

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

constraints in language speciﬁcations, that leads to

two different candidate approaches for deﬁning a new

language constraints language. In section 5, we pro-

pose an alternative approach for handling language

constraints; and in sections 6, the beneﬁts and limita-

tions of the proposed language are discussed. Related

work is discussed in 7, and ﬁnally 8 contains a sum-

mary of the article as well as plans for future work.

2 LANGUAGE SPECIFICATION

There are different ways to divide the aspects of a

language speciﬁcations. In traditional compiler the-

ory, we often refer to concrete and abstract syntax,

and static and dynamic semantics. In meta-modelling,

the structural aspect is often referred to as the meta-

model, and we may ﬁnd cases where the term meta-

model also include other language aspects like con-

straints. In (Nytun et al., 2006), a language deﬁni-

tion is said to consist of the following aspects: Struc-

ture, Presentation and Behaviour, and we also include

Constraints and Mapping for completing the picture.

Structure deﬁnes the constructs of a language and

how they are related. This language aspect is often

named abstract syntax. Constraints bring additional

constraints on the structure of the language, beyond

what is feasible to express in the structure itself. This

is related to what is called static semantics in tradi-

tional compiler theory. Presentation deﬁnes how in-

stances of the language are presented to the developer.

This can be the deﬁnition of a graphical or textual

concrete syntax. Behaviour explains the dynamic se-

mantics of the language. This can be a transformation

into another language (denotational or translational

semantics), or it deﬁnes the execution of language in-

stances (operational semantics). Mapping binds to-

gether speciﬁcations for structure with speciﬁcations

for presentation and for behaviour.

In a meta-model-based language speciﬁcation en-

vironment, it is common that each language aspect

is handled by a separate domain-speciﬁc language,

also called a meta-language, with tools for generating

the needed code. In the popular environment Eclipse,

structure may for example be deﬁned by the ECORE

language, and code generation handled by the Eclipse

Modeling Framework (EMF)(Steinberg et al., 2008).

There are several plug-ins available that cover other

language aspects. These typically provide their own

aspect-speciﬁc meta-language(-s) and tools that inte-

grate the code generated from the aspect speciﬁca-

tion in the EMF-based structure code, thus providing

a complete editor/execution environment for the lan-

guage being developed.

3 LANGUAGE CONSTRAINTS

Language constraints can put limitations on the struc-

ture of a well-formed instance of the language. This

aspect of a language deﬁnition mostly concerns log-

ical rules or constraints on the structure that are dif-

ﬁcult to express directly in the structure itself. Nei-

ther meta-models nor grammars provide all the ex-

pressiveness that is needed to deﬁne the set of wanted

language instances. However, there is an overlap be-

tween the structure and constraint aspects of a lan-

guage. Some language features may obviously belong

to one of them, but many features could belong to ei-

ther of them, depending on choice or on the expres-

siveness of the technology used to deﬁne the structure.

What we typically want to express with con-

straints in a compiler-based language speciﬁcation is

logical rules and restrictions (static semantic condi-

tions) related to elements of the language structure.

Often, these constraints are expressed in code using a

general purpose programming language, and in some

cases in a separate logic language. These logical rules

may be attached to attributes in an attribute grammar.

IBM’s SAFARI (an IDE development meta-tool)

and MontiCore (a framework for development of

domain-speciﬁc languages) have some support for

constraint handling. Many tools handling attribute

grammars can also handle constraints deﬁned on the

attributes, e.g. with code or logical expressions.

While meta-models are constructive deﬁnitions of

what objects a language instance can consist of, con-

straints allow to narrow down the possible instances

of a meta-model class. A meta-model constraint ex-

pressed is thereby usually written in the context of a

class, and only constrains the set of possible instances

(objects) of this class. A constraint forms a logical ex-

pression. It takes an instance of the context class as

input and evaluates to a boolean value, assessing the

instance as either a valid, or an invalid instance. Only

the models that exclusively consist of valid objects are

valid language instances.

In general-purpose modelling as well as meta-

modelling, model constraints allow the modeller to

restrict the possible valid instances of a model by

deﬁning logical expressions over elements of the

model. This is commonly done in e.g. UML with

the Object Constraint Language (OCL) (OMG, 2005).

OCL is a formal language for describing expressions

on UML models. These expressions typically spec-

ify invariants and pre- and post- conditions that must

hold for the system being modelled. OCL can also ex-

press queries over objects described in a model. OCL

is designed to present the expressiveness of predicate

logic, in a programming language like syntax. Re-

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

330

lated tools allow to check whole models or single

objects, based on the constraints associated with the

model’s meta-model classes. Meta-model-based lan-

guage tools usually do not check a model within a

separate tool, but are integrated into model editors.

Plugins that provide support for OCL constraints in

Eclipse include MDT OCL (Willink, 2012), Dresden

OCL (Birgit Demuth and Claas Wilke, 2009), and the

EMF Validation Framework (EMF-VF).

There are some important issues of constraints

that are not handled by the OCL language, i.e. the se-

riousness of breaking a constraint, and when it should

be checked. These issues will have to be dealt with in

the implementation.

3.1 Constraints in the UML 2

Infrastructure Speciﬁcation

The UML 2.3 Speciﬁcation consists of two com-

plementary speciﬁcations: Infrastructure and Super-

structure. The UML infrastructure speciﬁcation de-

ﬁnes the foundational language constructs required

for UML 2.3, and the UML Superstructure deﬁnes

the user level constructs required for UML 2.3 (OMG,

2007). The primary language used for deﬁning con-

straints in this speciﬁcation is OCL. The following

quote from (OMG, 2007) describes the use of con-

straints in the UML infrastructure speciﬁcation:

The well-formedness rules of the meta-

class, except for multiplicity and ordering

constraints that are deﬁned in the diagram at

the beginning of the package sub clause, are

deﬁned as a (possibly empty) set of invariants

for the metaclass, which must be satisﬁed by

all instances of that metaclass for the model

to be meaningful. The rules thus specify con-

straints over attributes and associations de-

ﬁned in the metamodel. Most invariants are

deﬁned by OCL expressions together with an

informal explanation of the expression, but in

some cases invariants are expressed by other

means (in exceptional cases with natural lan-

guage).

The usage of OCL constraints in the UML speciﬁ-

cation is also supported by auxiliary functions deﬁned

in the speciﬁcation.

3.2 Constraints in the SDL Speciﬁcation

The SDL speciﬁcation (ITU-T, 1999) is organised by

topics described by an optional introduction followed

by titled enumeration items for:

a) Abstract grammar, described by abstract syntax

and static conditions for well-formedness.

b) Concrete textual grammar. This grammar is

described by the textual syntax, static conditions and

well-formedness rules for the textual syntax, and the

relationship of the textual syntax with the abstract

syntax.

c) Concrete graphical grammar, described by

the graphical syntax, static conditions and well-

formedness rules for the graphical syntax, the

relationship of this syntax with the abstract syntax.

d) Semantics, that gives meaning to a construct,

provides the properties it has, the way in which it is

interpreted and any dynamic conditions which have

to be fulﬁlled.

e) Model, that gives the mapping for notations that

do not have a direct abstract syntax and modelled in

terms of other concrete syntax constructs.

f) Examples.

The SDL speciﬁcation does not use OCL or other

dedicated constraints languages for constraints. The

constraints are instead expressed in English and take

the form of sentences referring to elements of the

grammars. They are mostly well-formedness rules for

the concrete grammars, but there are occasionally also

constraints for the abstract syntax. However, it must

be noted that the document “ITU-T Recommendation

Z.100 Annex F: SDL Formal Semantics Deﬁnition”

(ITU-T, 2007) provides formal semantics for SDL in-

cluding a formal description of constraints.

4 CATEGORISATION OF

CONSTRAINTS USAGE

A survey of the usage of constraints in two differ-

ent language speciﬁcations, the UML infrastructure

speciﬁcation (OMG, 2007) and the SDL speciﬁcation

(ITU-T, 1999), has given insights that may be taken as

a starting point for creating a higher abstraction level

approach to language constraints. Two different ap-

proaches are tested, the ﬁrst approach is focused on

classifying and grouping the constraints with the pur-

pose of ﬁnding common semantic patterns that can be

applied to a language speciﬁcation. The second ap-

proach investigates possible structural commonalities

among constraints that can be exploited.

4.1 Semantic Approach

The ﬁrst approach attempted was based on grouping

and classifying constraints into sets of common con-

straint types that could be used as a basis for a li-

brary of common constraint patterns that could be ap-

LCL-AGraphicalMeta-LanguageforSpecificationofLanguageConstraints

331

plied to a language speciﬁcation. If successful, this

approach could signiﬁcantly lower the complexity of

deﬁning language constraints by allowing the lan-

guage developer to pick and apply the relevant con-

straint patterns for the language to be developed. We

started with an initial set of expected constraints cate-

gories, based on previous experience with language

constraints: Name-space-related constraints, Type-

related constraints, Structural constraints and Syn-

tactic matching.

By going through the constraints in the UML In-

frastructure speciﬁcation (OMG, 2007) and attempt-

ing to sort them into these categories, more cate-

gories were discovered that were added to the initial

set. As the survey progressed, the categories were re-

evaluated and adjusted until a stable set of categories

was established. Then, the SDL speciﬁcation was ex-

amined and used for verifying the adequacy of the set

of categories.

The total number of constraints in the UML in-

frastructure speciﬁcation is 67. The main categories

of constrains discovered in the speciﬁcation are:

Namespace handling (5)

Example: All the members of a Namespace

are distinguishable within it (9.14.2.1 of (OMG,

2007)).

Type handling (9)

Example: If this operation has a return parameter,

type equals the value of type for that parameter.

Otherwise type is not deﬁned (11.8.2.6 of (OMG,

2007)).

Structural constraints (25)

Example: Generalization hierarchies must be di-

rected and acyclical. A classiﬁer cannot be both a

transitively general and transitively speciﬁc clas-

siﬁer of the same classiﬁer (9.19.1.1 of (OMG,

2007)).

Context constraints (1)

Example: Subsetting may only occur when the

context of the subsetting property conforms to

the context of the subsetted property (11.3.5.3 of

(OMG, 2007)).

Helper functions for constraints (not counted)

Example: The query allFeatures() gives all of the

features in the namespace of the classiﬁer. In

general, through mechanisms such as inheritance,

this will be a larger set than feature (9.4.1.1 of

(OMG, 2007)).

Dynamic semantics constraints (27)

Example: If this operation has a return parameter,

isOrdered equals the value of isOrdered for that

parameter. Otherwise isOrdered is false(11.8.2.3

of (OMG, 2007)).

We note that three new categories are identiﬁed

(the last three in the list above), and one expected cat-

egory that is removed (syntactic matching) after a lack

of related constraints identiﬁed.

The SDL speciﬁcation (ITU-T, 1999) has also

been examined, and when it comes to abstract syntax,

the constraints fall into the categories above. How-

ever, it is noticeable that while the UML speciﬁca-

tion uses constraints to cover the limitations of MOF

for deﬁning structure, the SDL speciﬁcation uses con-

straints to cover the limitations of grammars, for ex-

ample for simulating associations with multiplicity.

For concrete textual and graphical syntax, there are

two additional categories of constraints detected:

Location of elements

Typically takes a form like <element A> is to the

right of <element B> or <element A> is inside

<element B>.

Mapping handling

Typically takes the form <concrete element> rep-

resents <abstract element>.

However, we encountered complications when

trying to divide the categories further into simple

(positive or negative) patterns that can be handled by

a new constraint language. Most of the constraints are

falling into a rather vague structural constraints cate-

gory, where it is difﬁcult to isolate common patterns.

With this in mind, a different approach is attempted,

as described in the following.

4.2 Structural Approach

The majority of the analysed constraints are in the

form of implications, with object patterns on the right-

and left-hand sides of the implication, in many cases

combined with logical operations. By analysing the

constraints, we ﬁnd that more complex constraints in-

volving logical operations like AND and OR, can be

handled by rewriting or splitting up the constraints.

We note that constraints tend to be local, concern-

ing an object and its attributes and references; but it

may also be more complex, making it necessary to

look at a bigger picture. For the non-local constraints,

some require looking at the parent node in the graph

structure, some require iterative navigation to parent

nodes, and a few are completely global, requiring

more complex querying of objects. Constraints may

also contain external references, referring to some-

thing outside the speciﬁcation, e.g. ﬁlenames, mod-

ules, or editors. However, this type of constraints can

also not be handled by OCL. In the UML speciﬁca-

tion, the initial quick survey detected 86 local con-

straints, 29 parent constraints, 3 iterated constraints

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

332

and 20 global constraints. However, the constraints

that were initially put into the global category tended

to be the most complex and difﬁcult to understand,

and since global patterns are harder to express as ob-

ject diagrams, we performed a second closer analy-

sis of the initially thought global ones that uncovered

that all of them actually more correctly fall into ei-

ther local, parent or iterated categories, and in a few

cases the statement is not a constraint at all but e.g.

a explanatory statement for the reader. The ﬁnal re-

sults are 68% local patterns, 22% parent patterns, 6%

iterated patterns, 0% global patterns and 4% not a

testable constraint. A brief survey of the SDL speciﬁ-

cation shows a similar trend in the distribution of the

results, although there are less local patterns and more

parent and iterated patterns found in this case: 50%

local patterns, 30% parent patterns, 20% iterated pat-

terns, 0% global patterns. Note that non-constraints

statements were not counted in the SDL speciﬁcation.

This indicates that a structural approach may handle

the great majority of real-world language constraints,

and therefore be valid for real-world usage.

4.3 Do we Really Need a New DSL for

Language Constraints?

While OCL is more specialised for the task of deﬁn-

ing constraints than general-purpose programming

languages, it may still be argued that we are on a rela-

tively low abstraction level, using a quite general logi-

cal language for something much more speciﬁc. OCL

has a wide feature set that handles a wide range of

model types, and many of these features will normally

not be needed in a language speciﬁcation.

Although OCL clearly is up to the task of deﬁn-

ing constraints in a language speciﬁcation, it also

makes sense to create a domain-speciﬁc language not

because we need features that general purpose lan-

guages cannot offer, but because we would like to re-

duce unneeded complexity. Therefore, a DSL for lan-

guage constraints called LCL (Language Constraint

Language), is proposed. It aims to be a simple, intu-

itive and easy to use alternative to OCL (or code), that

covers the needs of the language developer.

4.4 The Chosen Approach

We have found that simple series of object pattern im-

plications will cover the majority of the cases encoun-

tered during this survey. A typical constraint will then

consist of 3 parts; context pattern, one or more con-

dition patterns, and ﬁnally a check pattern. The con-

text pattern part is setting the context or applicabil-

ity criteria for the constraints in much the same way

as in OCL. An advantage over OCL may be that we

are able to express more complex contexts than OCL’s

single element context. The context pattern is always

positive, while the condition patterns may be positive

or negative as needed, to express that the given pattern

must or must not be present in the model for the impli-

cation to be valid. These patterns functions to restrict

the possible sets of elements that the constraint ap-

plies to and may also introduce additional connected

elements. The last pattern in the implication series

is the check pattern. This functions as an evaluation

point where we get the result of the constraint evalua-

tion; True if the implication series is valid, and False

otherwise. Based on the evaluation result, a response

to the user is generated. This approach is further de-

scribed in the following section.

5 A NEW META-LANGUAGE FOR

LANGUAGE CONSTRAINTS

From examining OCL usage in language speciﬁca-

tions, we gained insights that are used as a foundation

to deﬁne a new DSL for language constraints. A con-

straints language based on object patterns is proposed,

that also supports handling of constraints checking is-

sues like when to check, and what to do if a constraint

is broken.

5.1 Structure of LCL

Figure 1 shows the basic structure of the Language

Constraints Language (LCL). The two main parts of

the language are the Constraint with its connected

ObjectPattern classes, and the CheckHandling

class. The attributes of the CheckHandling class de-

termine when a constraint should be checked, how se-

vere a breakage is, what to do if it is broken, and an

optional message to the user.

Figure 1: The Structure of the Language Constraints Lan-

guage.

LCL-AGraphicalMeta-LanguageforSpecificationofLanguageConstraints

333

The ObjectPattern part is here abbreviated into

a single class for reasons of space and clarity, but

does actually represent a simple object description

language similar to UML object diagrams, enhanced

with recursive associations for iterated patterns.

The Constraint has three associations corre-

sponding to the three elements of the constraint; the

context, the conditions and the check. The context

pattern may only reference a PositivePattern,

that represents an object diagram pattern that has to

be present in the model for the constraint to apply.

The conditionPatterns association points to a se-

quence of positive or negative patterns that further de-

tails the scope of the constraint in the form of an im-

plication chain. The checkPattern ﬁnally provides

the positive or negative pattern that will be evaluated

to be true or false based on the previous implication

chain.

5.2 Presentation of LCL

A graphical presentation for LCL may take the form

of a sequence of boxes containg object patterns, as

shown in Figure 2. Each box contains an object dia-

gram representing the relevant pattern, with a plus or

minus sign in the corner of the box determining if it

contains a positive or negative pattern.

The illustrated constraint is taken from section

9.21.1 of (OMG, 2007): “If a NamedElement is not

owned by a Namespace, it does not have a visibility.”

In OCL, it is expressed as: namespace->isEmpty()

implies visibility->isEmpty(). In the LCL ex-

ample, name of the constraint is given in the top of the

diagram, “NamedElementVisibilityConstraint”. The

box on the left hand side contains the context pat-

tern. This pattern is positive, as context patterns al-

ways have to be. This is signiﬁed by the “+” in the

upper right corner. The “+” means that the constraint

applies if the pattern is found in the given model that

it is attached to. In this example, the context is the

existence of a NamedElement. The NamedElement is

given the variable name a so we can refer to it in later

patterns. The next pattern is a negative pattern, ex-

pressing that the constraint applies if the NamedEle-

ment from the previous pattern does not contain an

association to a NameSpace. The last pattern is the

check pattern, giving the ﬁnal criteria that the con-

straint will be evaluated based on. It states that given

the previous restrictions, the Visibility attribute of

the NamedElement must have a value NULL. Note

that the check handling parameters are not shown in

the constraint examples provided here.

5.3 Semantics of LCL

In a nutshell, the semantics of LCL can be separated

into two parts, the evaluation of the constraints, and

the handling of checking and reporting results. There

are 5 main steps in handling a constraint:

• CheckHandling: based on the checkHanding

properties of the Constraint, evaluation of the

Constraint is triggered.

• Context: search the model for objects that ﬁt the

criteria given by the contextPattern, and select

these for further evaluation.

• Conditions: for each pattern in the conditionPat-

terns sequence, restrict the set of objects accord-

ingly.

• Check: evaluate the ﬁnal implication towards the

checkPattern, and return a True or False result ac-

cordingly.

• Report: based on the checkHanding properties of

the Constraint, a message to the user is generated,

and appropriate action is triggered.

Interpretation of positive and negative patterns:

• A positive pattern is valid if and only if all ele-

ments of the pattern are present in a structurally

equivalent form in the model to be evaluated.

• A negative pattern is invalid if and only if all el-

ements of the pattern are present in a structurally

equivalent form in the model to be evaluated.

On object names in patterns:

• Names are introduced to identify objects between

patterns in a constraint.

• Names are limited in scope to a single constraint.

• Different object description b= different objects

unless name is equal.

• Negative patterns cannot introduce object names.

• Need also object description reference! (i.e. refer

to more info of an object)

5.4 Additional Examples of LCL

Constraints

The ﬁrst example, taken from section 11.8.2 of

(OMG, 2007), shows how a complex constraint can

be expressed as two different constraints in LCL: “If

this operation has a return parameter, type equals

the value of type for that parameter. Otherwise

type is not deﬁned.” In OCL, it is expressed as:

type = if returnResult()->notEmpty() then

returnResult()->any().type else Set endif.

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

334

Figure 2: Example constraint in LCL.

Figure 3: Type checking constraint in LCL.

In LCL, we divide it into two constraints as shown in

Figure 3, both ﬁrst setting the context to Operation

objects. The ﬁrst limits the set to operations having a

returnParameter, while the second constraints covers

operations without such a parameter. The last part

of each constraint then in the ﬁrst case requires the

associated type to be the same, while in the second

case, the operation should not have a type, as given in

the corresponding negative pattern.

The second example is taken from section 13.1.8

of (OMG, 2007)and states that “A stereotype must be

contained, directly or indirectly, in a proﬁle.” OCL

solves this using a specialised function, expressed

as profile = self.containingProfile(). In

LCL (see Figure 4), we can use this example to

demonstrate both a minimal constraint with only two

patterns, the context and the check pattern; and use

of the iterated association shown using an association

with a star in the middle. This means that the element

Figure 4: Containment constraint in LCL.

must be directly or indirectly associated with the

other element. In this case, showing that a Stereotype

must be directly or indirectly contained in a Proﬁle.

The third example from section 9.19.1 of (OMG,

2007), states that “Generalization hierarchies must be

directed and acyclical. A classiﬁer cannot be both

a transitively general and transitively speciﬁc classi-

ﬁer of the same classiﬁer.” This is expressed in OCL

LCL-AGraphicalMeta-LanguageforSpecificationofLanguageConstraints

335

Figure 5: Generalisation hierarchies constraint in LCL.

as not self.allParents()->includes(self). In

LCL, it can be expressed as shown in Figure 5, us-

ing again an iterated connection, but this time an iter-

ated generalisation in a negative pattern showing that

a Classiﬁer can not directly or indirectly generalise

itself.

6 DISCUSSION

The chosen solution primarily focusses on concep-

tual issues and does not provide a complete language

with all aspects fully speciﬁed. However, reﬁnement

of LCL into a complete language speciﬁcation, and

further implementation into a usable language, would

not be very difﬁcult given the relative simplicity of the

provided solution.

The solution provides the possibility to handle

language constraints on a higher level of abstraction,

and allows the language developer to deﬁne when to

check each constraint and what to do if it is broken.

Solutions like adding higher abstraction level func-

tions to OCL (i.e. LCL as an internal DSL in OCL)

or to add support for constraint check handling could

also partly solve the problem, but it is considered im-

portant that a constraints language should be as sim-

ple to use as possible, and that is a strength of deﬁn-

ing LCL as an external DSL. If a wanted constraint

is not possible to express with the implications and

object diagrams supported by LCL, should then the

use of OCL be allowed? It would be constructive

to ﬁrst determine if the newly requested constraint is

actually one that could be split up into manageable

parts, or if wanting the constraint is the result of bad

design decisions by the language designer. We note

for example that expressions support is a feature that

is present in OCL but missing from LCL. However,

while it is clearly needed in a general purpose con-

straints language, the survey of language constraints

shows that the need for expressions in language con-

straints is small and the constraints can usually be ex-

pressed in other ways.

The approach is intended to make deﬁning lan-

guage constraints easier. With a graphical approach

and a high level of abstraction, it should be less prone

to bugs than by using OCL or similar logical lan-

guages, or even general purpose programming lan-

guages. A full logical language may in most cases be

overkill for the issues to be handled by language con-

straints, when a more simple and easy to understand

language would be sufﬁcient. This design should help

the language developer avoid errors and bugs related

to malformed or logically incorrect constraints, and

will lower the requirement for programming skills of

the language developer and allow him to operate on

a higher level of abstraction. The chosen approach

would be particularly suited for DSL developers; a

graphical approach is more easy to grasp for non-

programmers and therefore facilitates communication

with domain experts during development of DSLs.

An additional advantage to LCL is that it is easy to

learn as it is just a minor extension to an already well-

known object diagram notation.

Real-world usage is needed to determine if this ap-

proach is able to cover the needs of a language devel-

oper in its current form, or if it has to be extended,

e.g. with more complex implication patterns.

7 RELATED WORK

A limited but signiﬁcant amount of related work can

be found. Among others, there are articles related

to language workbenches and their technologies that

are worth noting as they may also cover constraints

support in these workbenches. Research related to

domain-speciﬁc constraint(-like) languages outside of

the language domain may also be interesting for com-

parison across domains. Finally, research on general

purpose constraint languages may also be relevant.

In the ﬁrst category, The State of the Art in Lan-

guage Workbenches by Erdweg, van der Storm, et al.

gives an interesting overview of the participants in

the 2013 Language Workbench Competition, where

it describes the features supported in several language

workbenches and gives some insights on how the dif-

ferent workbenches support constraints; ranging from

no support, to support for speciﬁc types of constraints

like type enforcement through dedicated declarative

languages, but in many cases ether relying on pro-

grammatic handling or semantically rich meta-models

(Erdweg, Sebastian and van der Storm, Tijs and Völ-

ter, Markus and Boersma, Meinte and Bosman, Remi

and Cook, William R and Gerritsen, Albert and Hul-

shout, Angelo and Kelly, Steven and Loh, Alex and

others, 2013). Visser and Eelco’s Separation of Con-

cerns in Language Deﬁnition propose an approach to

MODELSWARD2015-3rdInternationalConferenceonModel-DrivenEngineeringandSoftwareDevelopment

336

separation of concerns in language deﬁnition that in-

cludes high-level declarative meta-languages that in-

cludes constraints (Visser, 2014).

In the second category, Mens, van der Straeten

and d’Hondt cover model consistency checking in

Detecting and resolving model inconsistencies us-

ing transformation dependency analysis (Mens et al.,

2006) with an interesting approach using transforma-

tion rules that have some similarity to the graphical

presentation of LCL, although it has a different goal

from the current issue of constraints enforcement in

language speciﬁcations.

The third category includes Jaffar and Mahler’s

Constraint logic programming: a survey that gives

an overview of constraint logic programming, from

which domain-speciﬁc constraint languages may ﬁnd

inspiration (Jaffar and Maher, 1994).

8 SUMMARY AND FUTURE

WORK

A survey of OCL usage in language speciﬁcations has

been performed, in order to gain an understanding that

is used to deﬁne a new approach for language con-

straints. A solution based on structured object pattern

implications is proposed, that also supports handling

of constraints checking issues like when to check, and

what to do if a constraint is broken. The proposed so-

lution allows language designers to focus on language

features rather than complex logical expressions. It

may be particularly useful for DSL developers be-

cause of its familiar graphical syntax that make con-

straints in LCL both easy to understand and easy to

explain to stakeholders that may be less familiar with

logical expression languages.

There are still open issues left for future work.

A full formal speciﬁcation of all aspects of the pro-

posed constraints language is needed. A textual con-

crete syntax is being developed as an alternative to

the graphical diagram-based presentation. A pro-

totype implementation of LCL is already ongoing,

adding constraints support to the LanguageLab lan-

guage workbench (Gjøsæter and Prinz, 2012) that will

be tested on Master students studying computer lan-

guage theory and design next year. Based on experi-

ences from this prototype, the approach will be further

reﬁned and adapted to the needs of DSL developers.

REFERENCES

Birgit Demuth and Claas Wilke (2009). Model and Object

Veriﬁcation by Using Dresden OCL. In Proceedings

of the Russian-German Workshop Innovation Infor-

mation Technologies: Theory and Practice, July 25-

31, Ufa, Russia, 2009, page 81. Ufa State Aviation

Technical University, Ufa, Bashkortostan, Russia.

Erdweg, Sebastian and van der Storm, Tijs and Völter,

Markus and Boersma, Meinte and Bosman, Remi and

Cook, William R and Gerritsen, Albert and Hulshout,

Angelo and Kelly, Steven and Loh, Alex and others

(2013). The state of the art in language workbenches.

In Software Language Engineering, pages 197–217.

Springer.

Gjøsæter, T. and Prinz, A. (2012). Languagelab 1.1 user

manual. Technical report, University of Agder.

ITU-T (1999). SDL - ITU-T Speciﬁcation and Descrip-

tion Language (SDL-2000). ITU-T Recommendation

Z.100.

ITU-T (2007). Recommendation Z.100 Annex F: SDL For-

mal Semantics Deﬁnition. International Telecommu-

nications Union (ITU), Geneva.

Jaffar, J. and Maher, M. J. (1994). Constraint logic program-

ming: a survey. The Journal of Logic Programming,

19–20, Supplement 1(0):503 – 581. Special Issue: Ten

Years of Logic Programming.

Kelly, S. and Tolvanen, J.-P. (2008). Domain-Speciﬁc Mod-

eling. Wiley-Interscience.

Mens, T., Van Der Straeten, R., and D’Hondt, M. (2006).

Detecting and resolving model inconsistencies using

transformation dependency analysis. In Model driven

engineering languages and systems, pages 200–214.

Springer.

Nytun, J. P., Prinz, A., and Tveit, M. S. (2006). Auto-

matic generation of modelling tools. In Rensink, A.

and Warmer, J., editors, ECMDA-FA, volume 4066 of

Lecture Notes in Computer Science, pages 268–283.

Springer.

OMG (2005). OCL 2.0 Speciﬁcation. Object Management

Group. ptc/2005-06-06.

OMG (2007). UML Infrastructure Speciﬁcation, V2.1.2.

Object Management Group. ptc/06-10-06.

Steinberg, D., Budinsky, F., Paternostro, M., and Merks, E.

(2008). EMF: Eclipse Modeling Framework. Eclipse

Series. Addison-Wesley Professional, second edition.

Visser, E. (2014). Separation of concerns in language def-

inition. In Proceedings of the Companion Publica-

tion of the 13th International Conference on Modular-

ity, MODULARITY ’14, pages 1–2, New York, NY,

USA. ACM.

Willink, E. D. (2012). An extensible ocl virtual machine and

code generator. In Proceedings of the 12th Workshop

on OCL and Textual Modelling, OCL ’12, pages 13–

18, New York, NY, USA. ACM.

LCL-AGraphicalMeta-LanguageforSpecificationofLanguageConstraints

337