an integrated view on modeling with multiple domain ... - CiteSeerX

AN INTEGRATED VIEW ON MODELING WITH MULTIPLE DOMAIN-SPECIFIC LANGUAGES Henrik Lochmann SAP Research CEC Dresden Chemnitzer Str. 48 01187 Dresden, Germany [email protected] ABSTRACT The use of domain-specific languages (DSLs) has been shown to raise the level of abstraction, increase productivity and ease maintenance and evolution in software development. Development of and tooling for a single DSL is well-studied, but surprisingly little is known about the interplay of different DSLs in a single system. Multiple DSLs are required when moving from toy examples to real enterprise applications. Method and tool support is needed if multiple DSL development is to succeed. In this paper, we propose a novel method for development with multiple DSLs which fills this gap. The method specifically tackles the problem of overlapping concerns between different DSLs. It has three steps: 1) Identification, 2) Specification, and 3) Application. We explain these steps using a suite of prototype tools and documented case studies.

1

Introduction

The idea of using a domain-specific language (DSL) to raise the level of abstraction in software development has gained a lot of interest in the last decade. Significant research contributions have provided tools and methods to create and maintain a DSL. However, for many realistic industrial software systems, a single DSL only solves a limited part of the problem. Complex, real-world systems require multiple DSLs and impose new challenges for DSLbased approaches [12, 18, 24, 35]. Specifically, how do we offer tool- and method-support for development with multiple DSLs in a single system? How can we assist developers in navigating and maintaining consistency between programs/models written in different DSLs? Can we offer developer guidance such as intelligent assistance and completion for a range of DSLs? Ideally guidance should be provided by a language agnostic mechanism such that old languages can be evolved and new languages can be added without significant changes to the tool infrastructure. In this paper, we propose a novel method specifically for development with multiple DSLs. Our main focus is on the coordination mechanisms between different DSLs and we show how these mechanisms can be used to provide navigation, consistency checking and guidance. The coordination mechanisms are relevant when multiple DSLs

Anders Hessellund IT University of Copenhagen Rued Langgaards Vej 7 2300 København S, Denmark [email protected] have overlapping concerns or simply overlaps. The method is divided into three main steps: 1) Identification of overlaps, 2) Specification of overlaps, and 3) Application of overlaps. This method is mainly a response to problems that we have identified in earlier case studies [13, 24]. By combining previously developed tools [3, 4, 13, 14, 15, 24, 23], we assert that we can provide tool support for all steps in this method. The reader should note that this methodology does not prescribe how to develop new DSLs from scratch. Plenty of existing tools and methods already do that [2, 6, 8, 10]. Our aim is rather to provide an overall method and some individual prototypes that show how to develop with multiple DSLs on a single system (assuming that such a system already exists). Our contributions are: 1) a method for development with multiple DSLs, 2) tools that help developers use the method, and 3) two case studies of development with multiple DSLs. This paper is organized as follows: Sect. 2 introduces motivating examples for development with multiple DSLs. Section 3 explains the background and examines two different kinds of development scenarios. Section 4 introduces our development method, whose limitations are discussed in Sect. 5. Finally, Sect. 6 surveys related work and Sect. 7 concludes.

2

Motivating Example(s)

Systems composed from multiple DSLs face a common integration challenge. Overlaps between different DSLs must be managed by a coordination mechanism. In the following section, we will present two examples of coordination mechanisms and their corresponding overlaps. First, a simple soft reference which is a string-based reference between models in two different DSLs. Second, a more complex reference between three DSLs using a semantic connection. The two mechanisms are illustrated by two fairly similar examples from previously developed case studies. 2.1

Soft References

The most basic coordination mechanism between two DSLs is a soft reference. Such a reference is established

.. ..

Figure 1. The EditSurvey input form

..

Figure 2. The UpdateSurvey service

by using the exact same string key within the attribute values in two models from different DSLs. To illustrate this mechanism, we will use an example from an industrial case study, the Apache Open For Business framework (OFBiz) [35]. The OFBiz framework is an enterprise resource planning system implemented using several DSLs. As shown in a previous case study [13], the OFBiz framework relies heavily on soft references to coordinate the 17 different DSLs from which it is composed. OFBiz is an interpretive system meaning that models serve as input to a set of interpreters at runtime (cf. Sect. 3.1). For instance, the Content Management module in OFBiz allows users to manage online surveys. On the web user interface, it is possible to edit surveys using the EditSurvey form. This form is specified in a custom DSL called the Form DSL as shown in Fig. 1. When the submit button in the form is pressed, the updateSurvey service is invoked. This service is specified using the Service DSL as shown in Fig. 2. The example contains two soft references from the EditSurvey form to the updateSurvey service. The target attribute on the form tells the framework to invoke the updateSurvey service on submit. The service-name attribute on the auto-fields-service element tells the framework that it should render all parameters of the updateSurvey service as input fields in the form. This eliminates the redundancy of specifying the same set of properties both as parameters in the service and as input fields in the form. A central challenge in a framework like OFBiz is to ensure referential integrity of soft references. If a name, e.g., updateSurvey, is changed in one place then all references to that name must also be updated. Standard XML Schema cannot express this constraint since it is limited to expression of well-formedness rules within a single schema, i.e., a single DSL. Furthermore, soft references between DSLs are basically implicit syntactic constructs. They do not convey any semantic information about the system, specifically in the example above, it is not explicit what the relation is between the target attribute and the name attribute in the two DSLs. Consequently, soft references can only represent the simplest kinds of overlaps

