A Domain Specific Language for Generating Tool Integration Solutions Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, Martin T¨orngren Embedded Control Systems Royal Institute of Technology Stockholm, Sweden {biehl,jad,loiret,martin}@md.kth.se

Abstract. Model-based development of complex systems requires tool support for the different phases of the system life cycle. To allow for an efficient development process, the involved tools need to be integrated. Despite the availability of modern tool integration platforms and frameworks, it is complex, labor-intensive and costly to build tool integration solutions. For managing the growing complexity of tool integration solutions, a need for systematic engineering arises. A missing piece is the high-level architectural description of tool integration solutions. We propose the domain specific language TIL for describing tool integration solutions at a high level of abstraction. We propose an approach that takes advantage of modeling technologies to systematize and automate the process of building tool integration solutions. By automatically generating integration solutions from a TIL model, we can reduce the manual implementation effort. Key words: Model-driven Development, Tool Integration, Domain Specific Language, Code Generation

1

Introduction

The model-based development of complex systems, such as automotive or aerospace embedded systems, involves a diverse set of models. These models represent different views of the system with respect to the involved disciplines, development activities or life cycle phases. In order to edit, analyze or simulate the models, different and dedicated tools are typically used. One approach to deal with the large number of heterogeneous tools is to manually translate, synchronize and update the data between the different tools, but it leads to development inefficiencies. Another approach is to build a tool integration solution that takes care of the necessary data exchange and trace links between the tools, but this integration solution needs to be built and extended manually for each new development tool. In this paper we follow the vision of automating the construction of such tool integration solutions. Tool integration is concerned with the relationships among tools, the properties of the relationship and the degree to which tools agree [25]. The goal of

2

Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, Martin T¨ orngren

tool integration is building tool chains or an integrated engineering environment out of isolated development tools [4]. The assumption of the research community is that using an engineering environment with several integrated tools increases productivity and product quality [27]. In this work, we are not concerned with the benefits of using tool integration solutions but rather focus on the process of building tool integration solutions systematically and efficiently. For a long time, approaches to tool integration used ad-hoc, pairwise point to point integration between tools. Modern tool integration solutions are built based on tool integration platforms, which allow for the reuse of common integration functionality. This increases the efficiency of building integration solutions. However, for each integrated tool, these platforms require extensive manual configuration, tailoring and adherence to standards. Despite many recent innovations in this field such as tool integration frameworks and platforms, it requires a lot of manual work. Building tool integration solutions is still costly and labor intensive. The importance of having integrated tools in the development process is more and more recognized. As a consequence the demands for tool integration solutions are growing. Users expect that modern integration solutions are built based on standards, frameworks and established technology with extendability and scalability for new tools. Thus the complexity of tool integration solutions is increasing. For managing the growing complexity of tool integration solutions we need to move away from ad-hoc integration between tools. The need for systematic engineering of tool integration solutions arises. A missing piece is the high-level architectural description of a tool integration solution, an approach often used in other domains. This leads to the question: In how far can we systematize and automate building modern tool integration solutions? In this paper we analyze new possibilities for automation and describe an automated approach for increasing the efficiency of building tool integration solutions. We propose the domain specific modeling language TIL for describing tool integration solutions at a high level of abstraction. We also describe how we can generate code from TIL models. This paper is structured as follows. Section 2 introduces the state of the art in the field of tool integration. Based on this analysis, we discover possibilities for automating the process of building tool integration solution in section 3. We introduce TIL in section 4, which is a language for describing and generating tool integration solutions. We illustrate how to use TIL on an example in section 5. We compare our approach to related approaches in section 6 and conclude in section 7.

2

State of the Art in Tool Integration

A broad overview of the literature on tool integration is provided in the annotated bibliographies of Brown [4] and Wicks [28]. The scope of tool integration is defined using the following dimensions [25, 26]: Data integration shares the data produced by different tools and manages the relationship between the data ob-

A Domain Specific Language for Generating Tool Integration Solutions

3

