A tool that allows multilevel language engineering and execution.

The XModeler allows multiple levels of classification and enables you to model, program and define new languages – all at the same time.

Create models, program, define your own languages and create corresponding editors on the fly. Navigate through its entire foundation – and change it, if you want.

It enables relaxing essential conflicts of system design and the construction of self-referential information which

  • feature a common representation of models and code
  • provide users with models of the software they use
  • empower users to adapt the system to their needs are aware of the context it operates in


The Need for Conceptual Models

Software systems are linguistic artefacts. Designing, implementing and using them requires languages. For a software system to be executable, the concepts of language for describing software  need to be mapped to the instruction set of processors. Furthermore, the description should be sound in order to foster the software’s reliability. That recommends the use of formal languages. However, formal languages are not sufficient. To make sense of a software system, a linguistic representation is required that corresponds to the language common in the targeted domain.

Conceptual modelling is the approach of choice to establish a correspondence between implementation languages and technical languages used in certain domains. It is based on the idea to use a common ontological foundation both for programming languages and for the reconstruction of domain-specific natural languages. Furthermore, the correspondence depends on common domain-specific designators used for naming concepts in conceptual models. As far as the common ontological foundation is concerned, basic concepts such as entity type, thing, property, event etc. are a good choice. They are used both in philosophical ontologies such as in Bunge’s “furniture of the world” (ref) and in conceptual modelling languages like the ERM or state machines. This common foundation of two separate language worlds enables to create a bridge between them – through conceptual models.


The Object-Oriented Paradigm


During the last decades, one particular language paradigm has gained outstanding relevance. Object-oriented programming languages allow for abstracting the cryptic representation of machine languages away and provide programmers with concepts such as class, object, attribute, etc. At the same time, these concepts form the linguistic foundation of object-oriented modelling languages. Since they correspond to basic concepts of philosophical ontologies, they are suited to reconstruct natural language descriptions of the domain a software system is supposed to represent. Hence, object-oriented models are enabled by two lines of abstraction: on the one hand, there is abstraction from machine code. On the other hand, there is abstraction of natural language descriptions that fades out irrelevant aspects and removes ambiguities.


The object-oriented paradigm does not only foster the correspondence between natural language and program code, it also contributes to reuse and flexibility of software artefacts by providing powerful concepts such as classification, encapsulation, generalization/specialization and polymorphism.



The clear benefits of the object-oriented paradigm are contrasted by two limitations, which may not be obvious at first sight, but have a serious impact on the usability of object-oriented languages. While it may be regarded as convenient that “the objects are there for the picking” (Bertrand Meyer), a language that offers primitive concepts like class and attribute only is a threat to productivity (imagine you would have to read a text like this where every concept was defined from scratch using class, object, attribute etc only) and integrity (an object can be anything, while more specific concepts constrain the number of meaningful sentences they can be used in). This limitation has been known for some time. It inspired the introduction of domain-specific modelling and implementation languages (DSML, DSL), which include domain-specific concepts. Therefore, a modeller or programmer does not have to build these concepts from scratch, but can use them directly.

The second limitation is not necessarily inherent to object-oriented abstractions per se, but to the dominating paradigm of object-oriented programming and modelling languages. According to this paradigm, an object-oriented system is characterized by the dichotomy of objects and classes. A class can be thought of as a template that serves to create objects of a certain kind. As a consequence, a class does not have a state and cannot execute methods. This strict dichotomy of objects and classes has been softened to some extent. To specify classes, a further language level with metaclasses has been introduced. Accordingly, meta-modelling tools allow for the construction of metamodels, which can be instantiated into models that consist of classes or types. However, these extensions did not remove one principal restriction of most object-oriented systems: one system may include objects and classes only, where classes do not have a state. In case of a meta-modelling tool, classes are actually represented as objects, that is, the object layer is overloaded. From a logical point of view, it does not seem convincing to restrict classes to templates only and to limit the representation of software systems to two levels of abstraction (objects and classes) only. Instead, it seems more reasonable to enrich the concept of class to allow for state and the execution of methods:

Specific properties: a class has a certain creation time, it was created by somebody, it may represent a certain version …
Specific values of properties that are shared by all instances of a class, e.g. the resolution of all screens of a certain kind.
Properties that depend on the instances of a class, such as the number of instances, or the average value of a certain property. To avoid redundancy, these properties should be calculated dynamically, which recommends to enable classes to execute methods.
It seems like an arbitrary decision to limit software systems and conceptual models to one classification level only. Classification is a powerful abstraction that enables us to express knowledge about an entire set of objects. Why should we not be allowed to express the knowledge we have knowledge about a set of classes – or meta-classes – accordingly by using further levels of classification?


A new Paradigm provided by XModeler

While object-oriented concepts as they are part of current mainstream languages serve us as a powerful tool to design and implement software systems, the explicit and implicit constraints they come with do not only create the inconsistencies we identified above, they may even prevent us from seeing aspects of the world we did not see before – and from building better systems: “The limits of my language are the limits of my world.” (Wittgenstein) For this principal reason alone, it makes sense to challenge a ruling paradigm, to aim at other, more powerful concepts. Multi-Level Modelling and Language engineering is an attempt to overcome the current object-oriented paradigm by challenging some of its principal foundations. It does not only enable an unlimited number of classification levels, but allows for defining properties of a class that do not directly apply to its instances, but only to instances of instances of instances. As a consequence, it is suited to promote reuse, flexibility, integrity, and user empowerment. However, it also means to give up on (or at least relax) core principles of object-oriented software construction, such as the strict dichotomy of instantiation and specialization or the substitutability constraint of specialization.

Crossing the boundaries of a field you feel familiar with (you have worked in it for long, you were convinced of its power, you preached its foundations) is an exciting, but also risky undertaking. It means to move into unknown territory, to discover new possibilities, but also to run into problems you were not aware of before. It is this kind of scientific adventure that makes the project LE4MM so appealing to us.