between languages.

2.2

Semantic Connections

Some systems do actually have richer and more finegrained semantic descriptions of their language overlaps. In such systems, it is also often the case that more than two elements from two or more languages are involved in an overlap. We term these more complex overlaps: semantic connections. To illustrate semantic connections, we will use the Sales Scenario [24]. The Sales Scenario is a software product line, which was developed as case study for two research projects, viz., FeasiPLe [9] and AMPLE [1]. In the case study, we identified 7 different DSLs that facilitate modeling of business applications. As opposed to the interpretive OFBiz case, the Sales Scenario is generative. Models in the Sales Scenario serve as input to code generators that produce platform-specific implementations. Currently, the target platform is J2EE web applications based on JBoss [18]. We revisit the example from Sect. 2.1 with DSLs of the Sales Scenario as shown in Fig. 3. Comparable to the OFBiz example, the illustration shows sample models of languages for 1) user interface dialogs (view DSL), 2) data entities (data DSL) and 3) persistence services (action DSL). As the figure shows, the example now comprises a model in each of the 3 languages. The view model contains a graphical widget with a title, a text field and a save button. The data model contains a survey business object with a title attribute. The action model contains a saveSurvey action which takes an argument of type Survey and persists that. The arrows in Fig. 3 express the semantic connection between the different models: The widget from the view model shows the survey business object and invokes the saveSurvey action. The saveSurvey action furthermore modifies the survey business object. The three arrows in Fig. 3 informally describe the semantics of the overlap by conceptual relations such asshows, invokes, and modifies. This is a richer description that makes it easier to implement model-to-code transformations for these languages. It does, however, also impose new and more complex consistency requirements. Instead of merely enforcing referential integrity, it is also necessary to consider whether a reference is semantically valid. For instance, the survey business object can not modify the saveSurvey action but the opposite is perfectly fine. In other words, richer semantic connections result in richer semantic constraints that developers must be able to enforce. Current tools do not offer consistency checking of, and rarely even the ability to express, such constraints. This means that developers must rely on manual measures rather than on tool-support in the form of modeling guidance or intelligent assistance.

Figure 3. Informal illustration of a semantic connection between 3 Sales Scenario DSLs

3

Development Scenarios with Multiple DSLs

Development with multiple DSLs is a natural consequence of the old practice of using custom programming languages tailored to specific application domains. Such custom languages offer domain-specific programming abstractions and ease of use typically at the expense of the expressiveness of a full general-purpose language. Using more than a single DSL becomes necessary to handle separation of concerns and hence offer multiple views on a single system. This can of course lead to an extreme proliferation of new languages, as Landin [21] pointed out as early as 1966. Two things have, however, changed since 1966: 1) Programming is no longer an activity limited to software engineers, today DSLs are used to empower domain experts and even end-users with no formal computer science training. 2) The more recent wave of language workbenches [5, 6, 7, 8, 16, 19, 22] offers not only the simplified specification of grammars and generation of parsers but also strong IDE support for the languages. We assert that this justifies the renewed interest in DSLs and in particular our interest in development with multiple DSLs. Development with multiple DSLs is, as previously stated, used to separate concerns. There are several issues to consider when introducing multiple DSLs in a single system. In this section, we will describe the distinction between using multiple DSLs in an interpretive versus a generative scenario. This distinction influences the way overlaps between different DSLs can be represented. 3.1

Interpretive Systems

One common approach to multi-DSL development predominantly stems from the area of web application development. Here, huge managed application servers necessitate the employment of complex configuration files and other declarative assets, such as persistence mapping descriptions, navigation rules through web pages or user interface pages. These specifications have to be connected to the actual business logic and data entities, commonly im-

