MetaEdit+ DSM Environment by company MetaCase is a commercial language workbench that in contrast to inflexible CASE tools, enables users to build their own modeling and code generation tools (aka DSM tools). It comes in two main product components:

  • MetaEdit+ Modeler provides customizable DSM functionality for multiple users, multiple projects, running on all major platforms.
  • MetaEdit+ Workbench i) allows building custom modeling languages (DSLs), and text generators and 2) includes the functionality of MetaEdit+ Modeler and MetaEdit+ API (the latter is not reviewed in this document).

This review is written from the MDE perspective and will cover major MDE functionally related to specification of modeling languages. For a complete picture of MetaEdit+, readers are advised to consider other aspects (e.g. collaboration, versioning, etc…) as well.This review covers MetaEdit+ Workbench version 4.5.

Language Specification


MetaEdit+ supports graph-like visual languages represented as diagrams, matrixes or tables. There is a limited support for spatial languages: touch and containment relationships are derived from canvas coordinates of modeling elements. There is no actual tool support to preserve these relationships: for example, as a modeller moves a “container” element, contained elements do not move along as expected, but remain at old coordinates.In MetaEdit+, languages are specified with a set of specialized tools. In the following, we describe the tools per each aspect of the visual language definition: abstract syntax, concrete syntax, static and dynamic semantics.

Abstract Syntax

This aspect is defined with GOPPRR metatypes. GOPPRR is an acronym for metatypes Graph, Object, Property, Port, Role and Relationship. For each metatype, there is a form-based tool, e.g. Object tool allows specification of object types  and Graph tool allows assembling types produced with the other tools into a specification of abstract syntax. GOPPRR tools support single inheritance.Graph tool also allows linking DSL objects to graphs of other DSLs through decomposition and explosion structures. Furthermore, through sharing language concepts (of any OPPRR metatype) among graphs, DSLs can be integrated so that changes in one model can be automatically reflected in models based on different languages.An alternative to these form-based tools for abstract syntax specification is a visual metamodeling DSL. However, this functionality is best used as easy start-up leading to automated generation of barebone GOPPRR metamodels. Once a language developer changes a GOPPRR metamodel (which is inevitable), visual metamodeling is best discontinued to avoid manual round-trip between the two metamodels.

Concrete Syntax

By default, MetaEdit+ provides generic symbols. However, language developers are free to specify custom symbols for objects, roles and relationships. These symbols are either defined with a WYSIWYG vector drawing tool or imported from vector graphics (SVG) or bitmap files. Symbols can display text, property values and dynamic outputs produced by text generators (more on generators in section M2T Transformation). Moreover, symbols or their parts can be conditionally displayed. Finally, symbols can be reused among different DSLs via a symbol library.MetaEdit+ does not directly support multiple concrete syntaxes per language, which (the lack of such support) is still a common practice among language workbenches. However, its capability to display symbols based on conditions allows to work around this limitation.

Static Semantics

This aspect covers constraints and business rules. The purpose of these rules is to ensure a consistent and valid model.In general, DSM tools should verify a model against the static semantics of its DSL at different times. These times can be classified as ‘live’ (i.e. when a user is modelling) and ‘batch’ (i.e. invoked on events caused by actions such as user demand, model saving or transformation). Furthermore, tool actions following violation of a constraint can be classified as prevention (i.e. a violating action is canceled and a warning message is displayed) or merely informative (i.e. a violating action is allowed, but model will display clues about invalid constructions until the effect of the action is corrected).MetaEdit’s Constraint tool (available from the Graph tool) allows ‘live’ checks against constraints and preventive protection of models (‘live’ and ‘preventive’ in the terms of the above classifications). The tool is very expressive and easy to use, but covers only limited number of types of constraints, namely:

  • object connectivity in a relationship
  • object occurrence in a model
  • ports involved in a relationship
  • property uniqueness

More advanced constraints have to rely on MERL generator (see section M2T Transformation), which can inform users about invalid constructions during modeling (‘live’ and ‘informative’ in the terms of the above classifications). MERL generator can also be used for ‘batch informative’ and ‘batch preventive’ checks: a checking report can be run on demand or included as preventive check before any other transformation is carried out.

Dynamic Semantics

MetaEdit+ can define dynamic semantics through a process of translating DSL concepts to concepts in another target domain with defined dynamic semantics. Examples of target domains in code generation applications are e.g. C++ or Java. A major benefit of language workbenches is that they are capable of automating this and other useful kinds of processes.


