Domain-speci c languages (DSLs) are high-level and should provide abstractions and notations for a better understanding and easier modeling of applications in a special domain. It is essential to combine di erent DSLs while modeling a complete system. Hence the question arises: How can we combine DSLs and in addition integrate their semantics and constraints? Based on a case study from an industrial partner, in this paper we rst show how DSLs can be enriched by the ontology language OWL to de ne additional constraints and semantics within the DSL. Then we give an answer of how to combine these ontology-enriched DSLs and present a solution of integrating constraints and semantics of several languages.
Today domain-speci c languages (DSLs) are used to model and develop systems
of di erent application domains. Such languages are high-level and should
provide abstractions and notations for better understanding and easier modeling of
applications of a special domain. A variety of di erent domain-speci c languages
and fragmentations of their models may be used to develop one large software
system. Each domain-speci c language focuses on di erent problem domains and
as far as possible on automatic code generation [
Besides di erent domain-speci c modeling concepts there are di erent rules,
constraints and semantics. These rules and semantics have to be de ned, too,
to provide di erent bene ts like error prevention, guidance and consistency [
Description logics is a family of logics for concept de nitions and are used to
describe domain knowledge and allow specifying concepts by rich, precise logical
de nitions [
In this paper we use structural domain-speci c languages, which are widely
used in domain modeling and are instantiable. It might be useful to combine
these structural domain-speci c languages and ontology languages at the
metamodel layer [
It is essential to combine di erent DSLs while modeling a complete system, for example to allow multi-viewpoint modeling or to check if the models de ned by using overlaping DSLs still are consistent. In this paper we want to show how the semantics and constraints of several languages can be combined.
In this paper rst we show how DSLs can be integrated with ontology
languages to enrich their exprissiveness. The main contribution of this paper is to
consider already ontology-enriched DSLs with integrated constraints and
semantics and to combine these languages. In [
Generally, our approach should be useable for integrating several domainspeci c languages and their models and in addition the combination of constraints and semantics the domain models contain, while the constraints could be expressed by e.g. OCL or other constraint languages.
In section 2 of this paper we start with two di erent scenarios. The rst scenario considers the integration of DSLs and the ontology language OWL2 at the metamodel level. The second scenario considers the integration of two ontology-enriched DSLs. Section 3 presents all languages used in this paper and simultaneously provides a solution for the rst scenario. Afterwards, section 4 considers the second scenario and presents a solution of integrating DSLs at the metamodel layer and its semantics at the model layer. Finally, we present some related work and give a conclusion. 2
Comarch3, a polish IT company, specialized in software for telecommunication providers, uses di erent model-driven methods for software development where di erent kinds of domain-speci c languages (DSL) are deployed during the modeling process. One of the languages Comarch uses is the Business Entities Domain-Speci c Language (BEDSL). BEDSL is platform independent and is used to model di erent business entities in the scope of the operation support system that Comarch provides. A second language Comarch uses is the Physical Device Domain-Speci c Language (PDDSL). The language provides concepts 3 http://www.comarch.com of the domain of network devices, e.g. Chassis, Slot, Card or Port. In general PDDSL de nes the structure of physical network devices. Both languages, their abstract syntax and examples in concrete syntax, are presented in section 3.2.
In the following we consider two di erent scenarios, schematically depicted
in gure 1. The rst scenario deals with integrating ontology languages and one
of the two Comarch DSLs resulting in a new more expressive language.
Using this we are able to create domain models and to de ne several constraints
within the domain models. An approach for handling this scenario was presented
in [
OWL
integration S BEDSL c e n a r i o 1 integration S c e n a r i o 2
integration
Studying the Comarch BEDSL and PDDSL presented in section 3.2 we ascertain that the languages are very simple to use but therefore do not provide much expressiveness. For instance, BEDSL is only focusing on business objects represented by entities and their attributes. Thus it makes sense to allow annotations of model elements which are de ned by simple OWL statements. For example domain modelers may want to annotate model elements with very simple OWL text to de ne additional constraints and semantic annotations, if they feel that the language is not expressive enough. Equally, PDDSL is not able to de ne restrictions or special con gurations of physical devices. For example it is not possible to describe with PDDSL that a device is a Cisco7603 Router if and only if it has a con guration with exactly three slots in which speci c cards are plugged in. Here again ontologies can be used and integrated within PDDSL. Thus more complex concepts like the one of the Cisco7603 router can be described.
In general it makes sense to integrate the DSLs and an ontology language
to provide advantages like constraint de nition, formal semantics and reasoning.
In this scenario the question arises how a metamodel of a DSL and the one of
an ontology language can be integrated. We gave a rst answer in [
Thus we realize our intention that a designer should use the language he is familiar with as much as he can. If he recognizes that it is not expressive enough he is able to use additional annotations. Furthermore a change of the existing infrastructure is not necessary. 2.2
An advantage of BEDSL is that there exists support for storing BEDSL models in relational databases. Furthermore Comarch aims also to store models of physical network devices in relational databases. Thus, it makes sense to integrate both languages, the BEDSL with its capabilities for databases and the PDDSL with its features for describing network devices.
During the integration existing semantics and constraints of each separate domain model are also to be integrated. In most cases they overlap or depend on each other. Here inconsistencies can occur, and existing semantics can be changed and thus can lead to incorrect domain models.
Thus, in this scenario the question arises how domain models with additional, embedded formal constraints and semantics can be merged. In section 4 we present a rst combination approach where the integration of models plus its semantics and constraints is considered in the context of the new integrated metamodel which contains a BEDSL-, a PDDSL- and an OWL-part. 3
Integration of DSLs and Ontology Languages
In this section we want to present three di erent languages. In section 3.1 we
present an example of using the axiom-based ontology language OWL2. A
detailed speci cation of OWL2 can be found in [
OWL2 In general description logics based ontology languages are used to de ne sets of concepts that describe domain knowledge and allow specifying classes by rich, precise logical de nitions. Among di erent ontology languages, we use the W3C standard OWL2 in this paper. OWL actually stands for a family of languages with increasing expressiveness. OWL2, the current draft, is more expressive and still allows for sound and complete reasoning that is decidable as well as pragmatically e cient.
The di erence between OWL and class-based modeling languages like UML class diagrams is its capability to describe classes in many di erent ways and to handle incomplete knowledge. These OWL features increase the expressiveness of the metamodeling language, making OWL2 a suitable language to formally de ne DSL models. Therefore, our intention is to integrate OWL2 with the DSL such that domain models with additional, embedded constraints can be de ned.
OWL2 is axiom-based and thus provides di erent constructs to restrict
classes or properties. The three important kinds of axioms are class axioms,
object property axioms and data property axioms. A detailed speci cation of
the ontology language OWL2 and its axioms is presented in [
Using a concrete syntax in Manchester Style [
Class : Device Class : Cisco7603
SubClassOf :
Device , h a s C o n f i g u r a t i o n e x a c t l y 1 C o n f i g u r a t i o n 7 6 0 3 Class : C o n f i g u r a t i o n Class : C o n f i g u r a t i o n 7 6 0 3
SubClassOf :
C o n f i g u r a t i o n ObjectProperty : h a s C o n f i g u r a t i o n
Domain :
Device Range :
C o n f i g u r a t i o n
In [
In this section we want to describe two integrated metamodels. The
metamodels come from our project partner Comarch and are precisely presented in [
Domain-Speci c Language (BEDSL) is a domain-speci c language intended to model business entities. BEDSL is platform independent, abstracting from any speci c technology, focusing on representing business objects, like entities, their attributes and relations. Thus it provides a good basis to save such domain models in relational databases.
Figure 3 depicts an example in concrete syntax of using the enriched BEDSL. In such a diagram all business entities of Cisco devices and in our case its specialization Cisco7603 can be de ned. A Cisco device can contain CiscoSlots and CiscoCards. In the example we have three specializations of Cisco cards, namely HotSwappable card, SPAInterface card and Supervisor card.
The technical speci cation of a Cisco device requires that a Cisco has at least a Supervisor card and has exactly 3 slots. These requirements are de ned in the annotation (1). Furthermore we de ne that if and only if a Cisco device contains any Card then of course it contains a CiscoSlot (2).
(2) Cisco and containsSlot some CiscoSlot
EquivalentTo:
Cisco and containsCard some CiscoCard Cisco containsSlot
CiscoSlot hasSupertype containsCard
CiscoCard
Cisco7603 (1) (SucboCnltaasisnOsfCa:rd some Supervisor) and (containsSlot some CiscoSlot)
hasSupertype HotSwappable
SPAInterface relation between Entity and SimpleAttribute by the class SimpleProperty which inherits from OWL DataProperty. Thus we are able to adopt di erent OWL object property and data property axioms on relations between entities and its attributes. In the following we call the enriched language BEDSL+OWL. Fig. 4. Integrated Metamodel of the Business Entities Domain-Speci c Language (BEDSL+OWL)
tions between physical device elements the Physical Device Domain-Speci c Language (PDDSL) is used.
Figure 5 depicts an example in concrete syntax of using the enriched PDDSL. Here in general a Cisco7603 with its possible con gurations is modeled. Using simple OWL annotations we de ne that Cisco7603 is a subclass of Cisco (1), Configuration7603 is a subclass of CiscoConfiguration (2) and HotSwappable, SPAInterface and Supervisor are subclasses of CiscoCard (3). Furthermore we de ne that each Cisco device has some CiscoConfiguration (4) and each Cisco7603 only has exactly one Configuration7603 (5). Furthermore by de ning a global constraint, we state that if and only if a Configuration7603 contains a HotSwappable card it also has a SPAInterface card (6).
The metamodel of this language is presented in gure 6. PDDSL describes physical devices and thus provides concepts like Shelfs, Chassis, Slots and Cards. Shelfs and Chassis can be connected with other Cards through Slots. Concrete con gurations (a valid set of Slots with compatible Cards) are encapsulated in a Configuration. Every Shelf or Chassis contains many possible con gurations.
Analogously to the integration of BEDSL and OWL2 we have integrated an ontology language with PDDSL. Here, Element inherits from OWL Class. Thus it is possible to adopt several OWL class axioms on elements of a physical device. (6) CCiissccoo aanndd hhaassCCoonnffiigg ssoommee ((CCiissccooCCoonnffiigguurraattiioonn aanndd hhaassSSlloott ssoommee ((CCiissccooSSlloott aanndd hhaassCCaarrdd ssoommee HSoPtASIwnatpeprafbalcee)))) EquivalentTo:
Cisco hasConfig CiscoConfiguration hasSlot
CiscoSlot hasCard CiscoCard (4) CSiubsCcloaCsosnOffig:urhaatsiCoonnfig some Furthermore we materialize the relation between a SlotContainer and its congurations by the separate class ConfigurationProperty, the relation between Configuration and Slot by the separate class SlotProperty and the relation between Slot and Card by the separate class CardProperty. All property classes inherit from OWL object property. Hence it is allowed to adopt di erent OWL object property axioms on these relations. In the following we call the enriched language PDDSL+OWL.
Fig. 6. Integrated Metamodel of the Physical Device Domain-Speci c Language (PDDSL+OWL) 4
In this section we want to consider how the metamodels of BEDSL+OWL and
PDDSL+OWL can be integrated and how the constraints behave after the
integration. At rst we present the general approach of combining models and
additional constraints. Afterwards we give an example and concentrate on two
integration transformations, namely the Merge Transformation and the
Specialization Transformation, presented in [
If two metamodels are combined, the integration transformations have to consider the di erent semantics of the two languages. Model elements of two di erent languages can only be combined, if the result conforms to the already existing semantics of the two di erent languages.
To present an approach for solving the problem of merging semantic annotations of model elements and constraints, we have to consider the integration transformations on two di erent layers. First the transformation is de ned at the M2-layer where it de nes which di erent classes of the di erent metamodels are to be connected (e.g. merged).
Then we have to de ne at the domain model layer (M1-layer) which model elements (instances of concepts in the metamodels) are considered by the transformation (e.g. some of them can be merged). Here the domain knowledge of a DSL expert is important, which leads to intensional semantics of concepts at the M1-layer. These semantics later are represented by description logics axioms and are used to decide which concepts are transformed. The result of the execution of the transformation at the M2-layer is an integrated metamodel and a corresponding integration of the models.
The result of the execution of the transformation at the M1-layer is a modied abstract syntax graph of the domain model. This new abstract syntax graph describes how the considered instances are connected corresponding to the applied transformation. It further must de ne how the abstract syntax parts of the annotations and constraints are combined. This combination depends mainly on the transformation and the kind of annotation (e.g. on the type of axiom used in an annotation of a model element).
Considering the scenario of integrating BEDSL+OWL and PDDSL+OWL, two model elements, both annotated with a constraint, that are selected by a domain expert to be merged to one single element have to ful ll both constraints. In fact, the merged element has to keep the constraints given for the origin BEDSL+OWL model and it has to keep the constraints for the origin PDDSL+OWL model. 4.2
In the following we present two transformations that are used to combine different metamodels. The transformations themselves are de ned at the M2 layer. Furthermore we also depict how the instances at the M1 layer are changed and de ne which instances at the M1 layer are considered by the transformation by stating a pre-condition de ned by OWL axioms.
Merge Transformation. Figure 7 depicts the merge transformation on the M2 and M1 layer. Generally the two meta-concepts MA and MB are identi ed to be merged and are replaced by the meta-concept MC at the M2 layer. In addition the model elements at the M1 layer, instances of the corresponding meta-concepts at the M2 layer and visualized by a domain-speci c concrete syntax, can be merged, too. Furthermore, the concrete syntax model at the M1 layer acts as new structural language which is able to be instantiated. Its instances lie at the M0 layer (not depicted in gure 7). The merge transformation can be applied on the M2 layer and in addition on all identical instances, if the pre-condition holds for at least two instances A and B. Constraints, which are annotated at the instances A and B are combined and transformed to one single constraint of the target instance C. The new constraint depends on the kind of axioms annotated at A and B and the pre-condition (cf. section 4.3). Instances of type MA and MB which cannot be matched to identical ones are transferred together with their constraints without any change. Their new type is MC.
Specialization Transformation. Figure 8 depicts the specialization transformation on the M2 and M1 layer. Generally the two meta-concepts MA and MB are identi ed to be connected by a specialization relationship. In addition the model elements A and B at the M1 layer, instances of the corresponding meta-concepts at the M2 layer can be transformed too.
Based on intensional knowledge of domain experts we assume that an instance A of MA is a super-concept of an instance B of MB, if the name of A is pre x of the name of B (like Cisco of Cisco7603 ). Furthermore if A is a super-concept of B we assume that the set of instances of B is a subset of instances of A at the M0 layer.
As a consequence we can describe this intensional domain knowledge by the following semantic description, which further acts as a pre-condition of the specialization transformation:
C l a s s : B SubClassOf : A
The specialization transformation can be applied on the M2 layer and in addition on all instances A and B, which ful ll the pre-condition. Constraints, which are annotated at the instance A are combined by the transformation with the ones of B. Instances of MA and MB which do not match the sub-concept condition are again together with its constraints transferred without any changes. 4.3
In the following we want to consider the two above presented integration transformations and consider the constraints and additional semantics, which are de ned by annotations. In fact using OWL as a constraint language these constraints are OWL class axioms. Thus in the following we will consider the combination of class axioms and transformations.
{ The SubClassOf axiom allows to state that each instance of a subclass is also an instance of the corresponding superclass. Table 1 depicts the resulting constraints after one transformation is applied on two M1 concepts A and B and its corresponding SubClassOf axiom. Here the pre-condition of the transformation is taken into account.
Before any Transformation { The EquivalentClasses axiom allows to state that several class expressions are equivalent to each other. Table 2 depicts the resulting constraints after one transformation is applied on two M1 concepts A and B and its corresponding EquivalentClasses axiom. Here the pre-condition of the transformation is taken into account. { The DisjointClasses axiom allows one to state that several class expressions are pairwise disjoint. Table 3 depicts the resulting constraints after one transformation is applied on two M1 concepts A and B and its corresponding Class: A EquivalentTo: ClassExpressionA Class: B EquivalentTo: ClassExpressionB
DisjointClasses axiom. Here the pre-condition of the transformation is taken into account. Class: C EquivalentTo: ClassExpressionA
Class: A EquivalentTo: ClassExpressionA { The DisjointUnion axiom allows to de ne a class as a disjoint union of several class expressions and thus to express covering constraints. Table 4 depicts the resulting constraints after one transformation is applied on two M1 concepts A and B and its corresponding DisjointUnion axiom. Here the pre-condition of the transformation is taken into account.
Before any Transformation
If after a transformation two axioms of di erent types are connected to one merged or specialized model element, they are not combined in our approach. For example in table 5, after applying the merge transformation the EquivalentWithand the SubClassOf axiom are not combined. Although the transformed model element C (resp. A and B) at the M1-layer ful lls both axioms/constraints because the axiom-based OWL2 ontology, which later could be extracted from the merged domain model, provides a conjunction of all axioms. Class: A SubClassOf: ClassExpressionA Class: B EquivalentTo: ClassExpressionB
Class: C SubClassOf: ClassExpressionA EquivalentTo: ClassExpressionB In the following we consider the merge transformation. At rst we present its de nition at the M2 layer. Afterwards we give an idea of how to use it by considering the domain models presented in section 3.2.
provides the concept Entity and PDDSL+OWL provides the concept Element. Both concepts can be identi ed to be merged, because to apply the merge transformation we require that some instance of Entity is identical with some instance of Element. As later shown, this will be the Cisco element at the M1 layer. Figure 9 depicts an instance of the Merge Transformation on the M2 layer. Result of the transformation is the new class EntityElement, which merges the single concepts of Element and Entity. All OWL constructs which are connected with Element and Entity at the M2 layer are combined by the transformation as well. Transformation at the M1 layer. After presenting the merge transformation at the M2 layer we show in the following how it is adopted on the M1 layer. In the left side of gure 10 we have excerpts of two domain models conforming to the BEDSL+OWL and PDDSL+OWL metamodel. Both models contain the concept Cisco and we assume that these concepts are equivalent. Thus the precondition axiom for the merge transformation is ful lled and we can merge both to one single concept Cisco, which now is instance of EntityElement.
Because both Cisco concepts in the domain models on the left are restricted by constraints, these constraints have to be considered by the transformation, too. In the example the transformation at the M1 layer has to identify if the two concepts to be merged both are annotated by a SubClassOf axiom. If so, the transformation has to combine the two annotations automatically. In the example in gure 10 the class expression (containsCard some Supervisor) and (containsSlot some CiscoSlot) and the class expression hasConfig some CiscoConfiguration are combined by using an and-operator. After the transformation a valid Cisco still has to contain a Supervisor card and it still has to be connected to at least one CiscoConfiguration.
Besides the constraints annotated directly at the Cisco model elements there exists one global constraint in each of the domain models (not depicted in gure 10). These constraints are not merged because in our approach only the ones with equal class expressions are merged. In fact, this is not the case here and thus the global constraints are only transferred independently and without any change to the integrated model.
)s SubClassOf: e 1 itscnan a(ncdon(tacionnstCaairndsSsloomtesoSumeperCviiscsoorSl)ot) M tr(ceno BMEoDdeSlL + OWL Cisco e c
SubClassOf: hasConfig some CiscoConfiguration
Cisco
PDDSL + OWL
Model tr a n s fr o m
SubClassOf: ((containsCard some Supervisor) and (containsSlot some CiscoSlot)) and (hasConfig min 1 CiscoConfiguration)
Cisco MBEoDdeSlL(I+ntPegDrDatSeLd +MOodWeLl)
The approach presented in [
In [
[
In this paper we have presented an approach of combining constrained domain
models. In section 3 we presented two DSLs, namely BEDSL and PDDSL and
showed how they are integrated with the ontology language OWL2. Thus it is
possible to de ne several class axioms adopted on concepts of domain models
or property restrictions adopted on attributes of concepts. Because there is the
need to integrate the enriched BEDSL and PDDSL we presented the idea of
integrating the domain models and simultaneously combining the constraints of
each domain model in section 4. Therefore we extended our integration approach
presented in [
The transformation considers the additional constraints of enriched domain models. If constraints exist the right combination of them has to be applied. We have seen that these combinations are language dependent and thus have to be de ned by a DSL designer before integrating the languages.
Based on the user-de ned pre-condition and existing constraints in the model the transformation is able to compute the new constraints of the transformed model elements. We have shown two transformations how the combination can be derived from the pre-conditions of the transformations. Generally, our presented approach would be useable for integrating other languages and their constrained models (e.g using OCL instead of OWL2).