plemented with a general-purpose programming language. The whole integration task is accomplished by the underlying web application frameworks and application servers. Such systems are interpretive, i.e., the different software artifacts are interpreted by the runtime system. For instance, a navigation rule can maintain identifiers of certain web pages that are to be shown sequentially depending on particular user interaction. The corresponding application server module then automatically handles the delivery of the web pages that belong to these identifiers. The main advantage of this late-binding strategy is flexibility and adaptability.

data structures

behaviour descriptions

user interface

persistency mapping process flows Legacy Platform (e.g, OFBiz, JBoss)

References

Figure 4. Multi-DSL development with interpretive systems

Mappings between the software parts can be reduced to simple, string-based references as explained in Sect. 2.1. An explicit treatment of the interplay and interdependencies between different software parts is not necessary. Figure 4 illustrates such scenarios. Depicted is a software application that integrates into a legacy platform. As shown, the application consists of different solution parts that are interconnected with several references. For instance, the data structure artifact has soft references to the persistence mapping artifact, the behaviour descriptions artifact, and the user interface artifact.

Generative Systems

An alternative approach to implement multi-DSL scenarios, or model-driven systems in general, is the employment of code generators. A code generator processes binding specifications that map concepts of a modeling language to particular code assets. Code generators are metaprograms, because they are programs that produce other programs. In contrast to interpretive systems, multi DSL scenarios in generative systems do not necessarily build on execution platforms that support the use of different languages. Compared to the interpretive approach which uses a late binding strategy, code generators rely on early binding. Early binding is especially advantageous when the performance penalty of runtime interpretation is too expensive.

Interpretive Scenarios

Generative Scenarios

(e.g., OFBiz)

(e.g., SalesScenario)

1

Identification

2

Specification

f uture work

3

Application

3.2

Manual Identification

Automatic Identification

Encode Connections (e.g., Prolog or OWL)

Navigation

Consistency Ensurance

Guidance

Figure 6. A method for development with multiple DSLs DSM 2

DSM 1

DSL

data structures

behaviour descriptions

abstraction

instance of

4.1

Step 1: Identification

DSM

user interface

persistency mapping

DSM 5

DSM 3 process flows

generation

Platform Specific Code

Inter-Dependencies

DSM 4

The purpose of the Identification step is to uncover the overlaps between different DSLs. Depending on the employed multi DSL scenario (cf. Sect. 3) we can distinguish different types of references. According to available reference types, a classification mechanism is chosen that in turn prescribes what kind of modeling constructs must be identified for language connection.

Figure 5. Multi-DSL development with generative systems 4.1.1 Figure 5 illustrates multi DSL development with generative systems. As illustrated, the different domainspecific models (DSMs) that form the actual software specification are no longer interconnected with soft references, as in interpretive systems (cf. Sect. 3.1). Instead, the knowledge about language dependencies and interaction is implicitly contained in code generators that need to produce valid platform-specific program code. The lack of soft references in such systems facilitates a greater reusability of the modeling languages in other contexts. However, the generated code may include mechanisms such as soft references because at that point the implementation is tied to a particular platform.

4

A Method for Development with Multiple DSLs

Working with multiple DSLs requires a systematic approach. In this section, we present a generic method which can help developers working with systems based on multiple DSLs. Figure 6 gives an overview of our approach and outlines its three steps: Identification, Specification and Application. In the subsections below, we elaborate on the indivdual steps and illustrate them with previously introduced examples and development scenarios (cf. Sect. 2 and 3).

Reference Types

The simplest way to connect different DSLs is using explicitly typed references coming with the underlying modeling technology. The Eclipse Modeling Framework [5], for instance, provides the ability to create a typed reference from one metamodel to another. However, using typed references results in monolithic models that cause poor performance during editing or input/output operations. It also leads to strong dependencies between languages which limits reusability. Instead, the application of several small, loosely coupled models can help to improve performance and to leave languages independent. To connect languages and models in more complex cases, it becomes necessary to use implicit connections that can not be expressed with the means of the underlying modeling technology. An example of such implicit connections was introduced with soft references in Sect. 2.1. These are based on string equivalence in attribute values of different models. As also mentioned above, the use of soft references necessitates an execution platform that is aware of employed languages and can handle implicit model connections accordingly (cf. Sect. 3.1). In generative scenarios, where DSLs are intended to be reusable and composable in different contexts, advanced references are needed, such as semantic connections [3] (cf. Sect. 2.2). Here, the intentional semantics of particular modeling constructs in different languages is explicitly specified to gain the foundation for semantically sound

model connections. Figure 7 illustrates the different reference types. DSM 2

Complex Semantic Connections

Implicit Soft References

Explicit Typed References

DSM 1

Figure 7. Reference types between DSLs and models

4.1.2