MDE applications need capabilities to automate processes in which models are inputs and outputs. MetaEdit+ provides various levels of support for model-to-model (M2M), model-to-text (M2T) (e.g. in code generation applications) and text-to-model (T2M) (import of legacy code, data type definitions, etc. into models) types of transformations. (The latter transformation type is not reviewed.)

M2T Transformation

Text (and more specifically code) generation is accomplished with Generator tool that can efficiently navigate models, filter and access information, and output text into external files, Generator Output tool and DSL symbols.  All these tasks are specified with imperative language MERL. While MERL is very concise and efficient for most of these tasks, I think that navigation and access tasks are better accomplished in a declarative way.MERL generators are defined per graph type (i.e. per DSL) and can be acquired from supertypes of a given graph type via an inheritance hierarchy. If a generator has to be used for different graph types, then the generator should be defined for the common parent graph type. On the other hand, DSL developer can define new or redefine generators already provided by parent graph types.Finally, MERL provides support for modularization by allowing includes of generators in other generators. Making modular generators pays off well, as there are many reuse opportunities in MetaEdit+: generators can be reused not only for text generation but also in concrete syntax (symbols) and validation/reporting purposes (symbols, generator output tool).

M2M Transformation

Models can be transformed 1) programmatically via the SOAP and WebServices-based API of MetaEdit+ (this option requires product component MetaEdit+ API) or 2) through code generation of an intermediate external representation (in the XML format) and consequent import thereof as new model.These two options amount to a generic support at a minimum level that is commonly provided nearly by all language workbenches. Moreover, code generation of an intermediate representation cannot implement in-place M2M transformations, of which application examples are: model optimization, model layout, model interpretation, model weaving and any repeatable model manipulation in general.


  • DSL evolution: MetaEdit+ updates existing models instantly yet non-destructively to reflect changes in DSLs.  The update policy ensures that models created with the older DSL versions are not broken and remain usable with existing generators. Instant update is also very useful when fine-tuning a DSL with end users.
  • According to MetaCase, a MetaEdit+ project can hold over 4 billion objects. A typical project would contain about 40-100 models (graphs).
  • In the multi-user version, users can simultaneously access and share all models within a Repository. Locking is made at the object-level, so several users could collaboratively work on the same model at the same time.
  • Multi-user collaboration in MetaEdit+, product line analysis of commonality and variability and proper separation of concerns reduce the need for version control as it is known in software engineering. Therefore MetaEdit+ does not provide its own versioning system. Best practices for versioning with MetaEdit+ can be found here.
  • Model interoperability: by default, all models and DSLs can be exported in an XML format. The schemas are very simple, which make it easy to post-process such files if needed. Moreover, the M2T transformation capabilities of MetaEdit+ enable DSL developers to easily create custom export generators.


MetaEdit+ is a versatile language workbench that enables building high quality visual DSLs for any kind of domain, be it technical or business. Another key quality of MetaEdit+ is efficient DSL/GOPPRR tools, which allow light-weight, agile and fast DSL development and evolution. A testament to this quality is the fact that MetaCase is one of few language workbench makers that routinely designs and builds DSLs in improvisation with audience at conferences, workshops, etc. In my opinion, this impressive productivity is possible because GOPPRR tools are based on paradigms that are optimum for DSL development (DSM for DSM so to speak).Highlights of MetaEdit+ are:

  • Proper level of abstraction: DSL developers are completely shielded from details of how DSM-tools are implemented. DSL development tools focus on essential abstractions for specification of languages and generators.
  • High-levels of automation: DSM-tools are completely and automatically generated from abstract language specifications.
  • High quality of tools: each DSL development task has its own dedicated tool.
  • Numerous enhancements: high integration of tools, non-destructive evolution of languages, inheritance mechanism, reuse opportunities for types, symbols and generators, visual metamodeling, etc.
  • Very cheap introductory license.

Naturally, there are a few drawbacks as well:

  • No specific support for model-to-model transformation.
  • Somewhat limited constraints support.
  • Limited support for spatial relations.
  • Uncommon user interface.
  • Form-based GOPPRR tools prevent a global overview of a metamodel.
  • Expensive  standard licenses.

Code generation applications are the oldest tradition in MDE and this is where MetaEdit+ excels. As MDE discovers new applications, my experience is that the code generation specialization becomes restrictive. Admittedly, it is possible to implement some types of M2M transformations with code generation (via intermediate representation). However, the problem with this workaround is that it introduces accidental complexity both to MDE developers and more importantly to end users (that have to keep repeating the generate/import routine, sometimes complicated by model merge).That said, in my opinion MetaEdit+ gets the big things right. Whether its shortcomings are little things is a subjective matter that is best evaluated in the context of a concrete problem domain.


