Combining general purpose languages and domain specific languages for Model Driven Engineering
In a previous article about Model-Driven Engineering I’ve stated that the basic principle of MDE is that "everything is a model". Models and model elements are given a first-class status. The essential change is that models are no longer used only as mere documentation for programmers, but can now directly be used to drive software development. Models are used to define implementations, transformations, aspects of software artefacts, viewpoints on a system, and so on. In this article I define what a model is (taking into account the different usage scenario’s for a model) and how models can be defined using metamodels.
The definition of models with metamodels can be seen as a language definition which can be done using a general purpose language or a domain specific language. In most approaches a choice is made between a general purpose or a domain specific language. I think both approaches can be combined using the best from both worlds. I’ll show the power of this approach with a process modelling example using BPMN and BPEL to build a domain specific process modelling language which is almost directly executable.
PropertyI’ve tried to explain this abstract subject as simple as possible, but with a scientific foundation. This did result in a long article this time… If you want to skip parts, please jump to the part of interest using the following structure:
- What is a model?
- What is a metamodel?
- Metamodel hierarchies
- Process modelling example
The term "model" is derived from the Latin word modulus, which means measure, rule, pattern, example to be followed (Ludewig, 2003). Some definitions of the term model in software engineering are:
- A model is a set of statements about some system under study (SUS). Here, statement means some expression about the SUS that can be considered true or false (Seidewitz, 2003).
- A model is an abstraction of a (real or language-based) system allowing predictions or inferences to be made (Kühne, 2006).
A lot more definitions can be found. I think it isn’t useful to study all the different definitions. It is more useful to look at some criteria or features of models. Both Ludewig (Ludewig, 2003) and Kühne (Kühne, 2006) refer to Stachowiak (Stachowiak, 1973) which describes that a model needs to posses three features / meet three criteria otherwise it is not a model:
- Mapping: a model is based on an original. The original (system) might be something yet to be build or it may remain completely imaginary. Therefore Kühne adds that subject may be a more suitable term for original.
- Reduction: not all the properties of the subject are mapped onto the model, but the model is somehow reduced. However, a model must mirror at least some properties of the subject.
- Pragmatic: a model needs to be usable in place of an subject with respect to some purpose.
A model always has some relation with a subject (mostly a system, but it can also be another model). This relation can be classified along two different dimensions: model roles and model usage.
A model can have the following roles (Kühne, 2006):
- Token model: token models are often what people have in mind when talking about models in general. Token models consist of a one-to-one representation of (a part of) the subject elements, i.e. no abstraction is applied. Token models can also be called "representation model" (due to the direct representation character), "instance model" (since the model elements are instances as opposed to types), "singular model" (because the elements designate individuals rather than universals) or "extensional model" (as they are enumerative with respect to system elements). An example of a token models is a map or a building plan for a house.
- Type model: in contrast to token models, type models capture the universal aspects of a subject’s elements by means of classification. Object properties (e.g., four legged, furry, sharp teeth, and stereovision) are used to classify objects (e.g., as a predator). Other names for a type model can be "schema model", "classification model", "universal model", or "intensional model". Since type models are created by classification we may also say that a token model of a system is an instance of a type model of that system.
Figure 1 illustrates both concepts a bit more with an example. The subject is the real world, the token model maps the real world elements one-to-one and the type model is a classification of the elements into two concepts, a City and a Road, and an association between them.
Figure 1 – Kinds of model roles (Kühne, 2006).
Besides the classification of models into different roles, models can also be classified according to the way they are used. A model can mirror an existing original (like a photograph), or it can be used as a specification of something to be created (like a construction plan). In the first case we call the model descriptive, in the second case we call it prescriptive (Ludewig, 2003). If a model is first descriptive and later on prescriptive we call it transient. This is the case when an original have to be changed. First a descriptive model of the original is made (by example a house), after that some changes are made in the model which are applied on the original (modifying the drawing of the house and the building of the changes).
In software engineering a lot of models are used, most of them prescriptive (see Figure 2). Only the requirements specification is both descriptive and prescriptive, because it describes the user’s needs and it prescribes the product to be developed. It is this double role that makes the specification the most important software model (Ludewig, 2003). The problem in software engineering is that constructing a descriptive model is very difficult. In order to construct a descriptive model you need to know the original very well. In most cases the ‘real world’ of software engineering projects is a mess, with requirements that are neither complete nor precise. Another problem is that descriptive models only cover a small fraction of the world, they are a compromise of simplicity and realism. Prescriptive models, on the other hand, are easy to construct but they have the problem that they can command whatever their author prefers. A lot of ideas are never tested in practice.
Figure 2 – The (simplified) model chain in a software engineering process; the dashed arrow means ‘descriptive model for’, the normal arrows means ‘prescriptive model for’, based on Fig. 4. in (Ludewig, 2003).
Now the features, roles and usage scenario’s of models are clear, the question is how model languages can be defined. A metamodel, which is often referred to as a model of a model, is an important concept in defining (the micro processes of) models. Metamodels are always type models, they classify the elements of their subject models.
Figure 3 shows an example of the four-layer metamodel hierarchy of the UML (OMG, 2007). This infrastructure consists of a hierarchy of model levels, each (except the top) being characterized as "an instance" of the level above. As depicted in Figure 3 level M0 holds the user data. Level M1 is a model of the data at level M0. Level M2 is a model of the model on level M1, therefore it is often referred to as a metamodel. Finally, level M3 is said to hold a model of the information at level M2, and is often referred to as the meta-metamodel. According to the OMG a metamodel is a language definition for the subject model.
Figure 3 – An example of the four-layer metamodel hierarchy of the UML (OMG, 2007).
Although the UML is globally accepted and successfully used as foundation for the first generation MDE approaches, some problems can be identified (Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002). The most important one is the multiple classification problem (Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002).
According to Atkinson and Kühne (Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002) the UML framework takes a very liberal approach in interpreting levels and instance-of links, with result that:
- there isn’t a strict separation between different kinds of instance-of relations,
- and there is no explicit principle for judging at which level a particular element should reside
The cause for these problems is that the concept of metamodelling is used as a means of language definition. Atkinson and Kühne call this linguistic metamodelling (Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002). But according to Atkinson and Kühne this "traditional" point of view on metamodelling covers only one of the two important dimensions. Besides linguistic instantiation, like student is an instance of entity, an ontological instantiation relation exists defining that student is also an instance of person (Karagiannis & Höfferer, 2006). In linguistic metamodelling student and person are on the same layer, whereas from an ontological point of view person would be on a meta layer. Atkinson and Kühne call this ontological metamodelling.
Looking at the example shown in Figure 3 we see that the video "2001: A Space Odyssey" is both an instance and a video. Instance is defined on a meta layer while video is defined in the same layer. Instance is the linguistic definition of "2001: A Space Odyssey" and defines that it has attributes and associations, while video is the ontological definition and defines that it has a title attribute.
|Source||Instance-of relation 1||Instance-of relation 2|
|(Geisler, Klar, & Pons, 1998)||Intralevel instantiation||Interlevel instantiation|
|(Bézivin & Gerbé, Towards a Precise Definition of the OMG/MDA Framework, 2001)||Instance-of||Metainstance|
|(Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002)||Logical domain classifier||Physical classifier|
|(Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002)||Ontological instance-of||Linguistic instance-of|
Table 1 – Different instantiation relationships in literature.
In literature the idea of two different instantiation isn’t new. Table 1 shows an overview of other sources talking about different instantiation relationships and how they call them. I continue to call them linguistic and ontological instantiation because these terms are the most convenient.
A linguistic metamodel A for model B can be seen as a model of the modelling language in which B is notated. In other words: metamodel A defines the language of model B. In this case elements in model B are linguistic instances of elements in metamodel A. Linguistic instantiation between an element and a linguistic type is based on the assumption that the type represents a (fragment of a) language defining which expressions are valid sentences of it. So an element e is a linguistic instance of type T if it exists in the extension of the meaning of T (Kühne, 2006).
Linguistic instantiation concerns the form of elements. A linguistic metamodel defines the syntactical and structural aspects of a model, the abstract syntax. It also defines a part of the semantics of a model, namely the type, static and dynamic semantic:
- Abstract syntax: an abstract description of the entities that form a model of the respective language (Geisler, Klar, & Pons, 1998).
- Type semantics: the type semantics of an object is defined through the process of linguistic metamodelling and allows reasoning such as, for instance, student is derived from the metamodel construct entity and therefore is a kind of real world object and not a relationship (Karagiannis & Höfferer, 2006).
- Static semantics (context conditions, constraints): well-formedness conditions between the syntactic entities, such as absence of circular inheritance (Geisler, Klar, & Pons, 1998).
- Dynamic semantics (denotation): the (operational) behaviour of the entities of the specification, such as I/O, reaction to stimuli, effect of executing an operation, etc (Geisler, Klar, & Pons, 1998).
An example of a linguistic metamodel is the Business Process Modelling Notation (BPMN) specification (OMG, 2006). It defines the different kinds of elements and associations (abstract syntax and type semantics), the way elements can be connected (static semantics) and some basic behaviour of the different elements like "events affect the flow of a process" (dynamic semantics). Other well-known examples are an entity-relationship metamodel and, of course, the UML metamodel.
In addition to the "traditional" linguistic metamodelling dimension, the ontological metamodelling dimension is equally important. In philosophy, ontology is the study of the kinds of things that exist. It is often said that ontologies "carve the world at its joints". "Ontological analysis clarifies the structure of knowledge. Given a domain, its ontology forms the heart of any system of knowledge representation for that domain. Without ontologies, or the conceptualizations that underlie knowledge, there cannot be a vocabulary for representing knowledge" (Chandrasekaran, Josephson, & Benjamins, 1999). Even in software engineering ontologies are important. Any software program needs a model of the real world to do anything useful and hence it needs an ontology (Chandrasekaran, Josephson, & Benjamins, 1999).
An ontology is a system of concepts and their relations, in which all concepts are defined and interpreted in a declarative way (Devedzic, 2002). The system defines the vocabulary of a problem domain and a set of constraints on how terms can be combined to model the domain. A better known synonym for an ontology is "domain model". Ontological instantiation between two elements or models is based on the relationship between them in terms of their meaning (Kühne, 2006). An example of an ontological hierarchy is given in Figure 4. "Lassie" is an ontological instance of "Collie", while "Collie" is an ontological instance of "Breed".
Figure 4 – Ontological metamodelling (Kühne, 2006).
While linguistic metamodels define the language of a model (including the abstract syntax, type semantics, static semantics and dynamic semantics), ontological metamodels define the inherent semantics of a model. Inherent semantics describe the "inner meaning" of modelled resources and provide the basis for reasoning about concepts (Karagiannis & Höfferer, 2006). By example, a student is a human person that can be male or female and who is attending an university-like institution. Ontology’s are essential for defining declarative languages, e.g. languages defining the "what" instead of the "how".
In Figure 3 I’ve shown the metamodel hierarchy of the UML. From the previous part we can conclude that this hierarchy is a linguistic metamodel hierarchy. Most existing metamodel hierarchies are linguistic hierarchies.
An example of an ontological metamodel hierarchy is given in Figure 5, taken from (Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004). The top-most layer describes abstract technological concepts. These are not bound to specific platforms but are similar to the concepts in the platform independent models of the MDA. As example a DataSet is shown, which describes a persistent piece of data. The elements on this layer act as metaclasses for domain specific concepts. In the example in Figure 5, taken from the business domain "content management", a possible instance is Article. This middle layer is used as a domain-specific modelling language. In this example, the content management system modelled is an online cook book holding Articles called Recipes. An online newspaper might have Articles called Advertisement, NewsItem and Editorial (Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004).
Figure 5 – Example ontological metamodel hierarchy (Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004).
It seems to be odd to have a technology layer as the uppermost layer, while most approaches have a top-down approach, with a business ontology as uppermost model and the technology layer as the lowest level. However, this results in replication of concepts on the technology layer as shown in Figure 6. Gitzel and Merz (Gitzel & Merz, How a Relaxation of the Strictness Definition Can Benefit MDD Approaches With Meta Model Hierarchies, 2004) did use such a structure in a practical code generation example and also conclude: "during the code generation process it became obvious that other hierarchies are probably better suited for code generation, as the introduction of technology on the lowest layer leads to a lot of replication in the templates, i.e. each concept realized as a java session bean would need the same basic structure but the concepts share no common meta class which defines the shared technological properties". So in MDE approaches it is better to use an ontological metamodel hierarchy with the technology layer as the uppermost layer. Concepts in this layer should, as stated above, describe abstract technological concepts which are platform independent.
Figure 6 – Example alternative ontological metamodel hierarchy.
We’ve seen an example of both linguistic and ontological metamodel hierarchies. As argued before both dimensions are needed for a complete modelling approach.
An infrastructure supporting both tailorable, accessible models and the addition of types at runtime needs to be dynamically extensible (Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002). These needs come from the goals of MDE to let software artefacts outlive changes in personnel and (business) requirements (see Model-Driven Engineering). Dynamic extensibility requires the capability to dynamically extend the set of domain types available for modelling, and this in turn requires the capability to define domain metatypes, i.e. ontological metamodelling (Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002).
The other mentioned goals of MDE (see Model-Driven Engineering), improving the short-term productivity and the ability of software artefacts to outlive changes in personnel, development platforms and deployment platforms, call for concise, interchangeable models and user-definable mappings (Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002). This requires the capability to define a formal model language, i.e. linguistic metamodelling.
So, MDE needs both linguistic and ontological metamodelling. In combining these approaches some design possibilities arise, like using a linear or non-linear hierarchy, the definition of elements as language elements or library elements and the definition of strictness in a metamodelling hierarchy.
In the UML (OMG, 2007) the concept of stereotypes can be seen as the solution for combining linguistic and ontological metamodelling. Stereotypes are a lightweight metamodel extension mechanism. Instead of introducing new metamodel layers the existing metamodel can be extended by "tagging" elements. Using stereotypes has two advantages. First, stereotypes are easy to use, users don’t have to be aware of another metamodel hierarchy (Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004). Second, the concept of stereotypes is easy to implement in CASE tools because the metamodel itself doesn’t have to be extensible and can be hardcoded in the tool (Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002). However, these advantages do not come without a price. Atkinson and Kühne state "Not only did the introduction of an additional classification mechanism (stereotyping) compound the existing vagueness of instantiation semantics, it introduced further confusion about its proper role and interpretation in terms of the metamodelling framework." (Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002). Duddy (Duddy, 2002) states that the tagging mechanism for creating UML profiles is primitive and impractical. Existing UML profiles, like the Enterprise Application Integration (EAI) profile (OMG, 2004), use their own metamodel in addition to the UML metamodel. It can be concluded that stereotyping isn’t sufficient enough for creating your own language. A metamodel hierarchy should support first-class extension of its metamodel to enable the definition of new families of languages (domain specific languages).
As discussed above the common single meta-layer approach with stereotypes provides little structure and isn’t sufficient for defining domain specific models. Using metamodel hierarchies, e.g. the use of multiple metamodels, gives the user of an MDE tool the additional flexibility of user extensions, as he can choose a custom metamodel to model his application, with all the benefits a domain specific modelling language offers (Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004). Multiple metamodels can be arranged in different hierarchies. Figure 7 shows a linear metamodel hierarchy with linguistic instantiation between the technology layer and the language layer. Ontological instantiation is used between the other layers.
Figure 7 – Linear metamodel hierarchy.
If deep instantiation semantics are used, which means that a class can make statements about its instances and their instances in turn transitively (Gitzel & Hildenbrand, A Taxonomy of Metamodel Hierarchies, 2005), there isn’t any difference in semantics with the orthogonal metamodel hierarchy shown in Figure 8 and Figure 9. According to Atkinson and Kühne (Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002) the key to integrate linguistic and ontological classification is to view them as orthogonal dimensions. However, after investigating the concept of deep instantiation they conclude that it is an open question whether it is better to use an orthogonal hierarchy or a linear hierarchy combined with deep instantiation.
Figure 8 – Orthogonal metamodel hierarchy.
Figure 9 – Example elements of an orthogonal metamodel hierarchy.
Gitzel and Hildebrand (Gitzel & Hildenbrand, A Taxonomy of Metamodel Hierarchies, 2005) argue that the expressional strength of a non-linear hierarchy is higher, but only if the concept of deep instantiation is disregarded.
Although no semantic differences exist I recommend to use the orthogonal hierarchy because it emphasizes the different instantiation types. In the linear approach it is easy to confuse linguistic and ontological instantiation because they are both visualized in the same direction. Besides that, the orthogonal hierarchy directly shows that Recipe is both a Class and an Article. In the linear hierarchy man have to reason with deep instantiation to see that a Recipe is also a Class.
When defining a language for an MDE approach based on the concepts presented above, the question arises for particular elements whether to define them in the top ontological metamodel or in the top language metamodel.
If we look at object-oriented programming languages we see that they also distinguish between core language concepts and library classes. The strategy adopted by most object-oriented languages is to make the core language definition as small as possible and to define as many concepts as possible within the class libraries (Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002). According to Atkinson and Kühne this helps to:
- keep the language definition small and simple,
- keep the virtual machines stable even in the event of considerable (library) concept restructurings, and
- give users maximum tailorability (users may change or extend a library but cannot change the core language concepts).
In other words, the lesson learned from object-oriented languages implies that linguistic instantiation should be minimized and as many concepts as possible should be placed within the ontological classification hierarchy. It is even possible to learn from object-oriented languages what basic concepts have to be addressed in the linguistic dimension to achieve the same benefits of tailorability. Atkinson and Kühne (Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002) state that the only concepts or mechanisms a model-driven language definition needs to address are those related to:
- type/instance instantiation,
- graph-based models,
- presentation (concrete syntax), and
The last point to discuss about metamodel hierarchies is the semantics of instantiation. A distinction can be made between strict and relaxed metamodelling.
Strict metamodelling is based on the tenet that only instance-of relationships may cross meta-level boundaries, and that every instance-of relationship must cross exactly one meta-level boundary to an immediately adjacent level (Atkinson & Kühne, Strict Profiles: Why and How, 2000). This seems to unnecessary complicate modelling, but without this strictness definition the whole idea of metamodel hierarchies collapses. In practice, this means that the location of model elements is not determined by their place in the instance-of hierarchy, but instead by other, often unstated, criteria (Atkinson & Kühne, Processes and products in a multi-level metamodeling architecture, 2001).
Gitzel and Merz (Gitzel & Merz, How a Relaxation of the Strictness Definition Can Benefit MDD Approaches With Meta Model Hierarchies, 2004) have proposed a relaxed definition for strictness in metamodel hierarchies. They argue that this relaxed definition is useful when a metamodel hierarchy is used for code generation, it avoids replication of concepts. However, the example they use contains platform dependent concepts, in particular the concept which needs the relaxation of the strictness definition (JDOPersistence). Part of the reason for this is the use of a metamodel hierarchy with the technology layer as the lowest level (see before for an explanation of the different ontological metamodel hierarchies). Because platform dependent concepts don’t belong in an MDE approach, and can be avoided by using abstract technological concepts in the uppermost ontological layer, I don’t see the example as an argument for the need of the relaxation of strictness.
I think, however, that a relaxation of strictness can be very useful in practice to enable more flexibility for users. In a strict approach each element in a layer has to be defined in the layer above (the meta layer). If the meta layer isn’t complete enough and can’t fulfil the needs of an application modeller there is no way to solve it without changing the meta layer, but that isn’t always possible. In this situation the solution can be to let the application modeller define a concept based on the meta-meta layer. In the example below (Figure 10) this situation can occur if the application modeller wants to define an activity not defined in the Business Domain Layer. With a relaxation of strictness he can use concepts of the Pervasive Services Layer or, if that isn’t enough, he can directly use BPEL concepts (for more explanation of the example see the next part of this article).
In the previous parts of this article I’ve explained a lot about models, metamodels and metamodel hierarchies. I’ve argued that both linguistic and ontological metamodelling are necessary for models supporting Model-Driven Engineering. I’ve also shown some example hierarchies for object models. Although this shows the applicability of the presented approach for object models it doesn’t show its full potential for MDE. Process models are also import for MDE, so let’s look at a metamodel hierarchy for process models.
A lot of discussions are going on about the use of BPMN (OMG, 2006) and BPEL4WS (OASIS, 2007) as general purpose languages for business process modelling. While BPMN is used for defining business processes for analysis and documentation (in general), BPEL4WS is used to define executable business processes. From a Model-Driven Engineering perspective the mapping from BPMN to BPEL4WS (in short: BPEL) is interesting and necessary. The most comprehensive approach is presented in (Ouyang, Aalst, Dumas, & Hofstede, 2006). However, they only focus on the syntactical (structure) translation, in practice the gap between BPMN and BPEL is far bigger in terms of semantics (see also (Baeyens, 2008) for an explanation of the gaps between BPMN and BPEL).
Braha and Østerbye (Braha & Østerbye, 2006) indicate three obstacles in using general purpose modelling languages for business process modelling:
- Semantics. Specific semantics for custom tasks like RegisterInvoice cannot be defined. A modeller has to remember to define necessary data when using the task in models and there is no tool support for providing and validating the data. A transformation engine does not recognize a task like RegisterInvoice because it is modelled as a general task.
- Visualization. There is no customized visual presentation of the model. Visualization is important because different people such as users, business analysts, architects and developers all have to understand the model.
- Abstraction. A business process may be modelled at a high abstraction level. A task such as RegisterInvoice may not have a simple implementation as e.g. a web service invocation. Instead, it could have an implementation pattern, for instance a sequence of three web service calls, and mechanisms for handling exceptions. These details are not relevant for the model, but have to be modelled when using a general language to make transformation to an implementation possible.
Examples of domain specific process modelling approaches solving these problems are presented by (Braha & Østerbye, 2006), (Jablonski, Faerber, Götz, Volz, Dornstauder, & Müller, 2006) and (Becker, Pfeiffer, & Räckers, 2007). Although they present nice approaches, they don’t use a formal metamodel hierarchy for defining their languages and they don’t mention an explicit connection with existing general purpose standards like BPMN and BPEL.
I think the metamodelling approach presented in this article can formalize the definition of domain specific process modelling approaches and it can even bridge the gap between domain specific and general purpose process modelling. A proposal for a metamodel hierarchy for process modelling is shown in Figure 10. As linguistic metamodel the BPMN specification can be used, which defines the syntax and some basic semantics. BPMN specifies also that activities can be composite, e.g. they can be build of one or more other activities. This concept can be used to define ontological instantiation relations. By example, a business domain concept can be build of more than one pervasive service.
Figure 10 – Metamodel hierarchy for domain specific process modelling.
The BPEL elements are place at the top of the ontological dimension thereby defining the abstract, platform independent, technological concepts. BPEL elements can be graphically represented by BPMN concepts. In order to simplify the definition of domain specific concepts an extra layer is placed below the BPEL layer, the Pervasive Services Layer. The concept of pervasive services is defined by the OMG in the MDA (OMG, 2003). Pervasive Services are services available in a wide range of platforms. These services can thus be modelled in a platform independent way. Examples of pervasive services are Directory Services, Event Handling, Persistence, Transactions, and Security (Soley, 2000). Baeyens (Baeyens, 2008) proposes a corresponding concept called ‘components’.
With a wide range of pervasive services available it is possible to specify the Business Domain Layer without knowledge of BPEL. The Business Domain Layer supports the definition of a domain specific process language thereby enabling the modelling of processes in the Model Layer by domain experts (business users). Because the domain concepts used in the resulting model are ontological instances of / defined by BPEL concepts (through business domain concepts and pervasive services) they are directly executable, or better formulated: it is possible to define an automatic transformation into a platform dependent definition which is directly executable on that particular platform! This transformation definition can be defined on the level of the pervasive services, which means that it holds for all business domains.
Examples of instantiation chains in the presented metamodel hierarchy are shown in Figure 11. These are just example elements to make the concept clear and they don’t represent all needed concepts (gateways and flows aren’t mentioned by example).
Figure 11 – Example elements in the metamodel hierarchy for domain specific process modelling.
Let’s take a look at the example presented at the left of Figure 11. The linguistic concept is a BPMN activity which is defined as some work a company performs (OMG, 2006). It can be atomic or non-atomic and is represented by a rounded rectangle. The uppermost ontological concept is the BPEL Invoke activity. Table 2 shows the basic properties of the Invoke activity.
|partnerLink||points at the webservice to call|
|portType||indicates a specific port of the webservice|
|operation||or function to call at the webservice|
|inputVariable||the input elements for the operation|
|outputVariable||the output elements of the operation|
Table 2 – Properties of the BPEL Invoke activity.
The modelled pervasive service in the example is a SendEmail activity. The properties of this activity are defined in Table 3.
|ToAddress||The address the email will be send to|
|FromAddress||Email address of the sender|
|Subject||The subject of the email|
|Message||The message to send|
|Attachement||An optional attachement to send with the email|
Table 3 – Example properties of the SendEmail activity.
The SendEmail activity is an ontological instance of the Invoke activity and has the values shown in Table 4 defined for the Invoke properties.
Message containing the properties of the SendEmail activity:
|outputVariable||Return message of the send email request|
Table 4 – Example values for the SendEmail Invoke properties.
Now the SendEmail service can be used to model domain specific concepts. In the example a SendNotification activity is modelled. Table 5 shows the properties of the SendNotification activity.
|UserId||The id of the user the notification will be send to|
|Type||The notification type (e.g. error, warning, info, etc.)|
|Message||The notification message|
Table 5 – Example properties of the SendNotification activity.
The SendNotification activity is an ontological instance of the SendEmail activity and has the values shown in Table 6 defined for the SendEmail properties. By now we see that information from other model hierarchies is needed, the concept ‘User’ is used. I’m not going into detail about this subject now, but the idea should be clear that domain specific languages (DSL) should define interfaces for using concepts from other DSL’s and for publishing concepts to other DSL’s. A couple of DSL’s together can form the description of an application.
Table 6 – Example values for the SendNotification’s SendEmail properties.
Now that the concept on the Business Domain Layer is defined the user of the modelling tool can use this concept (SendNotification) to model the behaviour of a process.
Making the concept, modelled by the user of the modelling tool (in the example a LowStockNotification), actually work, the only thing to do is filling in the right binding for the BPEL partnerlinks. In case of the example the binding for the CommunicationServices partnerlink has to be defined. So defining a transformation is made very easy by using this metamodel hierarchy.
I’ve made clear what models are, what different roles models can have and how they can be used. I’ve argued that two different instantiation relations exist between model element, linguistic and ontological instantiation. A linguistic metamodel defines the language (including the abstract syntax, type semantics, static semantics and dynamic semantics) of a model. An ontological metamodel defines the concepts which can be used in a model. Ontological metamodelling is used for defining the meaning (inherent semantics) of concepts and enables reasoning about concepts in a model.
Based on the goals of model-driven engineering I’ve concluded that an MDE methodology has to make use of both linguistic and ontological metamodelling. In combining these approaches some design possibilities arise, like using a linear or non-linear hierarchy, the definition of elements as language elements or library elements and the definition of strictness in a metamodelling hierarchy.
I’ve argued that an orthogonal hierarchy is preferred, because it emphasizes the different instantiation types. In the linear approach it is easy to confuse linguistic and ontological instantiation because they are both visualized in the same direction. Besides that, the orthogonal hierarchy directly shows that Recipe is both a Class and an Article. In the linear hierarchy man have to reason with deep instantiation to see that a Recipe is also a Class.
The lesson learned from object-oriented languages implies that linguistic instantiation should be minimized and as many concepts as possible should be placed within the ontological classification hierarchy.
I think that a relaxation of strictness can be very useful in practice to enable more flexibility for users.
At last, I’ve shown with a process modelling example that the design decisions I made are very powerful for defining domain specific languages (DSL’s). First, the resulting DSL’s are easy to transform into working software. Second, the approach I’ve shown enables the combination of concepts from general purpose languages and domain specific languages. In the example I’ve used the general purpose languages BPMN and BPEL to build a DSL.
Atkinson, C., & Kühne, T. (2002). Model-Driven Development: A Metamodeling Foundation. IEEE Softw. , 20 (5), 36-41.
Atkinson, C., & Kühne, T. (2001). Processes and products in a multi-level metamodeling architecture. International Journal of Software Engineering and Knowledge Engineering , 11 (6), 761-783.
Atkinson, C., & Kühne, T. (2002). Rearchitecting the UML infrastructure. ACM Transactions on Modeling and Computer Simulation , 12 (4), 290-321.
Atkinson, C., & Kühne, T. (2000). Strict Profiles: Why and How. Proceedings of the Third International Conference on the Unified Modeling Language, Lecture Notes in Computer Science, vol. 1939, (pp. 309-322).
Baeyens, T. (2008, 02 04). Process Component Models: The Next Generation In Workflow? Opgeroepen op 04 03, 2008, van InfoQ: http://www.infoq.com/articles/process-component-models
Becker, J., Pfeiffer, D., & Räckers, M. (2007). Domain Specific Process Modelling in Public Administrations – The PICTURE-Approach. In M. Wimmer, H. Scholl, & A. Grönlund, EGOV 2007, LNCS 4656 (pp. 86-79). Heidelberg: Springer-Verlag.
Bézivin, J. (2004). In Search of a Basic Principle for Model Driven Engineering. UPGRADE , Vol. V (No. 2), 21-24.
Bézivin, J., & Gerbé, O. (2001). Towards a Precise Definition of the OMG/MDA Framework. Proceedings of Automated Software Engineering, ASE’2001. San Diego.
Braha, S., & Østerbye, K. (2006). Business Process Modeling: Defining Domain Specific Modeling Languages by Use of UML Profiles. In A. Rensink, & J. Warmer, ECMDA-FA 2006, LNCS 4066 (pp. 241-255). Heidelberg: Springer-Verlag.
Chandrasekaran, B., Josephson, B., & Benjamins, J. (1999). What are ontologies, and why do we need them? IEEE Intelligent Systems , 14 (1), 20-26.
Devedzic, V. (2002). Understanding Ontological Engineering. Communications of the ACM , Vol. 45 (No. 4), 136-144.
Duddy, K. (2002). UML2 must enable a family of languages. Communications of the ACM , Volume 45 (Issue 11), 73-75.
Geisler, R., Klar, M., & Pons, C. (1998). Dimensions and Dichotomy in Metamodeling. Proceedings of the Third BCS-FACS Northern Formal Methods Workshop. New York: Springer-Verlag.
Gitzel, R., & Hildenbrand, T. (2005). A Taxonomy of Metamodel Hierarchies. Mannheim: Research Report, department of IS.
Gitzel, R., & Korthaus, A. (2004). The Role of Metamodeling in Model-Driven Development. Proceeedings of the 8th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI2004). Orlando, USA: International Institute of Informatics and Systemics (IIIS).
Gitzel, R., & Merz, M. (2004). How a Relaxation of the Strictness Definition Can Benefit MDD Approaches With Meta Model Hierarchies. Proceedings of the 8th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI2004) (pp. 62-67). Orlando, USA: International Institute of Informatics and Systemics (IIIS).
Jablonski, S., Faerber, M., Götz, M., Volz, B., Dornstauder, S., & Müller, S. (2006). Configurable Execution Environments for Medical Processes. Fourth International Conference on Business Process Management (BPM).
Karagiannis, D., & Höfferer, P. (2006). Metamodels in action: an overview. Filipe, J., Shishkov, B. and Helfert, M. eds. ICSOFT 2006 – First International Conference on Software and Data Technologies. Setúbal: Insticc Press.
Kühne, T. (2006). Matters of (meta-) modeling. Softw. Syst. Model. , 5 (4), 369-385.
Ludewig, J. (2003). Models in software engineering – an introduction. Softw Syst Model , 2 (1), 5-14.
OASIS. (2007). Web Services Business Process Execution Language Version 2.0.
OMG. (2006). Business Process Modeling Notation (BPMN) Specification v. 1.0. OMG Final Adopted Specification, Document Number dtc/06-02-01.
OMG. (2003, 06 12). MDA Guide Version 1.0.1. Retrieved from Object Management Group: http://www.omg.org/mda
OMG. (2007). OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2. OMG Document Number: formal/2007-11-04.
OMG. (2004). UML Profile and Interchange Models for Enterprise Application Integration (EAI) Specification. OMG Formal Specification, Document number: formal/04-03-26.
Ouyang, C., Aalst, W. M., Dumas, M., & Hofstede, A. H. (2006). Translating BPMN to BPEL. Technical Report, BPM Center Report BPM-06-02.
Seidewitz, E. (2003). What models mean. IEEE Softw. , 20 (5), 26-32.
Soley, R. (2000, 11 27). Model Driven Architecture. Opgehaald van Object Management Group: http://www.omg.org/mda
Stachowiak, H. (1973). Allgemeine Modelltheorie. Wien: Springer.