Identification of the connections between different languages requires a deep understanding of the semantics of the individual languages. It is important to precisely understand the degree and nature of the conceptual overlap between different languages such that a proper fit can be achieved. This is a task best performed by domain experts that understand the individual languages. Besides domainspecific expertise, the actual identification process involves experts that know about the employed classification mechanism, in order to assist different domain experts in finding and expressing language overlaps. This development role we call composition expert or knowledge engineer. Figure 8 summarizes this view on multi DSL development roles.

Composition Expert

Domain Expert

Figure 8. Roles for language composition in multi DSL development 4.1.3

.. .. Service //ServiceType/servicename .. ..

Figure 10. The schema for the Service DSL

Roles in Identification

Domain Expert

The identified attributes then have to be tagged as matching with means of the corresponding classification mechanism. As an example, consider the use case from Sect. 2.1. In Fig. 9 the schema of the Form language is shown. The target attribute of a form has two (SmartEMF-) annotations which express that the target attribute uses the same identifier as the servicename attribute of the service element, shown in Fig. 10, in the Service DSL.

Manual Identification

Once the type of references that are used in a multi DSL development scenario are clarified, the corresponding classification mechanism dictates what kind of assets have to be identified within the modeling landscape. For instance, as soft references are based on string equivalence in attribute values in corresponding models, developers have to find link points between languages through identifying corresponding attributes in metamodels whose values match.

Figure 9. The schema for the Form DSL When dealing with complex semantic connections, however, an appropriate classification mechanism defines a framework for language connections. In [3], it has been shown how a Web Ontology Language (OWL) ontology can provide such a framework by defining concepts and roles that are common to software systems. During manual identification, domain and composition experts have to find the language overlap by identifying relevant constructs, i.e., constructs that belong to the ontological commitment [11, 20] of the language to the conceptualization given by the framing ontology. These relevant concepts then have to be interpreted by assigning appropriate concepts and roles to them. As an example, we consider the use case from Sect. 2.2. Figure 11 illustrates an excerpt of the data DSL and its semantic mapping, i.e., its identified modeling constructs. The figure’s left side shows a simplified version of the DSL’s metamodel while its right side illustrates corresponding concepts from the language ontology created for the DSL. To this end, language ontology concepts inherit from/are subsumed by concepts of the framing ontology, namely the Unified Software Modeling Ontology (USMO) [4]. The maps to arrow indicates that on the metamodel level appropriate mapping rules are defined, which trigger the creation of connecting structures during specification (cf. next section). 4.1.4

Automatic Identification

For legacy systems, it can be a rather large task to manually identify all language overlaps. New developers may

roles from the ontology. This provides us with a uniform way of describing and relating these elements such that the complete connection can be expressed. The actual encoding of this representation is done with OWL, appropriate description logic axioms and inference rules. Figure 12 illustrates an excerpt of the knowledgebase that encodes different connections at the modeling level. According to the identified semantic mapping of each DSL (cf. Sect. 4.1), corresponding language ontology concepts are instantiated. Based on this semantic frame, semantically sound references can be set by the developer. Figure 11. Semantic mapping for data DSL 4.2.2 find it challenging to understand the intricate interplay of languages in such systems; especially if the original language designers are not available. To assist developers in understanding the language interplay and uncover dependencies, it is possible to identify certain overlaps automatically. In a case study [15] of the OFBiz framework and a healthcare system called District Health Information Software (DHIS) [12], we have provided a set of algorithms that can automatically discover overlaps between languages. Specifically by examining a large set of models, we can infer properties of the languages such as soft references and specialization relations between the metamodels. Such an automatic approach cannot replace the manual identification process since it is not applicable to complex relations. It is, however, a useful and valuable way to get started when dealing with legacy systems. Automatic identification of complex semantic connections is still subject for future research, as indicated in Fig. 6 with the dashed arrow. 4.2

Full Specification

Full specification is based on the idea that not only language overlaps but the entire system should be encoded and represented in a common format. In other words, both inter- and intra-DSL consistency requirements are encoded and enforced. The main advantage of this approach is that the common representation can then be used to perform global consistency checks of the system. In the partial specification approach, it is only possible to check the integration of languages. Full specification may, however, be significantly less scalable in large systems since a lot of information has to be entered into a single knowledge base. An example of full specification can be found in the SmartEMF tool [13]. Fig. 13 shows an excerpt of how the example from Fig. 1 and Fig. 9 in the example in Sect. 2.1 can be mapped to a single representation. SmartEMF uses Prolog as its single representation. As the figure shows, all elements in both metamodel and the individual models are mapped to Prolog facts. Overlaps between metamodels are specified as Prolog rules which can be evaluated along with the other general consistency rules.

Step 2: Specification