jects, control integration allows tools to notify and activate other tools, presentation integration provides a common user interface with a common look-and-feel, process integration provides process management tools with data from development tools and platform integration provides a virtual operating environment for tools based on heterogeneous hardware and software. Tool integration frameworks and platforms provide common functionality for building tool chains. Examples are ModelBus [12] or the Jazz Foundations [10]. The OSLC initiative (Open Services for Lifecycle Collaboration) aims to standardize different components of tool integration solutions [23]. OSLC is an industrial effort, where the specifications are organized into topics such as Requirements Management, Change Management, etc. These specifications are based on a set of core specifications and guidelines, ensuring commonality between them. Data is described using OSLC Resources. These resources are made available via web services using a RESTful (Representational State Transfer) [9] architecture. The OSLC Core Specification describes how resources (called OSLC Resources) and resource types (called OSLC Resource Shapes) are defined in a domain specification.

3

Discovering Possibilities for Automating the Building of Tool Integration Solutions

It is our goal to automate the process of building tool integration solutions. As a first step we identify common building blocks occurring in tool integration solutions. We study different integration styles and identify commonalities between them. We describe in detail the building blocks which are common to all integration styles, as these elements are candidates for concepts in our language for tool integration.

3.1

Delimitation

In this paper we use the words tool chain and tool integration solution interchangeably and a tool chain does not necessarily imply that tools are used in a certain sequence. Tool integration has several dimensions and in this paper we focus on the dimensions of control and data integration, which we will analyze separately. Tool integration scenarios can be described in two ways: data centric and control centric approaches. (1) Control-centric approaches focus on the invocation of services, activation of tools and notification. (2) Data-centric tool integration approaches can be divided into two classes: (2a) information exchange and reuse of development information by transferring data between tools (2b) linking and tracing of development information without actually moving data. In this work we combine control-centric approaches (1) with data-centric approaches in the flavor of information exchange (2a).

4

Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, Martin T¨ orngren

3.2

Tool Integration Styles

A number of established styles for tool integration are used in integration solutions today. These styles are not mutually exclusive and can be combined, when building a concrete tool integration solution. We introduce these styles here, in order to analyze them and identify common elements in them. – Integrated Datamodel: Tools map their data onto a common integrated repository with a unified datamodel [17]. A closely related approach are ontologies, where tools map their data to an ontology, which defines the relationships between the tool-specific ontology elements [16, 15, 19]. An industrial use of this integration style is EAST-ADL [5] for the automotive embedded systems domain. – Process Flows: Tools are connected to an integration bus and a workflow describes the exchange between different tools [17]. An industrial use of this integration architecture is the CESAR Reference Technology Platform [2] for cross-domain embedded systems. It is based on the ModelBus platform [12]. – Service-oriented: Each tool provides a proxy component, which exposes tool functionality and data as services. Services allow for a loosely coupled, decentralized architecture. Service-oriented tool integration can be based on web-service technology and allows for uniform access of tool data and tool functionality. Service-oriented tool integration is increasingly used in industry, as the industrial OSLC initiative shows. 3.3

Common Building Blocks in Data Integration

As detailed in [3], data integration has two purposes: resolving structural differences between the datamodels of integrated tools and dealing with differences in the technical representation. This is why most integration styles for data integration have three basic building blocks: (1) Tool adapters, which bring tool data into a common technical space and (2) transformations, which resolve structural differences between tools by mapping corresponding data. In addition all integration styles have the concept of (3) a common representation of tool data, a common ground for integration, called the technical space for integration. For each of these building blocks we assess the suitability for automatic generation. (1) A tool adapter provides a bi-directional mapping between the technical space of the tool and the technical space of integration. A tool adapter extracts data from a tool to represent the data in the technical space for integration and it injects data into the tool, when new data is available in the technical space for integration. A tool adapter consists of two interfaces and logic that translates between the interfaces. One interface, called tool interface, is used to interact with the tool. The other interface, called integration interface, is used to interact with other integrated tools, an integration platform or an integration framework. If the metametamodel of the tool and of the integration are known, automation is possible. In this case the tool adapter works similar to M3-level

A Domain Specific Language for Generating Tool Integration Solutions

5

