The Experts below are selected from a list of 5985 Experts worldwide ranked by ideXlab platform
Agris Sostaks - One of the best experts on this subject based on the ideXlab platform.
-
Towards Concrete Syntax Based Find for Graphical Domain Specific Languages
2019 ACM IEEE 22nd International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), 2019Co-Authors: Elina Kalnina, Agris SostaksAbstract:One of the main reasons why Model-Driven Engineering (MDE) technologies including Domain-specific modelling languages (DSML) have not reached the expected acceptance in the industry is a poor tool support. One of the features with a limited support even in commercial modelling tools is search (find). Typically, MDE tools support only a simple keyword-based textual search functionality. The same is true for the tools built using Domain-specific language (DSL) tool definition frameworks. It is proposed to provide the Concrete Syntax-based find functionality as a service of a DSL tool definition framework. The find diagrams are defined in a Concrete Syntax of a DSL. A definition of a DSL is used to provide a language-specific find functionality in the DSL tool.
-
MODELS Companion - Towards Concrete Syntax Based Find for Graphical Domain Specific Languages
2019 ACM IEEE 22nd International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), 2019Co-Authors: Elina Kalnina, Agris SostaksAbstract:One of the main reasons why Model-Driven Engineering (MDE) technologies including Domain-specific modelling languages (DSML) have not reached the expected acceptance in the industry is a poor tool support. One of the features with a limited support even in commercial modelling tools is search (find). Typically, MDE tools support only a simple keyword-based textual search functionality. The same is true for the tools built using Domain-specific language (DSL) tool definition frameworks. It is proposed to provide the Concrete Syntax-based find functionality as a service of a DSL tool definition framework. The find diagrams are defined in a Concrete Syntax of a DSL. A definition of a DSL is used to provide a language-specific find functionality in the DSL tool.
-
Generation Mechanisms in Graphical Template Language
2017Co-Authors: Elina Kalnina, Agris Sostaks, Audris Kalnins, Edgars Celms, Janis IraidsAbstract:Textual models in MDD typically are generated in their Concrete Syntax using a template based language. On the contrary, graphical models as a rule are generated in abstract Syntax and then visualized, which is not very efficient for complicated languages. The paper discusses a case of template based generation of graphical models in a Concrete Syntax. We apply this approach to generation of programs in MOLA transformation language using the Template MOLA language. A novel idea of merge mechanism in MOLA templates is proposed which permits to obtain the required structure of generated models in an easy way.
Elina Kalnina - One of the best experts on this subject based on the ideXlab platform.
-
Towards Concrete Syntax Based Find for Graphical Domain Specific Languages
2019 ACM IEEE 22nd International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), 2019Co-Authors: Elina Kalnina, Agris SostaksAbstract:One of the main reasons why Model-Driven Engineering (MDE) technologies including Domain-specific modelling languages (DSML) have not reached the expected acceptance in the industry is a poor tool support. One of the features with a limited support even in commercial modelling tools is search (find). Typically, MDE tools support only a simple keyword-based textual search functionality. The same is true for the tools built using Domain-specific language (DSL) tool definition frameworks. It is proposed to provide the Concrete Syntax-based find functionality as a service of a DSL tool definition framework. The find diagrams are defined in a Concrete Syntax of a DSL. A definition of a DSL is used to provide a language-specific find functionality in the DSL tool.
-
MODELS Companion - Towards Concrete Syntax Based Find for Graphical Domain Specific Languages
2019 ACM IEEE 22nd International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C), 2019Co-Authors: Elina Kalnina, Agris SostaksAbstract:One of the main reasons why Model-Driven Engineering (MDE) technologies including Domain-specific modelling languages (DSML) have not reached the expected acceptance in the industry is a poor tool support. One of the features with a limited support even in commercial modelling tools is search (find). Typically, MDE tools support only a simple keyword-based textual search functionality. The same is true for the tools built using Domain-specific language (DSL) tool definition frameworks. It is proposed to provide the Concrete Syntax-based find functionality as a service of a DSL tool definition framework. The find diagrams are defined in a Concrete Syntax of a DSL. A definition of a DSL is used to provide a language-specific find functionality in the DSL tool.
-
Generation Mechanisms in Graphical Template Language
2017Co-Authors: Elina Kalnina, Agris Sostaks, Audris Kalnins, Edgars Celms, Janis IraidsAbstract:Textual models in MDD typically are generated in their Concrete Syntax using a template based language. On the contrary, graphical models as a rule are generated in abstract Syntax and then visualized, which is not very efficient for complicated languages. The paper discusses a case of template based generation of graphical models in a Concrete Syntax. We apply this approach to generation of programs in MOLA transformation language using the Template MOLA language. A novel idea of merge mechanism in MOLA templates is proposed which permits to obtain the required structure of generated models in an easy way.
Eelco Visser - One of the best experts on this subject based on the ideXlab platform.
-
SLE - Interactive disambiguation of meta programs with Concrete object Syntax
Software Language Engineering, 2011Co-Authors: Lennart C. L. Kats, Karl Trygve Kalleberg, Eelco VisserAbstract:In meta-programming with Concrete object Syntax, meta programs can be written using the Concrete Syntax of manipulated programs. Quotations of Concrete Syntax fragments and anti-quotations for meta-level expressions and variables are used to manipulate the abstract representation of programs. These small, isolated fragments are often ambiguous and must be explicitly disambiguated with quotation tags or types, using names from the non-terminals of the object language Syntax. Discoverability of these names has been an open issue, as they depend on the (grammar) implementation and are not part of the Concrete Syntax of a language. Based on advances in interactive development environments, we introduce interactive disambiguation to address this issue, providing real-time feedback and proposing quick fixes in case of ambiguities.
-
Interactive disambiguation of meta programs with Concrete object Syntax
2010Co-Authors: C.l. Kats, Karl Trygve Kalleberg, Eelco VisserAbstract:In meta-programming with Concrete object Syntax, meta programs can be written using the Concrete Syntax of manipulated programs. Quotations of Concrete Syntax fragments and anti-quotations for meta-level expressions and variables are used to manipulate the abstract representation of programs. These small, isolated fragments are often ambiguous and must be explicitly disambiguated with quotation tags or types, using names from the non-terminals of the object language Syntax. Discoverability of these names has been an open issue, as they depend on the (grammar) implementation and are not part of the Concrete Syntax of a language. Based on advances in interactive development environments, we introduce interactive disambiguation to address this issue, providing real-time feedback and proposing quick fixes in case of ambiguities This paper is a pre-print of: Proceedings of the 3rd International Conference of Software Language Engineering (SLE 2010), Eindhoven (The Netherlands) 12-13 Oct. 2010, Lecture Notes in Computer Science, Springer, 2010
-
interactive disambiguation of meta programs with Concrete object Syntax
Software Language Engineering, 2010Co-Authors: Lennart C. L. Kats, Karl Trygve Kalleberg, Eelco VisserAbstract:In meta-programming with Concrete object Syntax, meta programs can be written using the Concrete Syntax of manipulated programs. Quotations of Concrete Syntax fragments and anti-quotations for meta-level expressions and variables are used to manipulate the abstract representation of programs. These small, isolated fragments are often ambiguous and must be explicitly disambiguated with quotation tags or types, using names from the non-terminals of the object language Syntax. Discoverability of these names has been an open issue, as they depend on the (grammar) implementation and are not part of the Concrete Syntax of a language. Based on advances in interactive development environments, we introduce interactive disambiguation to address this issue, providing real-time feedback and proposing quick fixes in case of ambiguities.
-
Concrete Syntax for objects domain specific language embedding and assimilation without restrictions
Conference on Object-Oriented Programming Systems Languages and Applications, 2004Co-Authors: Martin Bravenboer, Eelco VisserAbstract:Application programmer's interfaces give access to domain knowledge encapsulated in class libraries without providing the appropriate notation for expressing domain composition. Since object-oriented languages are designed for extensibility and reuse, the language constructs are often sufficient for expressing domain abstractions at the semantic level. However, they do not provide the right abstractions at the syntactic level. In this paper we describe MetaBorg, a method for providing Concrete Syntax for domain abstractions to application programmers. The method consists of embedding domain-specific languages in a general purpose host language and assimilating the embedded domain code into the surrounding host code. Instead of extending the implementation of the host language, the assimilation phase implements domain abstractions in terms of existing APIs leaving the host language undisturbed. Indeed, MetaBorg can be considered a method for promoting APIs to the language level. The method is supported by proven and available technology, i.e. the Syntax definition formalism SDF and the program transformation language and toolset Stratego/XT. We illustrate the method with applications in three domains: code generation, XML generation, and user-interface construction.
-
retrofitting the autobayes program synthesis system with Concrete Syntax
Lecture Notes in Computer Science, 2004Co-Authors: Bernd Fischer, Eelco VisserAbstract:AutoBayes is a fully automatic, schema-based program synthesis system for statistical data analysis applications. Its core component is a schema library, i.e., a collection of generic code templates with associated applicability constraints which are instantiated in a problem-specific way during synthesis. Currently, AutoBayes is implemented in Prolog; the schemas thus use abstract Syntax (i.e., Prolog terms) to formulate the templates. However, the conceptual distance between this abstract representation and the Concrete Syntax of the generated programs makes the schemas hard to create and maintain.
Frédéric Fondement - One of the best experts on this subject based on the ideXlab platform.
-
Model-driven analysis and synthesis of textual Concrete Syntax
Software & Systems Modeling, 2008Co-Authors: Pierre-alain Muller, Michel Hassenforder, Rémi Schnekenburger, Frédéric Fondement, Franck Fleurey, Sebastien Gerard, Jean-marc JézéquelAbstract:Meta-modeling is raising more and more interest in the field of language engineering. While this approach is now well understood for defining abstract Syntaxes, formally defining textual Concrete Syntaxes with meta-models is still a challenge. Textual Concrete Syntaxes are traditionally expressed with rules, conforming to EBNF-like grammars, which can be processed by compiler compilers to generate parsers. Unfortunately, these generated parsers produce Concrete Syntax trees, leaving a gap with the abstract Syntax defined by meta-models, and further ad hoc hand-coding is required. In this paper we propose a new kind of specification for Concrete Syntaxes, which takes advantage of meta-models to generate fully operational tools (such as parsers or text generators). The principle is to map abstract Syntaxes to textual Concrete Syntaxes via bidirectional mapping-models with support for both model-to-text, and text-to-model transformations.
-
graphical Concrete Syntax rendering with svg
European conference on Model driven architecture-foundations and applications, 2008Co-Authors: Frédéric FondementAbstract:Model-based techniques place modeling at the cornerstone of software development. Because of the large number of domains and levels of abstraction one can find in software systems, a large number of modeling languages is necessary. Modeling languages need to be properly defined regarding Concrete Syntax in addition to abstract Syntax and semantics. Most modeling languages use a graphical Concrete Syntax, and solutions to model those Syntaxes appeared. If those solutions are convincing to support the rapid development of graphical modeling tools, they are often restrictive in the range of possible Concrete Syntaxes for a given abstract Syntax, and rely on dedicated technologies. In previous works, we proposed such a solution based on a representation model which was more flexible in that it abstracted away purely graphical concerns. Those concerns include actual design for representation icons, how the design reacts to representation variations within the icons, possible interactions with an icon, and synchronization between the graphical representation and the graphical model. In this paper, we show how to solve those four last points using the SVG open standard for vector graphics. We propose to define representation icons by SVG templates complemented by layout constraints, a predefined and extensible library of possible user interactions using DOM, and a specific approach based on events to synchronize the graphical representation with the graphical model. Thus, our solution solves the Concrete realization of an modeling environment cumulating advantages of a clear separation between abstract and Concrete Syntaxes at the modeling level, while benefiting from the expertise of the vector graphics community.
-
Concrete Syntax definition for modeling languages
2007Co-Authors: Frédéric FondementAbstract:Model Driven Engineering (MDE) promotes the use of models as primary artefacts of a software development process, as an attempt to handle complexity through abstraction, e.g. to cope with the evolution of execution platforms. MDE follows a stepwise approach, by prescribing to develop abstract models further improved to integrate little by little details relative to the final deployment platforms. Thus, the application of an MDE process results in various models residing at various levels of abstraction. Each one of these models is expressed in a modeling language, in which one may find appropriate concepts for the abstraction level considered. Many advocate to use the right (modeling) language for the right purpose. This means that it is sometimes better approach to use small languages specific to the considered domain and abstraction level, than to use general purpose languages (e.g. UML) when they do not perfectly fit the (modeling) needs. As a matter of fact, an MDE development process, which involves many different domains and abstraction levels, should also involve a large variety of modeling languages. Project managers who want to apply an MDE process need to deal with this language proliferation to such an extent that, in the long run, one may infer that language engineers can become major actors of software development teams. We believe that comprehensive modeling language management facilities may considerably alleviate that MDE drawback. Such facilities may include modeling language definition, extension, adaptation, or composition. To define a (modeling) language, one needs to define its abstract Syntax, its semantics, and one or more Concrete Syntaxes. This thesis focuses on Concrete Syntax definition for modeling languages, when the abstract Syntax is given in the form of a metamodel. We will provide solutions both for textual and graphical Concrete Syntaxes. Some of our experiences in building textual languages (as MTL, a model transformation language), and graphical languages (as Netsilon, a web-application modeler) has shown that a lot of work was spent in implementing interface using traditional techniques, be it a text processor generated from a compiler compiler specification, or a modeler making use of modern 2D graphical libraries. Indeed, abstract and Concrete Syntax were implemented in a disconnected way, and it was then necessary to assemble them, which became rapidly clumsy while abstract Syntax evolved. We built our solution to Concrete Syntax definition as companions of the abstract Syntax. The definition of Concrete Syntax we propose here made it possible to build automatic tools able to analyze or synthesize models from/to text, and to create graphical modelers. We will present a metamodel for textual Concrete Syntax definition to construct constructive reversible grammars. We will also propose a technique for graphical Concrete Syntax definition following a two-step process: specification and realization. Specification is a restrictive approach in which a metamodel defines a graphical Concrete Syntax. Both relations with abstract Syntax and spatial relationships are expressed by means of constraints. The realization step proposes a way to provide the Concrete Syntax tree a meaning, by attributing it a graphical appearance, and by expressing possible user interactions. The structure of the document is the following. After introducing in deeper details the problem and the general structure of the solution we propose, we will take a tour of MDE, text and graph grammars. Then, we will present Netsilon as an example of an MDE tool to MDE development, which required both the definition of a graphical and a textual modeling language. The two following sections will present the solutions we propose for textual and graphical Concrete Syntax definition, respectively. Final remarks and possible improvements, especially regarding reusability in general of MDE meta-artifacts (like metamodels or model transformations), and of Concrete Syntax in particular, will conclude the document.
-
Model-driven analysis and synthesis of Concrete Syntax
2006Co-Authors: Pierre-alain Muller, Michel Hassenforder, Frédéric Fondement, Franck Fleurey, Sebastien Gerard, Rémi Schneckenburger, Jean-marc JézéquelAbstract:Metamodeling is raising more and more interest in the field of language engineering. While this approach is now well understood for defining abstract Syntaxes, formally defining Concrete Syntaxes with metamodels is still a challenge. Concrete Syntaxes are traditionally expressed with rules, conforming to EBNF-like grammars, which can be processed by compiler compilers to generate parsers. Unfortunately, these generated parsers produce Concrete Syntax trees, leaving a gap with the abstract Syntax defined by metamodels, and further ad-hoc hand-coding is required. In this paper we propose a new kind of specification for Concrete Syntaxes, which takes advantage of metamodels to generate fully operational tools (such as parsers or text generators). The principle is to map abstract Syntaxes to Concrete Syntaxes via bidirectional mapping-models with support for both model-to-text, and text-to-model transformations.
-
Metamodel-Aware Textual Concrete Syntax Specification
2006Co-Authors: Frédéric Fondement, Rémi Schnekenburger, Sebastien Gerard, Pierre-alain MullerAbstract:Metamodeling is raising more and more interest in the field of language engineering. While this approach is now well understood for the definition of abstract Syntaxes, the formal definition of Concrete Syntaxes is still a challenge. Concrete Syntaxes are traditionally expressed with rules, conforming to EBNF-like grammars, which can be processed by compiler compilers to generate parsers. Unfortunately, these generated parsers produce Concrete Syntax trees, leaving a gap with the abstract Syntax defined by metamodels. This gap is usually filled by time consuming ad-hoc hand-coding. In this paper we propose a new kind of specification for Concrete Syntaxes that takes advantage of metamodels to generate tools (such as parsers or text generators) which directly manipulate abstract Syntax trees. The principle is to map abstract Syntaxes to Concrete Syntaxes via EBNF-like rules that explain how to render an abstract concept into a given Concrete Syntax, and how to trigger other rules to handle the properties of the concepts. The major difference with EBNF is that rules may have sub-rules, which can be automatically triggered based on the inheritance hierarchy of the abstract Syntax concepts.
Thomas Baar - One of the best experts on this subject based on the ideXlab platform.
-
Correctly defined Concrete Syntax
Software & Systems Modeling, 2008Co-Authors: Thomas BaarAbstract:Due to their complexity, the Syntax of modern modeling languages is preferably defined in two steps. The abstract Syntax identifies all modeling concepts whereas the Concrete Syntax should clarify how these concepts are rendered by graphical and/or textual elements. While the abstract Syntax is often defined in form of a metamodel, there does not exist such standard format yet for Concrete Syntax definitions. The diversity of definition formats—ranging from EBNF grammars to informal text—is becoming a major obstacle for advances in modeling language engineering, including the automatic generation of editors. In this paper, we propose a uniform format for Concrete Syntax definitions. Our approach captures both textual and graphical model representations and even allows to assign more than one rendering to the same modeling concept. Consequently, following our approach, a model can have multiple, fully equivalent representations, but—in order to avoid ambiguities when reading a model representation—two different models should always have distinguishable representations. We call a Syntax definition correct, if all well-formed models are represented in a non-ambiguous way. As the main contribution of this paper, we present a rigorous analysis technique to check the correctness of Concrete Syntax definitions.
-
on the usage of Concrete Syntax in model transformation rules
International Andrei Ershov Memorial Conference on Perspectives of System Informatics, 2006Co-Authors: Thomas Baar, Jon WhittleAbstract:Graph transformations are one of the best known approaches for defining transformations in model-based software development. They are defined over the abstract Syntax of source and target languages, described by metamodels. Since graph transformations are defined on the abstract Syntax level, they can be hard to read and require an in-depth knowledge of the source and target metamodels. In this paper we investigate how graph transformations can be made much more compact and easier to read by using the Concrete Syntax of the source and target languages. We illustrate our approach by defining model refactorings.
-
Correctly defined Concrete Syntax for visual modeling languages
Lecture Notes in Computer Science, 2006Co-Authors: Thomas BaarAbstract:The Syntax of modeling languages is usually defined in two steps. The abstract Syntax identifies modeling concepts whereas the Concrete Syntax clarifies how these modeling concepts are rendered by visual and/or textual elements. While the abstract Syntax is often defined in form of a metamodel there is no such standard format yet for Concrete Syntax definitions; at least as long as the Concrete Syntax is not purely text-based and classical grammar-based approaches are not applicable. In a previous paper, we proposed to extend the metamodeling approach also to Concrete Syntax definitions. In this paper, we present an analysis technique for our Concrete Syntax definitions that detects inconsistencies between the abstract and the Concrete Syntax of a modeling language. We have implemented our approach on top of the automatic decision procedure SIMPLIFY.
-
MoDELS - Correctly defined Concrete Syntax for visual modeling languages
Model Driven Engineering Languages and Systems, 2006Co-Authors: Thomas BaarAbstract:The Syntax of modeling languages is usually defined in two steps. The abstract Syntax identifies modeling concepts whereas the Concrete Syntax clarifies how these modeling concepts are rendered by visual and/or textual elements. While the abstract Syntax is often defined in form of a metamodel there is no such standard format yet for Concrete Syntax definitions; at least as long as the Concrete Syntax is not purely text-based and classical grammar-based approaches are not applicable. In a previous paper, we proposed to extend the metamodeling approach also to Concrete Syntax definitions. In this paper, we present an analysis technique for our Concrete Syntax definitions that detects inconsistencies between the abstract and the Concrete Syntax of a modeling language. We have implemented our approach on top of the automatic decision procedure Simplify.
-
making metamodels aware of Concrete Syntax
European conference on Model driven architecture-foundations and applications, 2005Co-Authors: Frédéric Fondement, Thomas BaarAbstract:Language-centric methodologies, triggered by the success of Domain Specific Languages, rely on precise specifications of modeling languages. While the definition of the abstract Syntax is standardized by the 4-layer metamodel architecture of the OMG, most language specifications are held informally for the description of the semantics and the (graphical) Concrete Syntax. This paper is tackling the problem of specifying the Concrete Syntax of a language in a formal and non-ambiguous way. We propose to define the Concrete Syntax by an extension of the already existing metamodel of the abstract Syntax, which describes the concepts of the language, with a second layer describing the graphical representation of concepts by visual elements. In addition, an intermediate layer defines how elements of both layers are related to each other. Unlike similar approaches that became the basis of some CASE tools, the intermediate layer is not a pure mapping from abstract to Concrete Syntax but connects both layers in a flexible, declarative way. We illustrate our approach with a simplified form of statecharts.