The purpose of the Identification step was to identify connections between different languages. The Specification step encodes these connections in a way that will make them amenable to various analyses. The primary purpose of this step is to find the most suitable representation of the languages, their connections and the models written in these languages. In this section, we will discuss two specification-approaches based on inference engines: partial and full specification. 4.2.1

Partial Specification

Partial specification is based on the idea that only the conceptual overlaps between languages have to be encoded. By only encoding language connections, we can minimize the specification effort. As introduced in Sect. 4.1, the Unified Software Modeling Ontology is proposed, which can serve as a common frame of reference when specifying language connections. The elements that take part in the language connection are classified according to concepts and

Figure 13. SmartEMF’s mapping from artifacts to Prolog

4.3

Step 3: Application

The last step of our method is Application where the encoded connections from the previous two steps are used. In the specification approaches that we have described, an inference engine is used. This means that apart from simple

Figure 12. Semantic mapping of DSLs to common ontology

querying we can also infer properties based on our encodings. To illustrate how such inference can be used, this section describes three areas of application: Navigation, Consistency and Guidance. 4.3.1

Navigation

The simplest form of application is navigation. A specification of language connections allows us for each single artifact to query related artifacts in the modeling landscape. The resulting traceability graph can be leveraged to visualize dependencies and relationships between modeling assets. If the developer for instance selects an attribute of the Survey data structure, we can make him aware of several, immediately related neighbors: 1) the input field in the releated EditSurvey form/dialog, and 2) corresponding updateSurvey service/action that modifies survey data objects and the related service parameter. Such cross-language navigation is useful especially when the developer changes, adds or removes keys. In case of properly specified semantic connections, navigation structures are moreover semantically qualified, which significantly enriches the meaning of inter-model references. Additionally, variability-driven use cases can benefit from the provided dependency graphs, e.g., when posing questions about impact analysis and implementation effort. In an integrated environment, like Eclipse, the navigation facility can open the relevant editors and place the cursor at the correct place in the file using source markers when the developer selects a node in the graph. 4.3.2

Consistency

A more advanced form of application is consistency checking. Both specification approaches described facilitate a degree of consistency checking. Partial specification in the form of an ontology knowledge base, encodes inter-model connections amenable to Semantic Web reasoners, such as

Pellet [33]. This allows us to check well-formedness of instantiated semantic connectors. As an example, consider the following integrity rule. The USMO concept Representative is meant to denote modeling constructs that represent particular entities (cf. Sect. 2.2 and Fig. 11). The shown integrity rule ensures that a Representative must either represent at least one instantiated entity, or alternatively modally represent at least one entity definition, as the data DSL in Sect. 2.2 declares them. In other words, the given rule states that decorative elements that are part of the partial specification, must not be dangling. Representative(r) → represents(r, p) ∨ may_represent(r, u)

(1)

Full specification, encoded in a form amenable to a full-blown Prolog engine, extends these facilities and also allows well-formedness checks within the individual languages as well as a global consistency check. One can furthermore add different kinds of custom consistency rules as described in [13], e.g., style constraints to ensure that programming conventions are obeyed. Below is a simple example of a well-formedness rule in Prolog. The rule states that attributes and references with a lower bound of 1 must have a value, i.e., have a value that is different from the constant id_UNSET. required_value_present( Object, Feature ) :not ( lower_bound( Feature, 1 ) , ( attrvalue( Object, Feature, id_UNSET ) ; refvalue( Object, Feature, id_UNSET ) ) ).

Consistency checking in a generic environment where we do not know all the involved DSLs in advance poses some interesting challenges. The challenge of checking constraints that span different languages is solved by the Specification step where the languages are mapped to a common representation. The problem of using a common format is, however, that error-reporting will be based on

this common format. Suppose that the EditSurvey input form and the updateSurvey of the example in Sect. 2 are developed in a graphical editor and an XML editor. In the graphical editor, we may wish to make an object blink if it has an error, and in the XML editor, we may want to highlight erroneous XML with the color red. It remains a research challenge how we can translate the error reports from the common, underlying representation to the two different editors.

tion domain can help to detect and resolve also semantic inconsistencies and indicate them to the developer [4]. Development with reactive and proactive guidance assumes that the underlying inference engine temporarily tolerates the inconsistency of models and indicates this inconsistency to the developer. A useful analogy is to think of modeling as configuration where the state of a configuration can be in one of three consistency states: Green The configuration is currently consistent.

4.3.3

Guidance