bridges [18]. Metametamodels are usually very similar, so that a mapping can be found, however, the mapping might involve a loss of information. The creation of tool adapters can be automated to different degrees: – Semi-automated adapter generation: In the general case, we do not have knowledge about the tool interface, which prevents us from generating the translation logic. The integration interface and necessary description files of the adapter can be generated. – Fully automated adapter generation: If the tool interface is known, full automation is possible. The integration interface of the adapter as well as the translation logic can be automatically generated. (2) A transformation provides a bi-directional mapping between two metamodels that preserves the semantics. The automatic generation of transformations for the purpose of tool integration is difficult, as it requires an interpretation of the metamodels, i.e. knowledge of the semantics of all involved tools. This interpretation is hard to automate in the general case. Mappings between two metamodels can be computed automatically under the assumption that the metamodels are similar. So called matching algorithms compute mappings between two given metamodels. The approaches are heuristics, i. e. follow a besteffort strategy using metrics. Relevant metrics are structural similarity of the metamodels [8], naming similarities between metamodel elements or a combination of different metrics [7]. A domain specific language for specifying matching algorithms has been proposed [11]. (3) A common technical space is a precondition for being able to perform transformations. The technical space for integration comprises all the technology used for representing and manipulating data. It is usually based on conventions and standards.

3.4

Common Building Blocks in Control Integration

Control integration allows tools to notify users, activate tools, call a specific functionality in another tool, trigger data exchange or trigger a transformation. Similar to data integration, there needs to be a common technical space for integration, which allows unified access of control functionality from different tools. Notification of a user can be as simple as sending an email to the user. Activation of a tool means starting the tool (with a set of parameters or input models) and bringing it to the front, so the user can work with it. Calling a functionality in a tool means that some feature or function of a tool can be triggered. This presupposes that the function is made accessible in the technical space for integration by the tool adapter. Often data needs to be exchanged between tools. If the tools support the same data format, data exchange is easy. Usually tools have different formats and a transformation is necessary. Control integration can be used to trigger both simple data exchange or transformations.

6

Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, Martin T¨ orngren

4

TIL - A Tool Integration Language

Tool integration solutions consist of several building blocks that are composed. We can automate both the composition of the building blocks and the building of individual building blocks. We propose a model-driven approach, which uses a domain specific language for tool chains. The domain specific language describes the composition of building blocks. For each newly integrated tool a new tool adapter needs to be created. For the data that is supposed to be exchanged between the tools, a transformation of the relevant tool data needs to be written. We also need to create the control logic, specify notifications and activation of different tools. 4.1

Language Concepts of TIL

The first step in our approach is finding common patterns used in tool integration solutions. These are candidates for language concepts. Our language consists of two basic, abstract types: channels and components, where components are connected by channels. We distinguish between several types of components: Tool Adapters, Repositories, Sequencers and Users. Channels connect components and are always directed. We differentiate Control Channels and Data Channels. In the following, the concepts are introduced in detail. – Users: describe the interaction of the tool chain with a user. Incoming control channels denote a notification to the user, e.g. by e-mail. Outgoing control channels denote an action triggered by the user. – Tool Adapters: are components that expose both functionality and data of an integrated tool. Tool adapters are described by a tool metamodel based on EMF. Tool adapters provide and accept data that corresponds to the tool metamodel. Tool adapters also provide services that expose the functionality of the tool, which is usually available via the user interface of the tool. – Repositories: are components that provide storage of tool data. Repositories accept data corresponding to registered metamodels. – Sequencers: execute multiple services in a defined sequence. They have incoming and outgoing control channels: The incoming control channel triggers the execution of the sequencer. The control channel might originate from any component or user. Outgoing control channels can activate a data channel or component in a predefined order. – Data Channels: transfer data between components. The realization of a data channel can entail calling a transformation to deal with the heterogeneous consumers and producers. A transformation can be explicitly modeled and attached to a data channel to resolve structural heterogeneities between tool metamodels. If no transformation is attached to the data channel, but consumer and producer expect different data, an implicit transformation is created. Data channels need to be activated by a control channel. As a byproduct of the data exchange over the data channel a trace may be created, if a trace channel is present at the same time.