In MDD explicit knowledge of the domain is crucial for successful development of domain-specific modeling languages (DSML). Yet many starting DSL developers are missing the skill of domain knowledge conceptualization. The main symptoms are difficulty to come up with good language concepts and struggling with levels of abstractions. While language design remains an art, there are a number of paradigms, techniques and guidelines that can make creation of DSLs easier. These helping means are the core of the DSL design tutorial developed at Luminis Software Development. The tutorial was given for the first time during the PPL2010 conference that took place on November 17 & 18 at Océ R&D, Venlo, NL. A small group of participants learned basics of domain analysis, participated in domain definition and implemented a simple metamodel of their own. The general feedback was very positive. The slides for the tutorial can be downloaded here from the Bits&Chips website.

26-10-2013 Update: the slides are now available via slideshare:

Model interpretation approach is grasping attention of the model driven community. Industrial experiences of company Mendix has shown some very promising results. A recent post at a popular “model-minded” blog triggered a discussion about code generation versus model interpretation. Model interpretation in itself is not a new concept and there exist well known interpreters for generic and mainstream domains (e.g., Ptolemy and Simulink). The novelty in model interpretation today is that model driven methods provide efficiency and flexibility, which enable application of this concept to arbitrary problem domains. In a series of blogs we will illustrate this novel aspect and provide an example of model interpretation. Specifically this article will illustrate 1) how a custom modeling language (DSL) is developed for an arbitrary problem domain and 2) how a system behavior can be specified with the DSL and directly interpreted without any intermediate transformation steps. In a followup article we will show how a custom model interpreter can be efficiently built using a model driven method.

Model Interpretation As System

Traditional generative approaches like Model Driven Architecture (MDA) prescribe an (automated) code generation process that takes a system model as input and eventually produces code that implements the specified system. The system comes to existence when the code is executed. Alternatively, the code generation process can be skipped and a system model be executed directly.  Model Interpretation achieves such direct execution by means of a model interpreter. In this case the system comes to existence when the model is being interpreted. Thereby system behavior is completely defined by the model being interpreted. Fig. 1 illustrates a possible approach to model interpretation of event-driven systems.  An event-driven system exhibits behavior by generating (external) events in reaction to incoming external events. Therefore, the interpreter should support two-way event communication with the context. An example of an incoming external event is arrival of a positive signal from a motion sensor for an automated door. An outgoing external event could be a command to an actuator to open the door.


Figure 1: An approach to system as model interpretation In the figure, entities are shown as boxes and their roles w.r.t.  each other are shown in italic. Given that a domain-specific language (DSL) and an interpreter already exist, a domain expert uses the DSL to specify a system and its events at development time. Moving to the run-time, the same model (system configuration) represents the system and its events. During model execution, the interpreter reads system state from the model and interprets system events according to the semantics of the events. Interpretation may change the state of the system by changing the system configuration at run time, and communicate external events to the system’s context. Typically a sequence of external events is provided by the context of the system. Alternatively, these events can be specified in the system model and consequently generated by the interpreter itself (in this case, system behavior is simulated).


Today model interpretation can be applied to an arbitrary problem domain. To reflect this freedom, we chose a minor and uncommon weighbridge domain, whose purpose is to measure weight of vehicles. The following is a typical weighbridge scenario: One or more delivery vans arriving (at a factory) must pass over a weighbridge on entry. A weighbridge accepts one van at a time and each weighing operation takes a certain amount of time. If the weighbridge is busy, arriving vans join the waiting queue to the bridge. When the weighbridge becomes available again, the first van in the waiting queue drives over the bridge. This domain is characterized by a number of inherent variations, such as number of weighbridges, weighbridge capacity, weighing operation duration, number of arriving vans, arrival times of vans, etc.. The result is that a multitude of weighbridge system configurations are possible and per configuration a multitude of dynamic van arrival and weighing scenarios can play out.


Figure 2: A weighbridge system modeled in a DSL Figure 2 shows a simplified weighbridge system configuration, originally described by Birtwistle and Tofts [1]. Yellow boxes are vans. The large blue box is a weighbridge and green entities are a van arrival queue (EL) at the factory and a van waiting queue (Delay) at a weighbridge. As you can see the factory’s configuration has a single weighbridge W, which is free at this time. Finally, three delivery vans V1, V2 and Main have arrived (external events). An execution of this model is illustrated further in the article. An AToM3 implementation of a DSL for the domain is briefly described next.