The most advanced form of application is full-blown modeling guidance. The concept of guidance is well-known from traditional programming. In traditional textual editors, typical forms of guidance are popups with possible completion hints as well as text-highlighting on errors. Such assistance can usually be achieved in custom editors because the editor has the syntax of the language hardcoded and can hence make suggestions that will for instance complete a statement. In graphical editors, it is possible to provide various visual clues such as preventing the developer from drawing invalid associations or by highlighting valid targets for associations [37]. More generic editors, such as for instance XML editors, can use schema information to provide completion hints. If the editor has access to the underlying representation of multiple DSLs, it is even possible to provide hints based on cross-language constraints as shown in [13]. One of the advantages of using an inference engine to store the underlying representation, as done in [3, 13, 37], is that it allows developers to infer completion hints based on more than schema awareness. In Prolog, we can for instance ask the engine for all solutions that will solve an arbitrary consistency constraint for an incomplete model. Given an incomplete model, an inference engine can suggest 1) the next valid editing operation [13] or 2) possibly even suggest a sequence of operations that will complete the entire model as shown by several others [17, 25, 26, 32, 37]. We call the first kind of completion reactive and the second kind proactive. An advanced use case for reactive and proactive guidance arises when considering software product line engineering. Here, modifications to the modeling landscape are not limited to manual changes in particular models only. One single product line feature potentially comprises many different assets that contribute new structures, behavior and functionality to several models of diverse languages. Moreover, the diversity of feature combinations makes it unpredictable how the solution models for a particular product finally look like. It is even possible that the well-formedness rules of a certain language are not violated, but the modeled specification is semantically false itself or in combination with other models. To alleviate the challenge of complexity in feature implementations and to ensure semantical correctness, domain-specific guidance can help. For instance, language ontologies that are specific to a particular solu-

Yellow The configuration is currently incomplete and hence potentially inconsistent. A sequence of constructive editing operations may however turn the configuration into the green state. Red The configuration is currently inconsistent. One or more editing operations have to be reversed in order for the model be turned into either the green or yellow state. The traffic light metaphor above is a way of indicating what kind of guidance the developer needs. When the model is in the yellow state, the development is constructive hence guidance is about suggesting new elements to be added or attributes to be set. When the model is in the red state, development is de-constructive hence guidance is about suggesting editing operations to be reversed. Both of these development modes require an underlying inference engine that does not fail on detection of simple constraint violations.

5

Discussion

First of all, one major question could already be posed about the practicability of using several languages for software specification. Instead, it would be possible to specify a system with one or more models that might be based on one single metamodel that already specifies the interplay of diverse modeling facets. The Object Management Group (OMG) tried to follow this approach with the Unified Modeling Language (UML) that provides a number of sub languages for structural and behavioral modeling. However, providing one huge metamodel is actually the attempt to establish a general-purpose modeling language, which again is not appropriate for the specifity of particular application domains. Even the ability for domain-specific extensions, e.g., with UML stereotypes, is not adequate for particular use cases. This can be witnessed by the multitude of available languages and tools [18, 35], and the increasing effort in open source communities, research and business to facilitate the creation of such assets [5, 31]. Major limitations of the presented method are related to the classification mechanism used during Identification and Specification. It must be clearly stated that not all languages are amenable to the used classification mechanism. In this respect, for instance, embedded DSLs as presented in [14] are not compatible with our approach because they

do not have explicit syntax definitions that can be annotated. In turn, the ontology for software models, USMO, was developed to capture reference knowledge of technical software models only. Therefore, computer-independent models, such as requirement or feature models, are not suitable for the concepts and roles within the ontology. With the presented method, we narrow the vision of purely model-driven software development. Consistency and explicit mutual understanding between languages builds the foundation for the production of executable programs. However, not every single implementation detail must necessarily be derivable from modeling assets. Sometimes it might be explicitly desired to influence actual program code without giving up the convenience of modeling languages. In fact, the proposed method does not harm this kind of backward compatibility. Depending on the modeling language and corresponding development scenario (cf. Sect. 3) certain programming exits can be defined, e.g., to instruct code generators to produce protected regions in source code that facilitates the injection of handwritten code [34]. This way, the whole flexibility of manual coding remains available.

tool in this area is ViewPoints [30] which has a very strong model management and consistency checking facility. Our approach can be distinguished from ViewPoints by the Identification step and our guidance facilities. In the field of modeling guidance, several approaches exist. All are limited to a single DSL with the notable exception of xlinkit [28, 29]. Xlinkit offers consistency checking and even automatic repair for multiple DSLs. As opposed to our approach, it has a strong dependency on XML and a rather verbose custom constraint language. Automatic completion of models have been proposed for several modeling languages, such as feature models [17], ATOM3 [32], and DiaMeta [25, 26]. The most powerful of these approaches is White’s GEMS-project [37] which can do socalled batch configuration or completion of entire models on demand. The GEMS tool also offers strong visual support for modeling and is backed by a Prolog inference engine similar to ours. The GEMS project does, however, not have any concept of ontological commitment nor any focus on multiple DSLs.