A Domain Specific Language for Generating Tool Integration Solutions

7

– Control Channels: are directed edges between a source component and a target component. They denote a source component activating the target component or invoking a service of the target component. If the control channel points at a data channel, it activates the data exchange over the data channel. – Trace Channels: describe the link of data between different components. 4.2

Generating Tool Integration Solutions from a TIL model

Given a model of the tool integration solution described in TIL, we can generate some parts of the tool integration solution. – We need to make a decision for the technical space of integration, e.g. OSLC. Also, a tool integration framework, platform or standard providing common functionality used in the tool integration solution needs to be chosen. – We can generate a tool adapter based on its assigned tool metamodel. – For each data channel, we analyze the source and target tool metamodel. If source and target are different, we calculate a proposed transformation using a matching algorithm and the metamodels of consumer and producer, similar to [8, 7]. – Generating code for control channels requires some more interpretation. We organize the different options in table 1.

Source Target Action User Any Realized as an event handler e.g. onClick() Repository Any Realized as an event handler e.g. onCommit() Tool Adapter Any Calls service in another tool or activates it Sequencer Any Calls service in another tool or activates it Any Sequencer Activates the sequencer Any Data Channel Transfers the data and executes the transformation if necessary Any Tool Adapter Activates the tool or calls a service of the tool Any User Sends a mail or notification to the user. Table 1. Overview of the Possibilities for Realizing Control Channels

5

An Example for Tool Integration with TIL

We illustrate the usage of TIL by describing an existing integration scenario from automotive embedded systems development [1]. The desired tool integration scenario depicted in figure 1 can be described as follows: We connect a UML design tool with a safety analysis tool and a repository. Each time the designer uses the UML design tool to check-in a new version of the UML design model into the repository, the safety analysis is triggered. This tool chain for developing safety critical systems ensures that safety is considered during design. Building a tool integration solution with TIL involves four steps:

8

Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, Martin T¨ orngren

Fig. 1. Tool Integration Solution described in TIL

1. The tool chain designer creates a high-level TIL model of the scenario. We use a visual syntax for the concepts introduced in section 4.1 to describe the tool integration scenario in figure 1. 2. The designer creates or reuses existing tool metamodels for the UML design tool and for the safety analysis tool (see figure 2). The metamodel for the UML design tool is also assigned to the repository, indicating that the repository stores UML models. 3. Once the integration solution is described with TIL, we can start the automated generation of the tool integration solution. We first generate our data integration solution. The tool metamodels are used for generating tool adapters for each of the two tools. These tool adapters provide access to both the data and the functionality of the tool in the chosen technical space for integration. In addition a transformation is generated, since the right data channel has different source and target metamodels. Control logic can be generated as well, based on the rules for generating code from control channels provided in section 4.2. User events will be generated for activating the UML tool adapter and for triggering the data channel to the repository. An event handler is generated for handling checkins in the repository. This event triggers the execution of the sequencer, which first calls the transformation from a UML model to the safety analysis model and then activates the safety analysis tool. 4. Manual adjustments of the tool adapters, or tweaking of the transformation rules might be necessary.

6

Related Work

The topic of integration is widely discussed outside the narrow scope of tool integration and can provide insights, which are relevant for tool integration as well. Enterprise Application Integration (EAI) is concerned with integrating business software [13]. Similar to our approach, EAI identifies several common integration patterns that can be used to both reason about integration and to quickly

A Domain Specific Language for Generating Tool Integration Solutions

Fig. 2. Tool Metamodel for the Safety Analysis Tool

9

10

Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, Martin T¨ orngren

