Domain-specific languages enable concise and precise formalization of domain concepts and promote direct employment by domain experts. Therefore, syntactic constructs are introduced to empower users to associate concepts and relationships with visual textual symbols. Model-based language engineering facilitates the description of concepts and relationships in an abstract manner. However, concrete representations are commonly atached to abstract domain representations, such as annotations in metamodels, or directly encoded into language grammar and thus introduce redundancy between metamodel elements and grammar elements. In this work we propose an approach that enables autonomous development and maintenance of domain concepts and textual language notations in a distinctive and metamodel-agnostic manner by employing style models containing grammar rule templates and injection-based property selection. We provide an implementation and showcase the proposed notationspecification language in a comparison with state of the art practices during the creation of notations for an executable domain-specific modeling language based on the Eclipse Modeling Framework and Xtext.
1 Introduction hTe engineering of a domain-specific language (DSL) is usually initiated by the construction of an artifact that captures concepts and relationships inherent to the domain being represented. Typical artifact types include variations of grammars and metamodels—each inherently of diferent natu1r5e].[In general, grammars are employed to describe domain concepts and their textual representation utilizing production rules and terminal rules, respectively. Contrarily, metamodels are used to capture concepts and relationships of a domain but not their syntactic constructs. Although state of the art language workbenches, such as X5t]e,xptro[vide means to generate grammars from metamodels and vice-versa, they provide a single (default) notation, i.e. either graphical, textual, or a combination thereof, that has to fit the needs of all types of domain experts or requires dedicated language engineering skills for adaptation and extension. The construction of a bridge between metamodel and grammar, and in particular from metamodel to grammar, is commonly approached by introducing annotations in metamodels or metamodel-to-grammar transfor2m]a.Htioown-s [ ever, construction and maintenance of such bridges is inherently complex and errorprone due to fundamental diferences between metamodels and grammars. Moreover, such bridges are often metamodel-dependent and are thus not universally applicable to arbitrary domains.
In this work, we present the Ecore Concrete Syntax Specification (Ecss) framework5—a novel textual notation description language and toolkit that enables the definition of both metamodel-dependent and metamodel-agnostic representations for Ecore-based languages—and employ it for automating the generation of textual modeling languages with supporting editors and tools from Ecore metamodels. In summary, Ecss facilitateis) (the creation, extension, and reuse of textual notations (subsequently also referred to as “style models” and “Ecss models”)iai)ntdh(e generation of grammar and executable implementation of domain-specific modeling languages (DSMLs) from pairs that consist of domain metamodel and style model. We showcase the implementation of our approach in a comparison with the state of the art in model-driven language engineering the results in the manifestation of a DSML. Roadmap. The remaining sections of this paper presenit)(a brief overview of methodologies and techniques upon which this work is buiildi), a( motivating examplei,i(i) the conceptual and technical characteristics of our approach alongside state-of-the-art solutions and in particular Xtext and the Eclipse Modeling Framework (iEvM)aF), ( selection of related work, and finallvy)(a conclusion and outline of future work.
Model-Driven Engineering and Domain-Specific Languages. In this work we specifically
focus on the construction and maintenance of Domain-Specific Modeling Languages
(DSML), i.e. the employment of Model-Driven Engineering (MDE) in the context of
Domain-Specific Languages (DSLs) [
Language Engineering and Workbenches. Language workbenches6[], such as Xtext, are tools that provide a range of features, such as dedicated editors, model transformations and validations, for DSML specifications. In general, Xtext employs the ANTLR parser generator23[] for the production of implementation artifacts, such as lexers and parsers, and ofers two diferent DSML construction-mechanisms, i.e. typically selected as a result of an engineer’s familiarity with the technica6losfpagcreasmmarware and modelware26[]. On one hand, grammarware engineers, which are more familiar with traditional CFGs, may construct CFGs and employ the Xtext mechanism for deriving EMF-based metamodels. On the other hand, modelware engineers, which are most familiar with MDE-based technologies, may develop EMF-based metamodels and derive CFGs by employing metamodel-to-grammar transformations. Although Xtext supports both, the main focus is to provide grammars at the front-end and metamodels at the back-end to facilitate tool interopera22b,il2it8]y. [ 3
Within this section, we present a typical language engineering use16c,a1s4e][that involves the construction of a DSML by employing Xtext and the EMF and in particular a metamodel for capturing the concepts and relationships of a language for space transportation services. Moreover, this metamodel formulates the foundation upon which state-of-the-art practices, such as model-to-text transformations and grammar adaptation, as well as our approach may create, modify, and apply notations. Language Structure. The metamodel of our exemplary language (cf. Figur1e) instantiates the core components of the Ecore metamodeling language, such as (abstract) classes, atributes, (containment) references, and enumerations. More specifically, the following concepts and relationships are defined:SpaaceTransportationService can own launch sites, spacecrafts, and engine types;Sapacecraft is defined by name, relaunch-cost, stages, manufacturer, country of origin, physical properties, functions, such as be an orbital launcher or intercontinental transport vehicle, and launch sites from where it can startS;taage is defined by name, such as booster or spaceship, an engine type, and physical properties;PahysicalProperty is defined by a type, such as length, volume or mass, unit, and value; anLdaaunchSite is defined by name, location, operator, number of launchpads, operational status, and physical properties. 6 Technical space refers to a working context with a set of associated concepts, body of knowledge, tools, required skills, and possibilities often associated to a given user community with shared know-how, educational support, common literature, and scientific ve1n7u].es [ Second
Stage Intermediate
Stage First Stage << abstract >>
NamedElement name : String
EngineType fuelKind : String LaunchSite [1..1] engineType
Stage engineAmount : Integer [0..*] engineTypes
[0..*] launchSites
SpaceTransportationService
Spacecraft [0..*] functions: Function manufacturer : String countryOfOrigin : String relaunchCostInMioUSD : Integer [0..*] stages [0..*] physicalProperties [0..*] physicalProperties
LaunchSite locationLatitude : Double locationLongitude : Double operator : String numberOfLaunchpads : Integer operational : Boolean
[0..*] physicalProperties [0..*] spacecrafts
[0..*] launchSites
PhysicalProperty type : PhysicalPropertyType unit : String value : Double
Notational Requirements. The requirements on the textual notation of the language
to be constructed includie) i(ndentation-based layout, i.e. also referred to as
ofsiderules [
1 SpaceTransportationService: 2 launchSites: 3 name: KennedySpaceCenter, 4 operator: NASA, 5 operational: true, 6 numberOfLaunchpads: 3, 7 locationLatitude: 28.524058, 8 locationLongitude: 80.65085
Listing 1.1. Instance of a space transportation service (excerpt).
Within this section our contribution is outlined alongside its application to the previously introduced example. First, the state-of-the-art model-first and grammar-first approach is showcased. Secondly, design principles, structural components, and selection modes of the style specification language are introduced. Thirdly, the style speciifcation language is employed to model a DSML that fulfils the requirements presented in Section3. Finally, the mechanism that generates executable DSML implementations from tuples that consist of style model and domain-specific metamodel is presented.
E1a E1b
G1 generate
G2
Metamodel StyleModel Grammar
G3 reference
ECSS E2
generate generate
Metamodel Grammar-first
Grammar
E3
generate
Language Structure
Style Language implementation
Component Subcomp. A
Subcomp. B generate
Step # Legend
M1 generate
Model-first
Metamodel
M2 M4
Grammar
reference M3
adapt
reference
transformation
4.1 Model-first approach
hTe model-first approach [
Listing 1.2. Result of stepM 2—generated domain-specific grammar (excerpt).
To yield a DSML that supports indentation-based layout that prescribes that all non-whitespace tokens of a structure must be further to the right than the token that starts the structure, as well as flexible order of specification, the following adaptations on the generated grammar are performed. First, synthetic tokens, i.e. ofering the specification of whitespace-semantics employing synthetic terminal rules, for the beginning and the end of a line as well as new lines are introduced (cf. lines 1-3 in Listing1.3). Next, production rules are adapted to use the specified synthetic tokens (cf. lines 8-13 in Listin1g.3). Secondly, to support arbitrary order of declaration alongside whitespace-semantics, all possible occurring sequences need to be depicted by the grammar, which is accomplished by intermediating rule assignments with a vertical line, i.e. indicating a logical or, and enclosing them with brackets ending with a star-character, i.e. indicating zero or multiple occurrences. However, the combination of flexible sequences and whitespace-semantics requires to state all possible occurring sequences explicitly and thus causes the size of production rules to multiply by the number of structural features occurring in the containing classes.
1 terminal BEGIN: 'synthetic:BEGIN'; 2 terminal NEWLINE: 'synthetic:NEWLINE'; 3 terminal END: 'synthetic:END'; 4 5 Stage returns Stage: SINGLESPACE 6 'name' ':' name=EString 7 (NEWLINE 'engineAmount' ':' engineAmount=EInt) & 8 (NEWLINE 'engineType' ':' engineType=[EngineType|EString]) 9 (NEWLINE 'physicalProperties' ':' BEGIN 10 physicalProperties+=PhysicalProperty 11 (NEWLINE physicalProperties+=PhysicalProperty)* 12 END)?;
Listing 1.3. Result of stepM 3—adapted domain-specific grammar (excerpt).
4.2 Grammar-first approach
hTe grammar-first approach [
Our approach is primarily intended to be applied within the context of model-first language engineering (cf. Sectio4n.1) due to the facilitation of metamodels for capturing domain-specific structural semantics and constraints. However, it is also applicable for use cases in which metamodels are derived from domain-specific grammar and employed alongside style models to generate modernized DSML implementations. 0..* templates 0..* imports
0..* properties 0..1 selector 0..1 property
0..1 templateMatch 0..1 propertyValue
0..1 slotMatch
0..* selectors
0..1 condition
0..1 selector 0..1 first 0..1 second 0..1 expression 0..* parameterValue 0..1 expression
Design principles. The aim of the Ecore Concrete Syntax Specification (Ecss) language to capture common styles of textual syntaxes (e.g. YAML-like, JSON-like, XMLlike) and to support the automated generation of Xtext grammars for such7.syntaxes Ecss is inspired by CSS, which allows to style HTML code and ofers straightforward composition, and thus aims for similar composability and parameterizability. For example, developers should be able to reuse, extend, and adapt existing language notations through composition with other language notations.
Structural Components. The core component of the Ecss language (cf. Figur3e) is a StyleModel that may extend other instances of style models through imports and contains a set of rules defining properties and templaPtreosp.ertyRules may be composed of a selector and properSteyl.ectors may be composed ofSingleSelector instances that may contain Caondition, i.e. defined by a FormalExpression such as an OCL expression. Each single selector selects a particular rule application instance. Selectors may define a name and thereby select rule applications with matching names. More specifically, the name for a rule that has a single feature as parameter refers to the name of the feature, i.e. the name of the class in case of a single class. Additionally, a selector may select subclasses by specifying the name of the rule that is named by its superclasses. Similarly to HTML, a sequence of single selectors choose rule applications based on their hierarchy. In detail, a rule application is chosen for a sequence of seleic)tors if ( it matches the last single selector itselfiia)nadd(irect or indirect parent matches the 7 An initial catalogue of reusaEbcless styles is available online ahttp://bit.ly/ecss-styl.es remaining selectors. In addition to basic names, selectors may also specify that all rule applications are admissible and may restrict the applications using OCL expressions.
Instances ofProperty may be composed of aTemplateMatch, a SlotMatch, and a PropertyValue. A template match containnsaame and associates a priority for using the templatneame for the rule application under consideration. A slot match contains a pair a(tributename , slotname), specifying the priority that an atribute is matched to a slot. A property value simply associates a property of the rule application to a certain value, which may be a constant or an OCL expression evaluation result. The application of all properties may further be restricted by OCL expressions.
TemplateRules manifest as expressions, suchFaosrEachExpression andIfExpression, or calls, such asEvaluationCall and TemplateFunctionCall, and may contain static executed code parts and static outputFso.rAEachExpression triggers the generation of code for each object in a parameter of the rule applicatTieomnp.lAateFunctionCall provides an opportunity to create a subsequent rule (subrule) application and may own instances oTfemplateParameterValue that originate from rule application parameters, values calculated from property rules, and values of a slot, i.e. defined by a multiplicity determining the minimum and maximum amount of subsequent features (subfeatures) that are distributed in this slotE.vAanluationCall produces output based on a property value. ATemplateFunctionCall produces output either as part of the parent rule, i.e. acting as the container, or as a reference identifier, i.e. triggering content generation outside the parent rule.
Syntactic Components. The primary syntactic components used within the context of an Ecss model include pronounceable keywords such iamsport , template, rule, for, and if, as well as template-activating character sequences su[c%h=…as%] for value insertion through variable access or function[%ca…ll%s], for (local) evaluation call or value call, and::ruleName() andruleName() for Java calls. 4.4 Style modeling hTe requirements imposed on the language introduced in Secti3onare fulfilled by supplying the Ecss grammar creator with the Ecore metamodel and Ecss model created in stepE1a and E1b of Figure2, respectively. In more detail, the style model ws-aware.ecss andarbitrary-order.ecss is created to fulfill the first and second requirement, respectively. The rule whitespaceClassRule in Listing1.4 defines that the features of a class are indented, i.e. with respect to the class itself. More specifically, line 6 produces the grammar rule header. Next, if the class being processed has no associated atribute, classname followed by an empty space and colon is produced as initial content of a class (cf. lines 7-8). Alternatively, if a class owns a set of atributes, a rule call to the rule grounpameDistRules is performed (cf. lines 9-11), i.e. selecting a subrule. Next, additional indentation is created for feature definitions that are returned by rule callatributeDistRules . The property rule NamedElement+ is metamodel-dependent and specifies that theclassname of classes that extend the clNaasmsedElement have to appear in uppercase characters (cf. lines 14-15). The global property rule, i.e. indicated by a star-selector, is metamodel-agnostic and specifies thactlatshsneame of (any matching) class is defined by its name (cf. line 17) or, in other words, the name of a class in its metamodel. Note that due to the (higher) prior2it.0ytohfat is defined by property rule NamedElement+, the global property rule with (lower) priorit1y.0oifs only matched by classes that dnoot extend the clasNs amedElement.
hTe rule arbitraryAtributeDistr in Listing1.5 defines a style that fulfills the second notational requirement, i.e. comma-separated arbitrary order of declaration, that is not feasible by the use of (simple) unordered groups and causes a quadratic increase in the size of a grammar rule. In more detail, lines 7-9 define the initially occurring feature as arbitrary, i.e. any feature from the set of features of a class may occur first. Next, lines 10-11 encapsulate Java code that computes a list of remaining class features that is subsequently being iterated for the production of individual feature occurrences that are prefixed by comma separators (cf. lines 13-15).
1 import "default.ecss"; 2 3 templateGen classGenTemplate extends classTemplate; 4 5 rule whitespaceClassRule :classGenTemplate :: classRules: 6 class.name " returns " class.name ":" "{" class.name "}" 7 [% if (slot_name.getValues().isEmpty()) {%] 8 " '" classname "' " " ':' " 9 [% } else {%] 10 nameDistRules(~name[0 .. 1]) 11 [% }%] 12 ::BEGIN() " (" attributeDistRules(~other[ 0 .. 99]) ")" ::END() ';' ; 13 14 NamedElement+ 15 { classname: ocl "rule.class.name.toUpperCase()" priority(2.0); } 16 17 * { classname: ocl "rule.class.name" priority(1.0); slot(name,name): 2.0;}
Listing 1.4. Ecss model for indentation-based layout (excerpt of ws-aware.ecss). 1 import "wsaware.ecss"; 2 3 template attributeTemplate: uk.ac.york.cs.ecss.newproc.AttributeXtendRule; 4 templateGen attributeGenTemplate extends attributeTemplate 5 6 rule arbitraryAttributeDistr: attributeGenTemplate :: attributeDistRules: 7 "(" 8 for esf: features join ") | (" { 9 attributeRule(esf) 10 [% List<EStructuralFeature> subFeat = new ArrayList(features); %] 11 [% subFeat.remove(esf); boolean first = true; %] 12 "((" 13 for EStructuralFeature sub: subFeat join ") & (" { 14 "','" attributeRule(sub) 15 } "))" 16 } ")"; Listing 1.5. Ecss model for arbitrary order of declaration (excerpt of arbitrary-order.ecss).
In this section, the process of generating grammars (cfE. 2stienpFigure2) that is followed by the final step (cfE.3), i.e. the generation of executable DSML implementations as illustrated in Fig4u,ries described in detail. The Ecss DSML grammar creator generates grammars based on models by substituting template parameters in style models with actual values and suitable subsequent values.
Rule template association
property rules select root rule template
Class
GeneRrautleed(PGarratm)mar
rule generation Rule Template Application
Rule Template Parameter Values Rule Slots
Rule-specific subrule Parameter extraction
Rule Value Assignment Process
Value property rules select values for slots Value Slots Value Slot Association
Rule Slot Association
For each rule slot association
CCoommppleleteteSSuubbruruleleAAssssooccaatitoionn
PPaararammeeteterrVVaalulueess
RRuuleleTTeemmpplalatete Subrule Parameter Values e.g. features, classes
Distribute Parameters to Slots
Slot association property rules
Rule template association
property rules
Ecss is built on template rules that act as code generating classes that produce code based on values assigned to class fields. Class fields can manifest ai)s d(irectly assigned fields, i.e. field values determined by constructor parameteiris),s(tyled fields, i.e. field values determined by property selectors, anidii)( slot fields, i.e. field values derived from directly assigned fields that are distributed in slots based on priorities computed from the set of available associations between slot and value. Moreover, directly assigned fields may refer to model elements in the input metamodel; the value of styled fields is the result of determining a rule template from the set of available priorities in associations between slot and rule template. The root rule application is selected using template property rules with their root class as a single parameter. In case no root class has been specified, it is automatically determined by selecting the class that contains most other other classes. Next, the variable associations of the rule application are established depending on the rule application class and subsequent parameters may be derived from parameters of the rule. Then, property rules assign property values to rule properties. Next, the priority of slot parameters is calculated using slot value property rules and specific subsequent parameters that are distributed among rule slot priorities and slot multiplicities. Next, the output generating function of the rule application, i.e. defined by values computed in the previous step, is executed and dynamically calls subrules. In detail, most suitable subrule templates, i.e. based on property rules and parameter types, are selected and similarly processed. Priority Computation. Assuming that the claSsstage in our motivating example represents the root class and is converted by employing thewhriutleespaceClassRule (cf. Listing1.4). As a result of the definition ocflassGenTemplate, the variableclass is set to the class parameters and all class features are distributed to slots as follows. First, values for non-slot fields, i.ec.lassname in this case, are computed. AlthouSgthage is a subclass ofNamedElement and therefore both associationsclfaossrname are possible, the association defined by thNeamedElement property rule is chosen due to its higher priority value. Secondly, features are assigned to slots based on defined priority values, i.e. 1.0 if undefined. In our example, the ruleslot(name,name) defines a priority of 2.0 and thus causes the atributneame and remaining atributes to be associated with the slotname and the slotother, respectively. Next, the generation process in our example continues with a call to the rule grnoaumpeDistRules, i.e. with featurneame as parameter, for the non-empty snloatme. Finally, the rulearbitraryDistrRule is prioritised over the ruledefaultAtributeDistr , i.e. imported fromdefault.ecss, due to its priority value being higher by 0.5. Thus, establishing atributeDistRules([engineAmount, engineType, physicalProperties]) as a new rule call that is similarly executed.
In this section we present existing literature on the specification of visual textual representations and diferentiate them with our approach.
In [
Further, 8[] presents a classification of existing concrete textual syntax mapping approaches and identifies a set of issues associated with incremental parsing, model updating, and partial and federated views. This classification distinguishes betwie)en ( manual development or auto-generation of metamodels from existing language grammars, (ii) manual development of grammars based on existing metamodels,iiain)d ( manual development of mappings between existing metamodels and grammars. Accordingly, our approach fits both classificatio ni) (and (ii) and thus can neglectiii().
TCSSL [
hTe Textual Editing Framework (TEF) [
Moreover, an approach that ofers library-based syntactic extensibility based on the Spoofax language workbench has been presented13in]a[nd ofers support for the host languages Java, Haskell, and Prolog. In comparison, grammar-dependent transformations weave and unweave “syntactic sugar” into and out of host language notations, respectively, instead of decoupling style information from abstract domainspecific concepts. Consequently, requiring construction and maintenance of domain metamodel-dependent bi-directional transformations to enable grammar backwardcompatibility instead of liberating language engineers from creation and maintenance of such complex transformations.
EMFText [
A dedicated DSL for the construction of (complex) bridges between grammars and
metamodels is presented in11[
In this work, we proposed an approach for the definition and maintenance of textual notations distinctively and autonomously and implemented the approach through a template language and toolkit for textual style definitions based on EMF and Xtext. Moreover, we showcased the application of our implementation, i.e. involving the creation of domain metamodel-agnostic notational definitions, in a comparison with the model-first approach, i.e. involving the adaptation of (generated) grammar, and indicate usability based on conciseness and expressiveness. Future work incil)udtehse ( application of style models to the set of open-source DSML projects available on opensource software providers, such as Github, to extend findings in regard to the expressiveness and conciseness,ii() the iterative extension of our notational-specification language in regards to the findings ini),(and (iii) the conduction of an empirical user study expanding our findings in regards to the usability of the proposed language. 6.1 Acknowledgements hTis work is supported by the European Commission via the CROSSMINER H2020 project grant number 732223, the Austrian agency for international mobility and cooperation in education, science and research (OeAD) via grand number ICM-2016-04969, the Austrian Research Promotion Agency (FFG) via the Austrian Competence Center for Digital Production (CDP) under the contract number 854187, and the Austrian Federal Ministry for Digital and Economic Afairs, the National Foundation for Research, Technology and Development.