7 6

Related Work

There is little work on the subject of using multiple DSLs in a single system. Bentley [2] describes the interplay of little languages in UNIX but his focus is limited to the language Pic and its pre- and postprocessors. Neighbors [27] presents a more complete approach with his Draco method. In this case, multiple DSLs are linked by a refinement relation, and a tool suite consisting of parsers, prettyprinters and transformers are used to support the method. Our work is influenced by the Draco method and its ideas of domain analysis as a central part of complex software development. However, the languages that we have described here cover a much wider range of domains than Draco, and we furthermore add navigation, consistency checking and guidance rather than merely prettyprinters. These added features from the Application step is also what sets us apart from the multiparadigm specification technique proposed by Zave and Jackson [38]. In recent years, the term domain-specific modeling has attracted a lot of attention. Tools such as MetaEdit+ [19], the Generic Modeling Environment [22], the Meta Programming System [8], the eXecutable Metamodelling Facility [6], and the Microsoft DSL Tools [7] all provide means of defining and deploying DSLs. None of them, however, offer proper means of handling legacy DSLs and only few offer any out-of-the-box support for coordination of multiple DSLs. Warmer and Kleppe [36] extend the DSL tools with a bus-facility to coordinate multiple DSLs. This approach is, however, limited to models conforming to the metamodel of DSL Tools, and it does not offer the kinds of guidance that we propose. Enforcing consistency between multiple views on an application is a well-studied field. The main method and

Summary

Development with multiple DSLs is challenging. It requires rigorous method support and proper tools. In this paper, we have proposed a method which covers 3 important steps of such development and illustrated each steps with some relevant tools. Our contributions are: 1) a method for development with multiple DSLs, 2) tools that help developers use the method, and 3) two case studies of development with multiple DSLs.

References [1] AMPLE Consortium. AMPLE Research Project. www. ample-project.net, Dec 2008. [2] J. Bentley. Programming pearls: little languages. Commun. ACM, 29(8):711–721, 1986. [3] M. Bräuer and H. Lochmann. Towards Semantic Integration of Multiple Domain-Specific Languages Using Ontological Foundations. In 4th Intl. WS on (Software) Language Engineering (ATEM’07) co-located with MoDELS 2007, Nashville, TN, USA, Oct. 2007. [4] M. Bräuer and H. Lochmann. An Ontology for Software Models and its Practical Implications for Semantic Web Reasoning. In Proceedings of 5th European Semantic Web Conference, 2008. [5] F. Budinsky, D. Steinberg, E. Merks, R. Ellersick, and T. J. Grose. Eclipse Modeling Framework: a Developer’s Guide. Addison-Wesley, 2004. [6] T. Clark, P. Sammut, and J. Willans. Applied Metamodelling - A Foundation for Language Driven Development. CETEVA, 2 edition, 2008. http://www.ceteva.com/docs/ AppliedMetamodelling(SecondEdition).pdf.

[7] S. Cook, G. Jones, S. Kent, and A. C. Wills. DomainSpecific Development with Visual Studio DSL Tools. Microsoft .NET Development Series. Addison-Wesley Professional, 2007. [8] S. Dmitriev. Language Oriented Programming: The Next Programming Paradigm. onBoard, (1), November 2004. http://www.onboard.jetbrains.com/ is1/articles/04/10/lop/. [9] FeasiPLe Consortium. FeasiPLe Research Project. http: //feasiple.de, Dec 2008. [10] J. Greenfield and K. Short. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley & Sons, Indianapolis, Indiana, USA, 2004. [11] G. Guizzardi, L. F. Pires, and M. J. van Sinderen. On the role of Domain Ontologies in the design of Domain-Specific Visual Modeling Languages. In Proc. of 2nd WS on DomainSpecific Visual Languages, Seattle, WA, USA, Nov. 2002. [12] Health Information Systems Programme. District Health Information Software. http://www.hisp.info/, 2008. Seen May 7th, 2008. [13] A. Hessellund, K. Czarnecki, and A. Wasowski. Guided Development with Multiple Domain-Specific Languages. In 10th Intl. Conf. On Model Driven Engineering Languages and Systems (MoDELS 2007), Nashville, TN, USA. Springer, Sept./Oct. 2007. [14] A. Hessellund and P. Sestoft. Flow Analysis of Code Customizations. In J. Vitek, editor, ECOOP 2008 - ObjectOriented Programming, 22nd European Conference, Paphos, Cyprus, volume 5142 of LNCS. Springer, July 2008. [15] A. Hessellund and A. Wasowski. ˛ Interfaces and Metainterfaces for Models and Metamodels. In K. Czarnecki, editor, ACM/IEEE 11th International Conference On Model Driven Engineering Languages and Systems (MoDELS 2008), Toulouse, France, 2008. to appear. [16] INRIA and LINA. AMMA – ATLAS Model Management Architecture. http://www.sciences. univ-nantes.fr/lina/atl, 2007. [17] M. Janota, V. Kuzina, and A. Wasowski. ˛ Model Construction with External Constraints: An Interactive Journey from Semantics to Syntax. In K. Czarnecki, editor, 11th Intl. Conf. On Model Driven Engineering Languages and Systems (MoDELS 2008), Toulouse, France, 2008. to appear. [18] JBoss Enterprise Application Platform. http: //www.jboss.com/products/platforms/ application, 2008. [19] S. Kelly and J.-P. Tolvanen. Domain-Specific Modeling: Enabling Full Code Generation. Wiley Interscience, 2008. [20] I. Kurtev. Metamodels: Definitions of Structures or Ontological Commitments? In R. F. Paige and J. Bézivin, editors, Proc. of WS on TOWERS of models co-located with TOOLS’07, pages 53–65, 2007. [21] P. J. Landin. The next 700 programming languages. Commun. ACM, 9(3):157–166, 1966. [22] A. Ledeczi, M. Maroti, A. Bakay, G. Karsai, J. Garrett, C. Thomason, and G. N. J. S. P. Volgyesi. The Generic Modeling Environment. In Workshop on Intelligent Signal Processing, May 2001.