construct integration solutions. The patterns can be put in relation with each other to form a pattern language. They provide modeling tools for constructing integration solutions and generate code from them. One example is the Apache Camel [14]. Languages such as BPMN [22], BPEL [20] and SPEM [21] provide the possibility to describe processes and potentially describe the interaction between tool adapters. These languages, however, have a different purpose, they describe business processes or development processes and not tool integration scenarios. They also are not intended for and do not have explicit support for generating tool integration solutions. Other languages for tool integration focus exclusively on the transformation aspect. The CAR mapping language [24] is an example for an integration language based on patterns. The TROPIC project focuses on building a higherlevel transformation language for tool integration issues, which is based on colored Petri-nets. The AMW approach for model weaving [6] proposes a weaving model which is subsequently translated into an executable ATL Transformation. We have found several languages for tool integration, however, they all take different angles and differ in coverage. Existing approaches are very detailed and focus on describing a particular aspect of tool integration. Our approach on the other hand focuses on the big picture and aims at describing tool integration on a high level of abstraction.

7

Conclusions and Future Work

In this paper we have described the need for a systematic engineering approach to building tool integration solutions. We analyze the possibilities for automatically generating tool integration solutions. We propose TIL, a high-level domainspecific architectural description language for tool integration solutions. We describe how to use TIL for the design of a new tool chain. Architecture description languages are usually used both for design and for analysis. In the future we want to explore how TIL models can be used for analysis as well. The presented language is now in its first version and is work in progress. In the future we will extend and refine the language, e.g. with additional concepts and configuration parameters. We plan to implement TIL as an EMF-based domain specific language. We are working on automated adapter generation and will also investigate the generation of transformations for realizing data channels. Traceability is an important part of tool integration. We need to analyze more closely, what the needs of traceability are and how TIL can express traceability. Based on the TIL traceability concepts we want to generate code that creates traceability links automatically. Our approach allows for the description of a tool integration solution and the generation of source code. We will need to analyze in which cases a full automation is possible and when semi-automation can be used. In any case, the approach has potential to increase the efficiency of building future tool integration solutions and tool chains.

A Domain Specific Language for Generating Tool Integration Solutions

11

References 1. Eric Armengaud, Markus Zoier, Andreas Baumgart, Matthias Biehl, DeJiu Chen, Gerhard Griessnig, Christian Hein, Tom Ritter, and Ramin T. Kolagari. Modelbased Toolchain for the Efficient Development of Safety-Relevant Automotive Embedded Systems. In SAE 2011 World Congress & Exhibition, April 2011. 2. Andreas Baumgart. A common meta-model for the interoperation of tools with heterogeneous data models. In 3rd Workshop on Model-Driven Tool & Process Integration (MDTPI2010) at the European Conference on Modelling Foundations and Applications (ECMFA2010), June 2010. 3. Matthias Biehl, Carl-Johan Sj¨ ostedt, and Martin T¨ orngren. A Modular Tool Integration Approach - Experiences from two Case Studies. In 3rd Workshop on Model-Driven Tool & Process Integration (MDTPI 2010) at the European Conference on Modeling Foundations and Applications (ECMFA 2010), June 2010. 4. Alan W. Brown and Maria H. Penedo. An annotated bibliography on integration in software engineering environments. SIGSOFT Softw. Eng. Notes, 17(3):47–55, 1992. 5. Philippe Cuenot, Patrik Frey, Rolf Johansson, Henrik L¨ onn, Yiannis Papadopoulos, Mark-Oliver Reiser, Anders Sandberg, David Servat, Ramin T. Kolagari, Martin T¨ orngren, and Matthias Weber. The EAST-ADL Architecture Description Language for Automotive Embedded Software. Model-Based Engineering of Embedded Real-Time Systems, 2010. 6. Marcos Del Fabro, Jean B´ezivin, Fr´ed´eric Jouault, and Erwan Breton. AMW: A generic model weaver. In Premiered Journees sur l’Ingenierie Dirigee par les Modeles, July 2005. 7. Marcos Del Fabro and Patrick Valduriez. Towards the efficient development of model transformations using model weaving and matching transformations. Software and Systems Modeling, 8(3):305–324, July 2009. 8. Jean-R´emy Falleri, Marianne Huchard, Mathieu Lafourcade, and Cl´ementine Nebut. Metamodel Matching for Automatic Model Transformation Generation. In Krzysztof Czarnecki, Ileana Ober, Jean-Michel Bruel, Axel Uhl, and Markus V¨ olter, editors, Model Driven Engineering Languages and Systems, volume 5301 of LNCS, chapter 24, pages 326–340. 2008. 9. Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. 10. Randall Frost. Jazz and the Eclipse way of collaboration. IEEE Software, 24(6):114–117, November 2007. 11. Kelly Garc´es, Fr´ed´eric Jouault, Pierre Cointe, and Jean B´ezivin. A Domain Specific Language for Expressing Model Matching. In Proceedings of the 5`ere Journ´ee sur l’Ing´enierie Dirig´ee par les Mod`eles (IDM09), 2009. 12. C. Hein, T. Ritter, and M. Wagner. Model-Driven Tool Integration with ModelBus. In Workshop Future Trends of Model-Driven Development, 2009. 13. Gregor Hohpe and Bobby Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, 1 edition, October 2003. 14. Claus Ibsen and Jonathan Anstey. Camel in Action. Manning Publications, pap/psc edition, January 2011. 15. Gerti Kappel, Elisabeth Kapsammer, Horst Kargl, Gerhard Kramler, Thomas Reiter, Werner Retschitzegger, Wieland Schwinger, and Manuel Wimmer. Lifting Metamodels to Ontologies: A Step to the Semantic Integration of Modeling Languages. MODELS, 4199:528–542, 2006.

