This paper presents the versatile language engineering, modeling, and execution environment XModelerML. Starting with the motivation for developing the tool and a brief historical background, the underlying language engineering technology is presented. Subsequently, we give an overview of core concepts of the (meta) modeling language FMMLx that is used for creating models and DSMLs with the XModelerML. Finally, an outline of the components of the XModelerML gives an impression of how to use the tool.
The development of languages, models, and corresponding tools and applications is a demanding undertaking. It often requires expertise and resources that are beyond many organizations capabilities. Reuse is a promising approach to reduce the corresponding efort without the need to compromise on quality. However, reuse is not easy to achieve, since languages, models and applications in general often have to satisfy specific requirements of particular use cases. Apart from reusing existing components, the only way to achieve reuse is to aim at powerful abstractions, which capture commonalities of a wide range of artefacts and, at the same time, support convenient and safe adaptation to specific needs. There are various approaches in software engineering and conceptual modeling that pursue this objective. The abstraction they allow for often depends on the (programming) language they make use of or they were designed for. This is especially the case for the fact that most (object-oriented) languages allow for one classification level only. As a consequence, more abstract knowledge about a class of systems or a domain that would require higher levels of classification can hardly be expressed.
The tool we present in this paper, the XModelerML, is based on a reflexive language architecture that
overcomes this limitation. It provides powerful abstractions over languages, models and tools that do
not only support the eficient realization of custom languages and tools, but also enable new system
architectures that promote reuse, adaptability, integration and user empowerment. The development of
the XModelerMLstarted in 2010 within the project “Language Engineering for Multi-Level Modeling”
(LE4MM) as a collaboration between the universities Duisburg-Essen and Middlesex, London [
The design of the XModelerMLwas motivated by objectives, which to achieve was hardly possible with existing language technologies. The presentation starts with a discussion of these objectives. We will then give an overview of the foundational architecture and present essential benefits from using the XModelerML.
The main reason for choosing the language technology implemented in the XModeler was frustration with prevalent language architectures. Previously the enterprise modeling group at the University of Koblenz and later at the University of Duisburg-Essen had developed a range of languages for enterprise modeling. To foster the use of these languages for analysis and design purposes, various corresponding modeling tools had been developed.
At first, Smalltalk was chosen to this end [
The frustration accumulated through the experience with Java and even with Smalltalk was caused
primarily by the following limitations. For an extensive analysis of limitations inherent to the traditional
language paradigm see [
Lack of expressiveness: It is a pivotal guideline, both for the design of modeling languages and for conceptual modeling in general to express all knowledge one has about a domain at the highest level of abstraction in order to avoid redundancy. It happens frequently that this is not possible with (meta-) modeling languages based on the MOF. The example in Fig. 1 illustrates this limitation. We know that a master thesis is a kind of document. At first, it seems plausible to regard the class MasterThesis as being specialized from the class Document. However, the attribute maxPages in Document is not to be inherited to MasterThesis. Instead, it should be instantiated there to indicate the maximum numbers of pages defined for master theses. Also, we know of documents that particular instances have a page count. Therefore, one should represent this knowledge with the specification of the class Document. However, it is not possible to define that it is to be instantiated only at level 0. to be instantiated on M0 inherited extended
Document created: Date pages: Integer maxPages: Integer
?
MasterThesis created: Date pages: Integer submitted: Date mt1: MasterThesis created = 05-26-2020 pages = 76 submitted = 05-27-2020 to be instantiated directly maxPages = 80 – where to specify?
Limitations of DSML design: This is a special case of the previous limitation. It occurs frequently with the design of modeling languages and is especially annoying, if the models created with a modeling Periph output: B input: Boo salesPrice: partSalesP serialNo: S noOfMod
Pr salesPrice: partSalesP serialNo: pagePerMi resolution:
CP partSales serialNo: language should be further instantiated. To this end, a process modeling language should include the knowledge we have about specific properties of process instances. For example, every process instance has a start time and a termination time. Aparently, this obvious knowledge cannot be expressed with a metaclass that is used for the specification of a modeling language.
Pitfalls of model-driven development: Model-driven software development is an appealing idea. It advocates to focus on modeling and do without coding as much as possible. Finally, when the models are complete, code is generated. While this seems like a convincing approach to software development, it sufers from a serious drawback: during its lifetime, a software system has to be adapted to new requirements. No matter whether changes are applied to the code – which will often be the case – or to the corresponding models, in any case both representations need to be synchronized, if one does not want to give up on the benefits of having an up to date model.
The example in Fig. 2 makes clear why code generation is necessary in the traditional language paradigm. While the concepts represented by a model will usually be at M1 or higher, modeling tools implemented with traditional languages do not allow for representing them there. Instead, they have to be located as objects as M0.
M2
M1
Class Attribute name: String includes name: String 0,* isAbstract: Boolean 1,1 0,* type: String specializedFrom represents class on M1
0,1 M1
M0
generate
Customer firstName: String lastName: String custID: String dateOfBirth: Date yearsOfAge() : Integer represented as object on M0
M M conceptual level actual implementation level
Dissatisfactory integration of models and software: This limitation is directly related to the previous
one. To empower users of a complex application system such as an ERP system, it would be useful to
tightly integrate the system with the conceptual models, it is based on. In an ideal case, users could
then navigate from the application they use to the corresponding models. By changing the models they
could modify the software. This vision of “self-referential enterprise systems” [
The development of the XModelerML was mainly motivated by these obstacles imposed by traditional (meta) modeling and programming languages. To overcome these obstacles a language architecture was required that allows for multiple, better: an arbitrary number of classifications, and that, thus, allows for a common representation of models and code. The language architecture that builds on XCore and XOCL and that is provided by the XModeler (see below) proved to serve as a powerful foundation for achieving this objective.
XModeler has been designed for language engineering, both in terms of model-based languages and
text-based languages, and their associated tools. To achieve this it is based on XCore, which is a small
meta-circular meta model that is shown in figure 3. For a simplified representation of XCore see [
The XOCL language is implemented as a concrete language on top of XCore. Most of XModeler is written in XOCL. It is also suitable for creating executable models of systems. XEditor is a tool that is written for working with text-based languages that are implemented in XCore. A typical executable model written in XOCL and its associated diagram is shown in figure 4.
The XModelerML features a multi-level (meta) modeling language, the FMMLx [
The XModelerML allows to overcome the obstacles imposed by traditional modeling and programming languages. It ofers clearly more expressiveness by allowing for an arbitrary number of classification levels and for deferred instantiation (see, e.g., the attribute salesPrice of the class Product at level 3 in in Fig. 5). Last but not least, models created with the FMMLx are fully executable. The common distinction between models and code does not exist anymore, since both share the same representation.
It also enables a more eficient specification of DSMLs. The specification of a DSML within the XModelerML is illustrated in a screencast provided at the project webpages (www.le4mm.org/ xmodelerml). DSMLs can be defined at any level of classification. For example, a DSML that represents general characteristics of products could be defined at level 4, and then used to specify a more specific DSML to model vehicles, which would start at level 3, but also comprise more specific concepts such as vehicle models at level 2. As a consequence, the distinction between modeling language, model and instantiations of models is overcome, since a model designed with the FMMLx may include classes at diferent classification levels. This corresponds directly to the use of concepts in natural language, where
a sentence may refer to concepts at diferent levels of abstraction as well as to particular exemplars. For language designers, modelers and model users, this architecture creates obvious advantages. Language designers are no longer forced to develop new languages from scratch using generic concepts such as Class or Attribute.
Instead, they can use a more general, yet domain-specific language, to define a more specific one. Modelers can navigate to the language they use (it can be part of the same model) at runtime. They can also instantiate a model at runtime, which may give valuable feedback for their design decisions. Finally, this architecture gives users of an application system the opportunity to navigate to the conceptual model of the system they work with at runtime, and change the model (if they are authorized to do so). By changing the model, they would directly change the system.
With the XModelerML, the notorious synchronization of models and code is widely obsolete. All classes specified with the FMML x are specified and implemented (!) at the level where they conceptually belong. Hence, they can be instantiated within a model editor without the need for code generation.
The XModelerML consists of various components that allow accessing, manipulating and executing a model from diferent perspectives. With each model a corresponding diagram editor is generated. In addition to allow for creating and modifying models, it also allows for executing models. If the execution of a model results in changes of the diagram, these are directly shown in the editor.
Developers that prefer textual representations over graphical ones may use an instance of the model browser. It can operate on the same model that is also used by an instance of the diagram editor at the same time. In case the default notation of the FMMLx (see Fig. 5) is not satisfactory, the concrete syntax editor serves the specification of notations by arranging pre-defined SVGs and text elements. After a notation has been defined, it can directly be used by the diagram editor.
The workspace allows to interact with and manipulate model elements, e.g. for testing purposes, using a command line editor. Two components serve the realization of application style GUIs to interact with models. An object browser can be generated for every class in a model. It is composed of widgets such as text or list boxes that serve the presentation of instances of the selected class. The GUIs created by the object browser are restricted to objects of one class and lack a user-friendly layout of widgets. The GUI builder overcomes this restriction. It transparently sends a model to an external GUI builder, which allows to modify a generated GUI. After the GUI was redesigned, it is transparently sent back to the XModelerML, where it can be used immediately to interact with the corresonding model. model browser diagram editor
instance browser console control center
Fig. 6 shows examples of the diagram editor, the model browser, the workspace and the object browser. It also shows the control center, which, among other things, serves to load models, to start diagram editors or access the workspace.
The project webpages at www.le4mm.org ofer a wide range of resources on the XModeler ML, including publications, screencasts and downloads of the latest build as well as example models. Multilevel modeling represents a new language paradigm. As a consequence, using the FMMLx may be perceived as demanding at first. Therefore, it will often be a good idea to start with using the FMML x as a kind of UML class diagram editor. One would then create a UML class diagram which could be directly instantiated, and executed, within the diagram editor (see screencast at www.le4mm.org/xmodelerml/ #UML-pp). Subsequently, one could continue with creating a first multi-level model to then subsequently raise the level of abstraction (screencast at www.le4mm.org/xmodelerml).
Research on multi-level modeling has resulted in various languages and tools, e.g., [
In conjunction with the language engineering facitilities provided by XModeler and XOCL, it enables a powerful foundation not only for the development of modeling languages and model editors, but also for a new generation of self-reflexive application systems. While still in the state of a research prototype, we believe the XModelerML allows to experience the benefits of multi-level modeling and software development in a fairly convenient way.
At the same time, multi-level modeling is a research subject that ofers attractive perspectives.
These include the development of hierarchies of DSMLs where higher level DSMLs promise attractive
economies of scale where more specific DSMLs serve to address particular needs [