[23] H. Lochmann. Towards Connecting Application Parts for Reduced Effort in Feature Implementations. In Proc. of 2nd IFIP Central and East European Conf. on Software Engineering Techniques (CEE-SET’07), Posen, Poland, Oct. 2007. [24] H. Lochmann and B. Grammel. The Sales Scenario: A Model-Driven Software Product Line. In Software Engineering 2008 Workshopband, volume 122, February 2008. [25] S. Mazanek, S. Maier, and M. Minas. Auto-completion for Diagram Editors based on Graph Grammars. In Proc. of IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC 2008). IEEE Computer Society Press, 2008. [26] M. Minas. Syntax Analysis for Diagram Editors: A Constraint Satisfaction Problem. In Proc. of Working Conf. on Advanced Visual Interfaces, New York, NY, USA, 2006. [27] J. M. Neighbors. Software Construction using Components. PhD thesis, Department of Information and Computer Science, University of California, Irvine, 1980. publ. as Technical Report UCI-ICS-TR-160. [28] C. Nentwich, W. Emmerich, and A. Finkelstein. Static Consistency Checking for Distributed Specifications. In Proc. of 16th IEEE Intl. Conf. on Automated Software Engineering, Washington, DC, USA, 2001. [29] C. Nentwich, W. Emmerich, and A. Finkelstein. Consistency management with repair actions. In Proc. of 25th Intl. Conf. on Software Engineering, Washington, DC, USA, 2003. [30] B. Nuseibeh, J. Kramer, and A. Finkelstein. Expressing the Relationships Between Multiple Views in Requirements Specification. In ICSE, pages 187–196, 1993. [31] Object Management Group (OMG). Meta Object Facility (MOF). http://www.omg.org/mof/. version 2.0. [32] S. Sen, B. Baudry, and H. Vangheluwe. Domain-specific Model Editors with Model Completion. In Proceedings of MPM Workshop associated to MoDELS’07, Nashville, TN, USA, October 2007. [33] E. Sirin, B. Parsia, B. C. Grau, A. Kalyanpur, and Y. Katz. Pellet: A Practical OWL-DL Reasoner. Submitted for Publication to Journal of Web Semantics, 2007. [34] T. Stahl and M. Völter. Model-Driven Software Development: Technology, Engineering, Management. Wiley & Sons, 1st edition, 2006. [35] The Apache Software Foundation. The Open For Business Project (OFBiz). http://ofbiz.apache.org/, 2008. Seen May 7th, 2008. [36] J. Warmer and A. Kleppe. Building a Flexible Software Factory Using Partial Domain Specific Models. Proceedings of The 6th OOPSLA Workshop on Domain-Specific Modeling, October 2006. http://www.dsmforum.org/events/DSM06/. [37] J. White, D. Schmidt, A. Nechypurenko, and E. Wuchner. Domain-Specific Intelligence Frameworks for Assisting Modelers in Combinatorically Challenging Domains. In GPCE4QoS, October 2006. [38] P. Zave and M. Jackson. Where Do Operations Come From? A Multiparadigm Specification Technique. IEEE Trans. Softw. Eng., 22(7):508–528, 1996.