12

Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, Martin T¨ orngren

16. E. Kapsammer, H. Kargl, G. Kramler, T. Reiter, W. Retschitzegger, and M. Wimmer. On Models and Ontologies - A Layered Approach for Model-based Tool Integration. In MOD2006, pages 11–27, 2006. 17. Gabor Karsai, Andras Lang, and Sandeep Neema. Design patterns for open tool integration. Software and Systems Modeling, 4(2):157–170, May 2005. 18. Heiko Kern. The Interchange of (Meta)Models between MetaEdit+ and Eclipse EMF Using M3-Level-Based Bridges. In Jeff Gray, Jonathan Sprinkle, Juha-Pekka Tolvanen, and Matti Rossi, editors, 8th OOPSLA Workshop on Domain-Specific Modeling at OOPSLA 2008, pages 14–19. University of Alabama at Birmingham, 2008. 19. G. Kramler, G. Kappel, T. Reiter, E. Kapsammer, W. Retschitzegger, and W. Schwinger. Towards a semantic infrastructure supporting model-based tool integration. In GaMMa ’06: Proceedings of the 2006 international workshop on Global integrated model management, pages 43–46, New York, NY, USA, 2006. ACM. 20. OASIS. OASIS Web Services Business Process Execution Language (WSBPEL) TC. Technical report, ”OASIS”, April 2007. 21. OMG. Software & Systems Process Engineering Metamodel Specification (SPEM). Technical report, ”OMG”, April 2008. 22. OMG. Business Process Model And Notation (BPMN). Technical report, ”OMG”, January 2011. 23. OSLC Core Specification Workgroup. OSLC core specification version 2.0. Technical report, Open Services for Lifecycle Collaboration, August 2010. 24. Thomas Reiter, Kerstin Altmanninger, and Werner Retschitzegger. Think Global, Act Local: Implementing Model Management with Domain-Specific Integration Languages. In Thomas K¨ uhne, editor, Models in Software Engineering, volume 4364 of LNCS, chapter 32, pages 263–276. Springer Berlin Heidelberg, Berlin, Heidelberg, 2007. 25. I. Thomas and B. A. Nejmeh. Definitions of tool integration for environments. Software, IEEE, 9(2):29–35, March 1992. 26. Anthony I. Wasserman. Tool Integration in Software Engineering Environments. In Fred Long, editor, Software Engineering Environments, International Workshop on Environments Proceedings, Lecture Notes in Computer Science, pages 137–149. Springer-Verlag, September 1989. 27. M. Wicks and R. Dewar. A new research agenda for tool integration. Journal of Systems and Software, 80(9):1569–1585, September 2007. 28. M. N. Wicks. Tool Integration within Software Engineering Environments: An Annotated Bibliography. Technical report, Heriot-Watt University, 2006.