Weighbridge DSL

The earlier mentioned freedom of application depends on flexibility and efficient adaptation of model interpreters to new domains. Model driven methods achieve this flexibility through metamodeling. If you are not familiar with metamodeling, you can skip this section as it is not required for understanding the demo. A DSL is defined with abstract syntax, concrete syntax, static semantics and dynamic semantics. (Such a definition is known as metamodel.) Behind every DSL is a modeling paradigm that gives fundamental guidelines for metamodeling. In case of the weighbridge domain, a proper modeling paradigm is Process Interaction [2].


Figure 3: PI Metamodel For the purposes of this demo, a PI modeling language will suffice  and we will reuse and extend a PI metamodel developed by Juan de Lara [3]. We just have to keep in mind that Process and Resource in Juan’s metamodel correspond to van and weighbridge concepts in the demo domain. The abstract syntax of the PI DSL is illustrated in Figure 3. The concrete syntax of this DSL is illustrated in Figure 2. We skip static semantics (in other words, business rules) as the focus of the domain is interpretation, not domain modeling. The following is a brief description of the key PI concepts: Resource is a synonym for the Weighbridge concept. A weighbridge has the following attributes: Name is a unique identifier of Weighbridge: String State denotes availability of Weighbridge: Enum{idle, busy} Tproc is typical duration of weighing service: Time (used in simulated execution) Capacity denotes capability to weigh multiple vans at the same time: [1..N] Load denotes weighbridge’s capacity occupied with served vans: [0..Capacity] Process is a synonym of the Van concept. A van has the following attributes: Name is a unique identifier of Van: String Tcreation is time-stamp of Van’s arrival event: Time Tinitproc is the start time of weighing operation: Time Tendproc is the end time of weighing operation: Time Body is a sequence of tasks: sequence{task} (tasks examples are bridge access, van weighing, bridge exit, etc.) EVnext is the iterator for tasks in body: [0..N] For simulation purposes, additional concepts are defined: Time is a clock for simulated time. ProcIntGenerator specifies time intervals between van arrivals. Finally, to assist visualization of system state, the original metamodel was extended with additional relationship: manageElement specifies an operation (append, insert or remove) on an element (target end of this relationship) of a sequence (source end of this relationship). The final touch of DSL definition is dynamic semantics (meaning of DSL concepts). In the model interpretation approach, such semantics is defined in an interpreter. In case of a DSL and a pure interpretive approach there is a good chance that an interpreter exactly matching the DSL will need to be developed. More so if the interpreter has to meet additional specific requirements. In our case, such requirements were run-time visualization of system behavior and interpreter integration with the factory context (not covered in this article). In a followup article we will show how a custom model interpreter can be developed. Incidentally our development approach is also based on model interpretation.

Run Time Example

A picture is worth a thousand words. With that in mind an illustration of model interpretation is best done with a video. The following screencast shows execution of the weighbridge system configuration introduced earlier (see Figure 2). For the sake of visualization, execution is carried out in the step-by-step mode and displays how the state of the weighbridge configuration changes in response to events.


In our experience model interpretation is characterized by very fast development times. In fact it did not even feel like development at all as domain experts are completely shielded from all incidental technical details.  I believe that Birtwistle and Tofts, the scientists that coined the weighbridge benchmark, would feel at home with the demonstrated DSL and the interpreter in no time. With incidental complexity out of the equation and direct involvement of domain experts, I think we’ve come very close to the essential complexity of the domain and development times cannot be drastically improved any more. That said, I feel that those interested in this approach should be aware of run-time performance penalty due to interpreter indirection. Whether this will pose a problem, depends on the application domain. What are your experiences with model interpretation? What is your domain?


[1] Graham Birtwistle and Chris Tofts. An operational semantics of process-oriented simulation languages: Part 1 πDemos. ACM Transactions on Modeling and Computer Simulation, 10(4):299–333, December 1994. [2] Jerry Banks, editor. Handbook Of Simulation. Principles, Methodology, Advances, Applications, and Practice, pages 813 – 833. Wiley-Interscience Publication, New York, September 1998. [3] Juan de Lara. Simulacio ́n educativa mediante meta-modelado y grama ́ticas de grafos. Revista de Ensen ̃anza y Tecnolog ́ıa, 23, Mayo-Agosto 2002.