This paper presents an approach to the development of modeling languages and automated generation of specific modeling tools based on meta-models. Modeling is one of the main tasks in engineering. Graphical modeling helps the engineer not only to understand the system but also to communicate with engineers and with other stakeholders that participate in the development (or analytic) process. In order to be able to provide adequately adapted modeling techniques for a given domain, it is useful to allow to develop techniques, which are designed for their special purpose, i.e. domain-specific modeling languages (DSML). For this cause meta-modeling comes in handy. Metamodels provide a clear abstract syntax and model-driven design approaches allow for rapid prototyping of modeling languages. However, often the transformation and also the original (source model) as well as the transformed (target) model do not provide a clear semantics. We present an approach to model-driven development that is based on Petri nets: high- or low-level Petri nets in various formalisms can be used as target models. Starting from the conceptual background and underlying thinking tool, following up with code templates, transformation engines, underlying semantics and the way our process support is implemented up to the final target engine Petri nets and Petri net tools can be used.
Meta-modeling enables us to build models in a more abstract way than we are used to today. For many purposes we prefer languages that solve a specific modeling quest. While there are several well established modeling techniques with a clear semantics, the purpose of the incorporated languages is more or less fixed. Annotations like those in UML can in combination with profiles enhance the expressiveness. However, it is difficult to build lean languages that cover exactly those domain aspects that are required in a certain context. In addition, normally there exist no tools that directly support those languages with specific language constructs. To make a language easy to use, one usually needs direct tool support. The development of tools for building graphical models was a challenge some years ago. Nowadays it is relatively easy within environments like Eclipse and its meta-modeling plugins. 1 Even extensions that allow a simulation of models built with those languages are available. However, usually these execution environments are relatively restricted and do not scale. This is due to the fact that the execution engine has to be built separately.
The development of a DSML and a corresponding modeling tool includes
a whole range of tasks. We will address in this contribution: (1) providing the
possibility to define an abstract syntax to allow users to build a special purpose
language, (2) providing a graphical environment to allow users to build special
language constructs for their specific language concepts (based on textual and
graphical representations), (3) providing a tool set that allows to build models
based on the previously defined languages and (4) providing a simulation
environment (especially based on reference nets [
The remainder of this paper is structured as follows: The conceptual background, which comprises the model-driven tool development, encompassing metamodeling, graphical modeling, transformations and semantical issues, is discussed with respect to the requirements and specification of our solution in Section 2. The example presented in Section 3 demonstrates the approach and the applications of Petri nets as well as the application of other techniques during DSML development. Section 4 elaborates on the wider context of model-driven development and the approach of providing transformational semantics for modeling languages with Petri nets. In Section 5 we will summarize our results and will give an outlook of our further research directions opened by these results. 1 Eclipse Modeling Framework, EMF, https://www.eclipse.org/modeling/emf/ 2 RMT: Renew Meta-Modeling and Transformation Framework, tools and examples: http://www.paose.net/wiki/Metamodeling
As our approach to software development is based on the model-driven
construction of software systems our aim is to provide a tool chain using model-driven
techniques. We want to support the agile development of graphical modeling
languages. Therefore, we rely on the concepts of software language engineering [
In this section we elaborate on the first part of the DSML development process. First we need to define the syntax of the new language (or technique). The abstract syntax of a language is specified by a meta-model, which defines the structure of the language. Our tool set, which is based on Renew, supports the modeling of the abstract syntax directly through the technique of Concept Diagrams (cf. [3, Chapter 12]). Concept Diagrams are simplified Class Diagrams, which are usually used to design type hierarchies or agent ontologies (in the context of P∗aose). In the context of this work the type hierarchies of Concept Diagrams are utilized to model the meta-models of the designed DSML, i.e. the abstract syntax.
Additionally, in order to define the representation of the elements we also need to define the concrete syntax. The concrete syntax, i.e. the representation of the syntactic elements, is defined through a mapping from the syntactic element to it’s graphical representation (representational mapping). The representational mapping includes concrete graphical or textual syntax as well as serialization representations. Typically, if the language should not be restricted to graphical standard figures, the layout, concrete form, etc. has to be defined in a form close to the implementation language. However, we provide also the possibility that the syntactic elements may be defined directly within the Renew environment using the graphical user interface. Each provided graphical representation is stored as one template drawing and the representational mapping refers not to an implementation but to a template (graphical component). Alternatively some standard elements are provided, which can be configured in terms of stylesheets to define the representation for the language constructs.
In addition to the abstract and the concrete syntax, we need to configure the user interface of the modeling tool that provides the modeling facility – in the Renew environment the modeling tool is integrated as a plugin. The configuration is done defining another mapping for task bar tool buttons and their design together with some general information about the modeling tool, such as the file extension or the ordering of tool buttons in the task bar.
The Renew plugins that provide the modeling facility for the stylesheets and the tool configurations are themselves meta-model based. They have been generated – in a bootstrapping fashion – using the RMT approach.
Figure 1 shows the defining artifacts of a modeling language’s syntax in the top. These artifacts are expressed within the scope of the meta-meta-model – the RMT meta-model – and can thus be used to generate a domain-specific modeling tool, which then provides the possibility to design a model, using the technique; e.g. a (domain-specific) modeling language.
A modeler may use the generated tool to model, store and retrieve graphical models (diagrams) in the syntax of the newly developed modeling language.3 For 3 In the following we will address these models as domain model or source models. operational or analytic models, however, it is not enough to be able to provide graphical descriptions of the models. In these cases we need to define a clear semantics. Following the idea of the model-driven architecture (MDA) the semantic interpretation of a source model can be defined through a transformation into specific target models using a generator as shown in the lowermost part of Figure 1, which references the schematic view of Petrasch et. al. [18, p. 107].
We elaborate on this in the following section. But before we present the approach to the definition of the semantics, we stress the flexibility of the given approach, so far. The meta-modeling approach in itself offers a high degree of flexibility. By changing (augmenting, modifying or restricting) the meta-model we are able to quickly produce variations of modeling techniques, which may subsequently be compared with each other (see for instance Section 3.2). Additionally, we are able to change the representation of the modeling language by either changing the representational mapping or by editing the graphical components. Especially the latter can be done by someone without knowledge in the development details and thus create his own representation. 2.2
The semantics of a modeling language is defined – as semantic mapping, cf. [
The transformation process is depicted in Figure 2 as a schematic Petri net. Transitions represent actions provided by either the RMT tool set (generation, transformation, execution or analysis) or by the source model developer (modeling). Necessary artifacts for the development of the modeling language workflow are provided by the language developer using the RMT framework. These artifacts comprise the syntax meta-models, the transformer and the semantic elements provided as net components [3, Chapter 5]. Net components are Petri net snippets that are used as patterns to be mapped by a generator and combined to constitute the target models. In this sense the model transformation process can be characterized as a pattern-oriented transformation following the categorization of Petrasch et. al. [18, p. 132].
Besides supporting the agile development of graphical languages the RMT approach also provides a high level of flexibility regarding the semantic transformation. First, the semantic targets for the syntactic elements are defined as net components, which can be modified or exchanged easily. We are even able to provide several target mapping sets of net components, which can be expressed using distinct formalisms. Thus we are able to transform one source model into multiple forms of target models. For instance, we could transform a workflow description into a PT net for analytic examination and transform the same source model to a colored Petri net for simulation / execution within a real world application. 3
In the previous section we introduced a conceptual approach to developing
modeling languages. We now show the concept in practice and demonstrate the
concrete models, which are utilized in the development process. We have chosen
to present, as example, the well-known modeling technique BPMN (Business
Process Model and Notation [
In Section 3.1 we develop a (rather simple) modeling language that implements a subset of BPMN. We show, how model transformations can be used to generate Petri net models, which provide formal semantics to the abstract BPMN models. The generated Petri net models can be referred to for analyzing a BPMN process.
In a subsequent step a more specific modeling language is developed in Section 3.2. This second language – the BPMN AIP formalism – enriches concepts from BPMN with domain-specific elements from the context of P∗aose (see Section 1). The intention is to demonstrate the flexibility of the RMT approach and the appropriateness for agile, rapid and prototypical model-driven language development. 3.1
We start with a simple subset of BPMN. Since BPMN has been described
extensively in the context of modeling, meta-modeling and also in the context of
Petri nets, we do not need to go into detail about the underlying semantics. A
mapping of syntactic elements of BPMN to PT net components has been
proposed by Dijkman et. al. [
Figure 5 shows the graphical components representing the syntactic elements of the BPMN language alongside with the Renew UI, which presents the loaded palette for the BPMN drawing tools. The graphical components are defined in separate template drawings. The templates define the concrete syntax for the BPMN technique. This concludes the specifications for the modeling language and enables us to generate the plugin for the modeling tool. During the generation process the RMT generator (automatically) prepares the images that are used for the tool buttons on the basis of the graphical templates. The icon images of parallel and alternative gateways where slightly modified as shown in the encircled part of Figure 5 to better distinguish the complementary constructs of split and join figures.
Using the generated BPMN plugin we are now able to model with this new technique using the Renew editor. Figure 6 shows a ticket workflow described in BPMN. The process reflects the lifecycle of support tickets in a conventional issue tracking system. Issues are created and at some point assigned to the holder of a certain role. They can be either rejected or accepted in which case the corresponding task will be carried out by the assignee. Later on, the task may be discontinued (unassigned ) or completed (finish ).
With the mapping of Dijkman et. al. [
The example presented in the preceding section describes the development of a modeling language together with a corresponding modeling tool (as Renew plugin) following the RMT approach. Based on meta-models the approach provides a high level of flexibility in all stages during the development of modeling languages. This enables language developers to rapidly prototype specific languages, evaluate them and adapt them according to their needs. To further illustrate this flexibility, we now present a domain-specific variation of BPMN, called BPMNAIP, which is used within the P∗aose approach.
We use BPMNAIP to model agent interaction protocols. In contrast to Agent
Interaction Protocol Diagrams (a variation of Sequence Diagrams [3,
Chapter 13]), the BPMNAIP formalism allows to shift the focus to the internal agent
processes. The presented agent-specific extensions have been proposed by
Haustermann [
BPMNAIP extends the BPMN subset in the previous section by incoming (drawn as white envelopes) and outgoing (black envelopes) message events and special tasks for agent-specific operations. The dc-exchange-task represents the synchronous or asynchronous call of an internal service. The kb-access-task serves for accessing the agent’s internal knowledge base. To use these constructs in the modeling tool, they have to be added to the meta-model. Figure 8 shows the extensions of the meta-model in Figure 3. With these extensions the modeling tool can already be used with the added constructs. The generated modeling tool uses a standard representation and standard task bar tool buttons to allow running early tests if none are provided by the developer. In order to define a customized concrete syntax, analogously to the previous example, a representation template drawn with the Renew tool, a button icon generated from the template image and a tool mapping entry in the tool configuration as shown in Figure 4 is sufficient.
In addition to the agent-specific constructs, BPMNAIP also has a domainspecific semantics. The semantics is based on the agent framework that is applied in the P∗aose approach, which uses Petri nets to implement agents and the agents’ behavior. Therefore the semantic net components for the target model are tailored for the fitness within the used framework.
In order to obtain another semantics it is possible to provide a different set of net components. The RMT framework is able to handle different transformation engines and multiple net component sets. For the BPMNAIP formalism the Mulan net components by Cabac are used [3, Chapter 5].
Figure 9 shows an adaptation of the ticket service example using BPMNAIP.
The management of the ticket status is now provided by an agent, the Ticket
Agent, which can delegate tasks to other agents. In this example the task to
export some drawing to an image is assigned to an Export Agent (as described
by Cabac et. al. [
With the described semantics the two agent processes in Figure 9 are transformed by the RMT-based BPMNAIP modeling tool into the Petri nets shown in Figure 10. These nets are protocol net skeletons, which have to be completed by additional implementation details in order to be runnable with the used framework. The figure illustrates the structure of the generated nets. A part of the net is zoomed in to exemplarily show the details of the net components. The zoomed part refers to the internal delegation of the task and the answer to the Ticket Agent. 4
In this publication we motivate the rapid and prototypical development of
domainspecific modeling languages. There are a number of related publications on
prototyping domain-specific languages (DSL), each focussing on different aspects or
application domains. Blunk et. al. [
Nytun et. al. [
With the claim of addressing general problems of defining DSML semantics
our goal consists in developing a Petri net based framework through combining
techniques of meta-modeling with Petri nets engineering. With the Event
Coordination Notation (ECNO) Kindler [
Dijkman et. al. [
In this contribution we present the RMT approach, which enables us to develop
modeling languages and modeling tools by applying concepts of model-driven
development. The key aspects of this approach are the use of meta-models for
automatic tool generation and transformation of models, exploiting the formal
semantics of Petri nets. Based on our continuously developed graphical
modeling tool and Petri net simulation environment Renew (see [
Depending on the chosen and intended formalism, we could even go one step further. We are able to simulate the transformed models directly, if there exists an operational semantics that can be mapped to the formalisms we already have implemented within the Renew context. For experimental environments where users want to define a special purpose language that suits exactly their current needs we can therefore provide a powerful tool set.
While the prototypical development of languages is already quite fast, we
now have to address the question of sustainable meta-modeling-based tools. We
have already successfully applied the tool several times within our P∗aose
approach. In this context we expect that further new modeling languages can be
developed in a prototyping approach. In the future we wish to provide the means
to support hierarchical modeling within the RMT framework. With the
Netswithin-Nets paradigm [
Acknowledgment We thank Dr. Daniel Moldt and the TGI group of the Department of Informatics, University of Hamburg for the support, constructive criticism and fruitful discussions.