A Modeling Language for the Description and Development of Tool Chains for Embedded Systems
MATTHIAS BIEHL
Doctoral Thesis Stockholm, Sweden, 2013
TRITA-MMK 2012:09 ISSN 1400-1179 ISRN/KTH/MMK/R-12/09-SE ISBN 978-91-7501-426-5
KTH School of Industrial Engineering and Management 10044 Stockholm Sweden
Academic thesis, which with the approval of the Royal Institute of Technology, will be presented for public review in fulfillment of the requirements for a Doctorate of Technology in Machine Design. The public review is held in Room F3, Lindstedtsv¨ agen 26, Royal Institute of Technology, Stockholm on 2013-01-17 10:00. c Matthias Biehl, 2013, Version 20121211174100
Print: US-AB
iii Abstract The development of embedded systems is typically supported by a number of diverse development tools. To achieve seamless tool support throughout the embedded systems development process, tool chains are constructed as software solutions that integrate the development tools. Tool chains have grown from ad-hoc solutions to complex software systems, since they need to support distributed engineering, integration conventions, a specific set of tools and the complete product development process used in a company. In practice, the development of tool chains that fulfill these needs is difficult and time-consuming, since it is a largely unsupported, manual engineering task. In addition, tool chains are typically described using general purpose modeling languages or languages borrowed from other domains, which contributes to the accidental complexity of tool chain development. Due to the increasing sophistication and size of tool chains, there is a need for a systematic, targeted description and development approach for tool chains. This thesis contributes with a language for the systematic description of tool chains and semi-automated techniques to support their development. • The Tool Integration Language (TIL) is a domain-specific modeling language (DSML) for tool chains that allows describing tool chains explicitly, systematically and at an appropriate level of abstraction. TIL concepts are from the domain of tool integration and express the essential design decisions of tool chains at an architectural level of abstraction. A TIL model serves as a basis for the development of a tailored tool chain. • Semi-automated techniques for the specification, analysis and synthesis support the development of tool chains that are described as TIL models. Specification techniques support the creation and refinement of a tool chain model that is aligned to a given development process and set of tools. Domain-specific analysis techniques are used to check the alignment of the tool chain model with the supported process. Synthesis techniques support the efficient realization of the specified tool chain model as a software solution that conforms to integration conventions. Experiences from case studies are presented which apply TIL to support the creation of tool chains. The approach is evaluated, both qualitatively and quantitatively, by comparing it to traditional development methods for tool chains. The approach enables the efficient development of tailored tool chains, which have the potential to improve the productivity of embedded systems development. Keywords: Tool Chain, Tool Integration, Domain-Specific Modeling Language, Generative Approach, Lifecycle Support for Embedded System Development
Acknowledgements This thesis would not have been possible without the support of many people. I would like to thank especially: • Martin T¨ orngren for the opportunity to work towards the doctorate thesis and for providing advise, feedback, encouragement and enthusiasm throughout the work! • Jad El-khoury for the advise, detailed feedback, our regular planning meetings at KTH and various coffee places in town and for not forgetting what it is like to be a student! • Fr´ed´eric Loiret, Fredrik Asplund, Carl-Johan Sj¨ostedt, Jiarui Hong and Weiquing Gu for the fruitful discussion and contributions to the appended co-authored papers. • De-Jiu Chen, Tahir Naseer Qureshi, Magnus Persson, Lei Feng and Sagar Behere for the great working atmosphere and discussions. • Vicki Derbyshire for the feedback on the writing style. • All colleagues in the department of machine design and in the research projects ATESST2, CESAR, iFEST and MAENAD. • ARTEMIS JU, EU Commission and the Wallenberg Stiftelse for funding parts of this work. • My friends and family, especially Diana, Gertrud, G¨ unter, Vera and Lena for their moral support during the intense periods of the work.
Matthias Biehl Stockholm, January 2013
v
Contents
Acknowledgements
v
Contents
vii
List of Appended Papers
xi
List of Additional Related Papers by the Author
xv
I Getting Started
1
1 Introduction 1.1 Embedded Systems Development 1.2 Problem Formulation . . . . . . . 1.3 High-Level Goals . . . . . . . . . 1.4 Delimitations and Alternatives . 1.5 Outline . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
3 3 5 9 9 10
2 Research Questions and Methods 13 2.1 Methodological Frameworks . . . . . . . . . . . . . . . . . . . . . . . 13 2.2 Research Questions and Methods . . . . . . . . . . . . . . . . . . . . 14 3 Criteria for the Description and Development 3.1 Criteria for the Description of Tool Chains . . . 3.2 Criteria for the Development of Tool Chains . . 3.3 Summary . . . . . . . . . . . . . . . . . . . . .
of Tool . . . . . . . . . . . . . . .
Chains 19 . . . . . . . 20 . . . . . . . 23 . . . . . . . 26
4 State of the Art 27 4.1 Basic Concepts and Terminology . . . . . . . . . . . . . . . . . . . . 27 4.2 Tool Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3 Characterization of Tool Integration Approaches . . . . . . . . . . . 35 vii
viii
CONTENTS
II Overview of Results and Evaluation
41
5 A Modeling Language for Tool Chains 5.1 Objectives for the Tool Integration Language . . . . 5.2 Domain Analysis for Tool Chains . . . . . . . . . . . 5.3 The Tool Integration Language . . . . . . . . . . . . 5.4 Proposed Tool Chain Development Process with TIL
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
43 43 44 46 50
6 Support for the Development of Tool Chains 6.1 A Development Environment for TIL . . . . . 6.2 Construction of a Conceptual TIL Model . . 6.3 Refinement of ToolAdapters in a TIL Model . 6.4 Refinement of DataChannels in a TIL Model 6.5 Analysis of TIL Models . . . . . . . . . . . . 6.6 Code Generation from TIL Models . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
55 57 57 58 59 60 62
. . . . . .
. . . . . .
. . . . . .
. . . . . .
7 Evaluation of TIL 65 7.1 TIL for the Description of Tool Chains . . . . . . . . . . . . . . . . . 65 7.2 TIL for the Development of Tool Chains . . . . . . . . . . . . . . . . 69
III Reflection 8 Discussion 8.1 Primary and Derivative Integration Challenge . . . . 8.2 From Model-Based to Model-Driven Tool Integration 8.3 Roles of Tools in the Tool Chain . . . . . . . . . . . 8.4 Potential Implications for Industrial Practice . . . .
75 . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
77 77 80 83 83
9 Conclusion 85 9.1 Review of Research Questions . . . . . . . . . . . . . . . . . . . . . . 85 9.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Bibliography
IVAppended Papers
93
107
A A Modular Tool Integration Approach - Experiences from two Case Studies
109
B A Domain Specific Language for Generating Tool Integration Solutions
123
C On the Modeling and Generation of Service-Oriented Tool Chains137
CONTENTS
ix
D High-Level Specification and Code Generation for Service-Oriented Tool Adapters 159 E Constructing Tool Chains based on SPEM Process Models
169
F Model-based Service Discovery and Orchestration for OSLC Services in Tool Chains 179 G Automated Construction of Data Integration Solutions for Tool Chains
191
H Early Automated Verification of Tool Chain Design
203
I
217
A Cost-Efficiency Model for Tool Chains
List of Appended Papers This thesis is based on the following 9 papers, which are appended to this thesis. Paper A 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 (MDTPI2010) at the European Conference on Modelling Foundations and Applications (ECMFA 2010), Jun. 2010. Martin provided feedback; Carl-Johan performed the case study on integrating Simulink and wrote section 4.2; Matthias performed the case study on integrating the safety analysis tool HiP-HOPS and wrote the rest of the paper.
Paper B Matthias Biehl, Jad El-Khoury, Frederic Loiret, and Martin T¨orngren, “A Domain Specific Language for Generating Tool Integration Solutions,” in 4th Workshop on Model-Driven Tool & Process Integration (MDTPI2011) at the European Conference on Modelling Foundations and Applications (ECMFA 2011), Jun. 2011. Jad, Frederic and Martin provided feedback; Matthias proposed the ideas, performed the work and wrote the paper.
Paper C Matthias Biehl, Jad El-Khoury, Frederic Loiret, and Martin T¨orngren, “On the Modeling and Generation of Service-Oriented Tool Chains,” in Journal of Software and Systems Modeling, Vol. 275, Online First Sept. 2012. Jad, Frederic and Martin provided feedback; Matthias proposed the ideas, performed the work and wrote the paper. xi
xii
LIST OF APPENDED PAPERS
Paper D Matthias Biehl, Jad El-Khoury, and Martin T¨orngren, “High-Level Specification and Code Generation for Service-Oriented Tool Adapters,” in Proceedings of the International Conference on Computational Science and Its Applications (ICCSA2012), Jun. 2012. Martin provided feedback; Jad and Matthias developed the initial concepts; Matthias implemented the generator, the case study and wrote the paper.
Paper E Matthias Biehl, and Martin T¨ orngren, “Constructing Tool Chains based on SPEM Process Models,” in Seventh International Conference on Software Engineering Advances (ICSEA2012), Nov. 2012. Martin provided feedback; Matthias proposed the ideas, performed the work and wrote the paper.
Paper F Matthias Biehl, Wenqing Gu, and Frederic Loiret, “Model-based Service Discovery and Orchestration for OSLC Services in Tool Chains,” in International Conference on Web Engineering (ICWE2012), Jul. 2012. Wenqing implemented the discovery algorithm, performed the case study and wrote section 4, Frederic contributed with knowledge on SCA and contributed to section 6, Matthias proposed the idea of OSLC-based discovery, the conceptual design of orchestration and discovery, initiated and led the work, and wrote the rest of the paper.
Paper G Matthias Biehl, Jiarui Hong, Frederic Loiret, “Automated Construction of Data Integration Solutions for Tool Chains,” in Seventh International Conference on Software Engineering Advances (ICSEA2012), Nov. 2012. Jiarui implemented the similarity flooding and matching algorithms. Frederic provided feedback. Matthias proposed the ideas, wrote the paper and implemented
xiii the higher-order model transformation and the TIL code generators.
Paper H Matthias Biehl, “Early Automated Verification of Tool Chain Design,” in Proceedings of the International Conference on Computational Science and Its Applications (ICCSA2012), Jun. 2012. Matthias proposed the ideas, performed the work and wrote the paper.
Paper I Matthias Biehl, Martin T¨ orngren, “A Cost-Efficiency Model for Tool Chains,” in Proceedings of the Workshops at the International Conference on Global Software Engineering (ICGSE2012), Aug. 2012. Martin provided feedback; Matthias proposed the ideas, performed the work and wrote the paper.
List of Additional Related Papers by the Author The following papers are related to this thesis, but are not included. • Matthias Biehl, “Semantic Anchoring of TIL,” Royal Institute of Technology, Tech. Rep. ISRN/KTH/MMK/R-12/14-SE, Oct. 2012. [Online]. Available: http://www1.md.kth.se/~biehl/files/papers/semantics.pdf • Fredrik Asplund, Matthias Biehl, Frederic Loiret “Towards the Automated Qualification of Tool Chain Design,” in Safecomp 2012 Workshops, Sep. 2012. • Matthias Biehl, Martin T¨ orngren, “An Estimation Model for the Savings Achievable by Tool Chains,” in Proceedings of IEEE 36th International Conference on Computer Software and Applications Workshops, Jul. 2012. • Weiqing Zhang, Birger Møller-Pedersen, Matthias Biehl, “A light-weight tool integration approach – from a tool Integration Model to OSLC Integration Services,” in International Conference on Software Paradigm Trends (ICSOFT 2012), Jul. 2012. • Eric Armengaud, Matthias Biehl, Quentin Bourrouilh, Michael Breunig, Stefan Farfeleder, Christian Hein, Markus Oertel, Alfred Wallner, Markus Zoier, “Integrated tool chain for improving traceability during the development of automotive systems,” in Embedded Real Time Software and Systems (ERTS2 2012), Feb. 2012. • Fredrik Asplund, Matthias Biehl, Jad El-Khoury, Daniel Frede, Martin T¨orngren, “The Impact of Tool Chain Qualification on ISO 26262,” in SAE 2012 World Congress & Exhibition, Apr. 2012. [Online]. Available: http:// papers.sae.org/2012-01-0026 • Matthias Biehl, “Analysis of Tool Chains,” Royal Institute of Technology (KTH), Tech. Rep. ISRN/KTH/MMK/R-11/17-SE, Nov. 2011. [Online]. Available: http://www1.md.kth.se/~biehl/files/papers/analysis.pdf xv
xvi
LIST OF ADDITIONAL RELATED PAPERS BY THE AUTHOR • Matthias Biehl, “Tool Integration Language (TIL),” Royal Institute of Technology (KTH), Tech. Rep. ISRN/KTH/MMK/R-11/16-SE, Sep. 2011. [Online]. Available: http://www1.md.kth.se/~biehl/files/papers/til.pdf • Fredrik Asplund, Matthias Biehl, Jad El-Khoury, Martin T¨orngren, “Tool integration beyond Wasserman,” in First Workshop on Integration of Information Systems Engineering Tools (INISET 2011), Jun. 2011. • Eric Armengaud, Markus Zoier, Andreas Baumgart, Matthias Biehl, DeJiu Chen, Gerhard Griessnig, Christian Hein, Tom Ritter, Ramin T. Kolagari, “Model-based Toolchain for the Efficient Development of Safety-Relevant Automotive Embedded Systems,” in SAE 2011 World Congress & Exhibition, Apr. 2011. [Online]. Available: http://papers.sae.org/2011-01-0056 • Matthias Biehl, Supporting Model Evolution in Model-Driven Development of Automotive Embedded Systems, ser. Trita ISRN/KTH/MMK/R-10/08-SE. Licentiate Thesis, Royal Institute of Technology, Nov. 2010. [Online]. Available: http://www.md.kth.se/~biehl/files/papers/licavhandling.pdf • Matthias Biehl, “Documenting Stepwise Model Refinement using Executable Design Decisions,” in International Workshop on Models and Evolution (ME2010), Oct. 2010. • Matthias Biehl and Martin T¨ orngren, “An Executable Design Decision Representation using Model Transformations,” in 36th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA2010), Sep. 2010. • Matthias Biehl, “Literature Study on Model Transformations,” Technical Report, Royal Institute of Technology, ISSN 1400-1179, ISRN/KTH/MMK/R10/07-SE, Stockholm, Sweden, Jul. 2010. • Matthias Biehl, Chen De-Jiu, Martin T¨orngren, “Integrating Safety Analysis into the Model-based Development Toolchain of Automotive Embedded Systems,” in Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES2010), Apr. 2010, pp. 125+. • Matthias Biehl, Welf L¨ owe, “Automated Architecture Consistency Checking for Model Driven Software Development,” in Proceedings of the Fifth International Conference on the Quality of Software Architectures (QoSA2009), Jun. 2009, pp. 36-51. [Online]. Available: http://dx.doi.org/10.1007/ 978-3-642-02351-4_3. • ATESST2 Project Deliverables D2.1, D3.1, D3.2, D3.5, D4.3.1 [Online]. Available: http://www.atesst.org. • MAENAD Project Deliverable D5.2.1 [Online]. Available: http://www.maenad.eu.
xvii • CESAR Project Deliverable D SP5 R3.2 [Online]. Available: http://www.cesarproject.eu. • iFEST Project Deliverables D2.1, D2.2, D2.3, D7.2 [Online]. Available: http://www.artemis-ifest.eu.
Part I
Getting Started
1
Chapter 1
Introduction This work proposes and evaluates a modeling language for the systematic description and development of tool chains, which are used in the context of embedded systems development. Embedded systems development is typically supported by a large number and wide variety of heterogeneous tools. The tools are isolated and it is thus difficult to create a seamless engineering environment using the tools. A tool chain, is such an engineering environment that is realized as a software system. In current practices, the development of tool chains is ad-hoc, lacking an engineering approach with an appropriate description of the tool chain and support for carrying out a systematic development process. In this chapter, the development of embedded systems is briefly introduced (Section 1.1), since it provides the context for tool integration. The challenges of tool integration, the challenges of tool chain development and the involved stakeholders are identified (Section 1.2). For addressing these challenges, a number of high-level goals for the development of tool chains are set (Section 1.3). Some delimitations are made (Section 1.4) and the outline of this work is described (Section 1.5).
1.1
Embedded Systems Development
In this section, the development of embedded systems is briefly introduced, since it provides the context for the challenges addressed in this thesis. Of particular interest in this introduction are the tools used for embedded systems development. Many innovative functions in traditionally mechanical systems, such as advanced driver assistance systems in cars or autopilots in airplanes, are realized as embedded computer systems. The IEEE Glossary defines an embedded computer system as a “computer system that is part of a larger system and performs some of the requirements of that system” [91]. In the following, the shortened term embedded system is used to refer to an embedded computer system. An embedded system is characterized by heterogeneity, since it consists of tightly connected hardware and software. In addition, the embedded system is integrated into a larger system, e.g. 3
4
CHAPTER 1. INTRODUCTION
a traditionally mechanical system such as a car or airplane. To capture the heterogeneous nature and the various properties of the system, it is typically described using multiple views. A view is a work product that expresses a system from a certain perspective [93]. The views are expressed using various languages and are supported by various tools for design, analysis and simulation. The development of embedded systems involves engineers from different disciplines, e.g. control engineers, mechanical engineers, electrical engineers and software engineers [48]. Each discipline views the product from a different perspective [56], resulting in a number of discipline-specific views, which are supported by discipline-specific development tools. Industrial development processes for embedded systems typically follow the VModel described in VDI 2206 [160]. According to VDI 2206, hardware and software are developed separately with certain synchronization points, after the overall requirements have been initially established. While hardware development typically follows a waterfall approach, software development may apply agile or iterative approaches. In addition, approaches for complexity management [155] are increasingly used, such as model-based/model-driven development [131] and component-based development [62].
1.1.1
Tools for Embedded Systems Development
The activities in embedded systems development are increasingly supported by development tools, and many alternative tools are emerging, leading in turn to a broad and heterogeneous landscape of development tools. The different phases of the development process are supported by specific development tools to design, simulate, implement, analyze, verify and test the system. For example, DOORS1 is used for managing requirements, EnterpriseArchitect2 for UML design, the WindRiver Workbench3 as an editor and compiler for implementation and FaultTree+4 for safety and reliability analysis. Discipline-specific development tools are also used – control engineers might use MATLAB/Simulink5 , mechanical engineers might use Solidworks6 for computeraided-design (CAD), electrical engineers use Xilinx7 for logic design and software engineers use a C compiler8 for software development. Besides dedicated development tools, even word processing applications and spreadsheet applications are used as development tools. In addition, there are tools for project management, collaboration, configuration management and product lifecycle management. 1 http://www.ibm.com/software/awdtools/doors 2 http://www.sparxsystems.com/products/ea 3 http://www.windriver.com/products/workbench 4 http://www.isograph-software.com/ftpover.htm 5 http://www.mathworks.com/products/simulink 6 http://www.solidworks.com 7 http://www.xilinx.com/ise 8 such
as http://gcc.gnu.org
1.2. PROBLEM FORMULATION
5
The tools for embedded systems development are typically commercial off the shelf tools (COTS), but open source tools and in-house developed tools are used as well. A brief overview of commonly used development tools for embedded systems development can be found in [69]. In addition to the diversity, a large number of development tools are used in the embedded systems industry – the Automotive Technology Business Sector of Robert Bosch GmbH reports a portfolio of approximately 1,500 different tools [84].
1.2
Problem Formulation
In this section, the basic problem of tool integration is described (Section 1.2.1), typical stakeholders of tools and tool chains are analyzed (Section 1.2.2), and the challenges of the development of tool chains are identified (Section 1.2.3).
1.2.1
Basic Problem of Tool Integration
The tool landscape for embedded systems is both large and diverse, consisting of a number of specialized tools that support specific aspects of embedded systems development. Each tool focuses on supporting particular development tasks or aspects of the development process. Development tasks are not performed in isolation, but as parts of a development process. For a comprehensive tool support throughout the embedded systems development process, an engineering environment that supports the system development process by allowing for the seamless use of several development tools is required. Such an engineering environment needs to support sharing and reusing artifacts created with different tools, creating traces between these artifacts, invoking services of several tools and notifying developers. The data and services of the tools are not readily accessible due to the technical differences among the tools and are difficult to use due to the syntactic and semantic differences. While the technical and syntactic differences among the tools can be regarded as contributors to the accidental complexity of tool integration, the semantic differences contribute to the essential complexity (see [50] for a discussion of essential and accidental complexity). No ready-made solutions for such engineering environments are available due to the diversity and size of the landscape for development tools. Tool integration is the activity of producing an engineering environment of tools that supports the systems development process [163]. Characteristically for this situation, the tools are available first, are built without considering integration, and their integration is performed afterwards. This situation is also described as a-posteriori integration [51], in contrast to a hypothetical a-priori integration, where tools are built so they fulfill specific integration requirements. Some tools may provide limited capabilities for a-priori integration with a limited set of tools, but in general, the need for a-posteriori integration can be assumed, since mostly commercial off the shelf (COTS) development tools are used [53].
6
CHAPTER 1. INTRODUCTION
In its simplest form, the engineering environment may be realized as a selection of tools and a set of guidelines that users of the tools, i.e. the embedded systems developers, need to follow to realize the integration. In this case, integration is performed by human operators, most likely the embedded systems developers themselves. This situation results in inefficiencies and high costs of development [164]. More effective engineering environments, called tool chains, are realized as a software solution. Tool chains are effective, since integration-related activities are automated. This allows embedded systems developers to focus on the creation of the product instead of manually performing the integration. Tool chains are not necessarily connected in a linear way, but can form networks of tools. Tool chains can enable higher reuse of development artifacts across tools and they enable the automation of development activities. The assumption of the research community is that the main benefits of using tool chains are increased productivity [164], cost savings, reduced human error and reduced time to market [168].
1.2.2
Stakeholders
Here, some of the most important stakeholders of tools and tool chains are introduced, including their roles as users or creators of tools and tool chains. The embedded systems developers work with multiple development tools and take on the role of the users of tools. In addition, the embedded systems developers take on the role of the users of tool chains, motivated by the expected efficiency gains in development provided by tool chains. The vendors of tools for embedded systems development take on the role of the creators of tools. Based on observations and interactions with industry in the research projects iFEST [2] and CESAR [1], the assignment of the role of the creator of tool chains is not clearly defined in industry. The role might be assigned to third party integration developers, but also to embedded systems developers or to tool vendors, which is problematic. Tool vendors are mostly interested in connecting only their tools to other tools, resulting in a limited scope of the integration, so called “islands of integration”. For embedded systems developers, the implementation of a tool chain is an additional burden that distracts them from their primary task of developing an embedded system.
1.2.3
Challenges of Tool Chain Development
A tool chain, is a software solution to the tool integration problem. The development of tool chains deals with a number of challenges. Tailoring In general, a tool chain supports a development process by automating the integrationrelated tasks of that process. Traditional tool chains support simple connections
1.2. PROBLEM FORMULATION
7
between a small number of tools, such as the connections between editor, compiler and linker. Tool chains with a simple architecture can thus be realized by a pipe and filter architecture [148]. Modern tool chains need to support development processes that are model-based and iterative [157] and include a larger number of tools used in different phases of the system lifecycle. To get a tool chain accepted it is important that the users are involved [59] and the tool chain is customized to their individual requirements. Each development project for an embedded system may use a specific selection of development tools, and a specific development process. Due to the large number of development tools (see Section 1.1.1) and even larger number of possible tool combinations, one-sizefits-all tool chains cannot provide adequate support. Instead, tool chains need to be tailored to the product development process, development team and development tools of each development project. As a consequence, a number of different, tailored tool chains need to be developed. Methodology An established methodology for the development of tool chains is not available. Tool chains are often implemented ad-hoc, leading to “fragile integrations” [67] that are difficult to extend and maintain. There is insufficient support for synthesis and early analysis of tool chains – current platforms for tool integration provide partial solutions, but also introduce accidental complexity through the amount of coding, low-level technologies and configurations. Tool chains are manually implemented and can only be tested after the time and effort for implementation has been spent. Efficient Development Despite recent innovations in the field of tool integration, for example by tool integration frameworks, such as Jazz [78] or ModelBus [85], the development of tool chains still requires a large, manual implementation effort. In addition, tool integration frameworks require a number of configuration files with complex dependencies between them. Techniques are needed to improve the efficiency of building tool chains. Description at an Appropriate Level of Abstraction When working with industrial partners on tool integration, a gap between existing general purpose modeling languages and concepts from the domain of tool integration quickly became apparent. Integration approaches typically focus on describing the data of tools in the form of models and corresponding metamodels; the tool chain, however, is not explicitly modeled using concepts from the domain of tool integration. Instead, tool chains are built in a bottom-up manner and are often described on implementation level, using source code and the concepts offered by integration frameworks [78, 85]. These concepts are very detailed and depend on the use of certain technology.
8
CHAPTER 1. INTRODUCTION
Alternatively, tool chains are described by existing languages, such as general purpose modeling languages and languages for other domains. Borrowing descriptions and languages originally defined for other domains is a “workaround”, which introduces accidental complexity [14], an example is the use of business process models for describing tool chains [85]. Managing Tool Integration Views and Technologies Several specialized technologies for realizing parts of tool chains are currently available, such as model transformation tools, tracing tools or libraries for exposing services of tools. Each of these integration technologies describes one aspect of the tool chain – a complete tool chain needs to cover several aspects. The functionality of a tool chain is thus fragmented across several integration technologies realizing parts of the tool chain. Each integration technology provides different, partial views of the tool chain, which are described using specific languages or configurations. To obtain an overview of the actually deployed or required functionality of the complete tool chain, several partial descriptions have to be consulted. The relationship between these descriptions is neither explicitly described nor managed, so inconsistencies can occur. This situation contributes to the accidental complexity of tool chain development. Integration Conventions Ad-hoc realizations of tool chains may use a variety of data formats, communication protocols and assumptions, which leads to incompatible tool chain realizations. Integration conventions provide a common ground for building tool chains and increase the likelihood that parts of tool chains can be reused in a different context than they were originally designed for, even when they are provided by a third party. Several conventions for integration exist, such as XMI (XML Metadata Interchange) [133], OSLC (Open Services for Lifecycle Collaboration) [141] and STEP [92]. Tool chains should be built according to conventions that are in use and accepted by industry. However, creating tool chains that follow integration conventions, involves a development overhead. Cost-efficient Tool Chains Industrially applied tool chains exist in a business context and need to be economically motivated, a view which has not received much attention in the academic literature on tool chains [164]. Tool chains are introduced by industry if they have a positive net value, i.e. if their benefits outweigh the necessary investment. The potential benefits of tool chains are increased productivity [164], cost savings, reduced human error and reduced time to market [168]. The necessary investment includes, for example, the cost for the construction of tool chains, the cost for introduction of the tool chain and training costs. One approach to increase the net value of tool chains is to develop them as cost-efficiently as possible.
1.3. HIGH-LEVEL GOALS
1.3
9
High-Level Goals
The main goal of this work is to provide a language, methods and tools to describe and develop tool chains. It requires overcoming the challenges identified in Section 1.2.3. The main goal can be broken down into the following sub-goals: 1. Support for describing tool chains in a systematic and structured way: The building blocks of tool chains and their composition need to be identified and described at an appropriate level of abstraction. Such a description can help to manage different tool integration views and technologies. 2. Support for developing tool chains efficiently: Tool chains need to be efficiently realized as software solutions that are compliant with integration conventions. To guide the work towards realizing these goals, a number of research questions are put forward (Section 2). For each of these goals, also a number of concrete criteria are identified (Section 3) using the Goal Question Metric (GQM) [18] approach. These criteria will be used for evaluating at the end of the work, whether the proposed results fulfill the stated goals.
1.4
Delimitations and Alternatives
A number of explicit delimitations are made for this work. • An investigation of the implications of product lifecycle management and software configuration management in the context of tool chains is part of future work. • The integration demands for co-simulation with multiple solvers are not addressed in this work. A description of the challenges and a possible solution for the co-simulation problem with multiple solvers is provided by the MODELISAR9 project. • The research results are internally validated based on case studies provided by industrial partners in the research projects iFEST [2] and CESAR [1]. Large-scale, external validation by industry is part of future work. • Tooling for embedded systems development could be approached at a deeper level by building new tools [67] that provide an a-priori integration and thus render the a-posteriori tool integration problem irrelevant [51]. The challenges for constructing tool chains are reduced (Section 1.2.3), but the basic challenges of multi-view modeling remain (Section 1.2.1). In contrast, a pragmatic perspective of embedded systems development is taken, focusing on existing COTS development tools and the improvements that can be made by their integration. 9 http://www.functional-mockup-interface.org
10
1.5
CHAPTER 1. INTRODUCTION
Outline
This work is organized in four parts. Part I describes the context of this work. In Chapter 2, the research questions and the methods applied in this work are presented, structured according to two methodological research frameworks. In Chapter 3, a number of criteria are identified for characterizing the description of tool chains and their development. In Chapter 4, a brief overview of the state of the art in tool integration is provided, including a characterization of selected approaches with the previously identified criteria. Part II presents an overview of the results and their evaluation. In Chapter 5, the design of the Tool Integration Language (TIL) is described. In Chapter 6, semiautomated techniques for different tasks of the tool chain development process are presented. In Chapter 7, the results are evaluated using the previously identified criteria. In Part III, the results are discussed and conclusions are drawn. New perspectives provided by the work are discussed in Chapter 8. In Chapter 9, the main results are related to the research questions and an outlook for future research in the field is presented. In the final Part IV, papers containing detailed descriptions of the results and evaluations are appended. Initial ideas for the language are described in Appended Papers A and B, and the language is described and evaluated in Appended Paper C, as visualized in Figure 1.1. The support for tool chain development is described in Appended Papers C - I, as visualized in Figure 1.2. Appended Paper E describes the support for specifying a tool chain that is aligned to a development process, Appended Papers F and G describe support for refining a tool chain model, Appended Papers H and I describe methods for analysis of a tool chain model and Appended Papers C and D describe code generation from a tool chain model.
1.5. OUTLINE
11
Figure 1.1: Overview of Appended Papers A - C, which present the systematic description of tool chains with a language. The picture also documents the evolution of the language.
12
CHAPTER 1. INTRODUCTION
Figure 1.2: Overview of Appended Papers C - I, which present development support for tool chains. The picture shows the tool chain development process described in SPEM [135] notation and highlights the provided development support.
Chapter 2
Research Questions and Methods In this chapter, the research questions that guided this work are introduced, their selection is motivated, and the methods applied to answer them are presented. Two methodological frameworks are introduced (Section 2.1) and applied to present the research questions and methods (Section 2.2).
2.1
Methodological Frameworks
Methodological frameworks provide a means for structuring and analyzing a chosen research approach. In this work, research on engineering design and software engineering is performed, thus both Blessing’s framework [45] for engineering design research (Section 2.1.1) and Shaw’s framework [147] for software engineering research (Section 2.1.2) are introduced.
2.1.1
Methodological Framework for Engineering Design Research
Engineering design research has two objectives, the development of design theories and the development of tool support [45]. Blessing proposes the Design Research Methodology (DRM) as a framework, which provides methods and guidelines for performing design research in the following stages: • Research Clarification: to identify the topics of relevance and contribution, clarify the current understanding, clarify the research questions and create a research plan. • Descriptive Study 1: to gain an in-depth understanding of the existing situation, e.g. by a literature survey. • Prescriptive Study: to create support for improving the existing situation. 13
14
CHAPTER 2. RESEARCH QUESTIONS AND METHODS • Descriptive Study 2: to evaluate the support developed in the prescriptive study.
2.1.2
Methodological Framework for Software Engineering Research
In general, software engineering seeks better ways to develop and evaluate software, motivated by practical problems, key objectives typically being quality, cost and timeliness. Shaw [147] proposes a methodological framework for research in software engineering. The framework provides a classification scheme for characterizing a research approach in terms of research questions, results and validation. • Research Question: To establish what is interesting, research questions are put forward. Typical research questions in software engineering can be classified as methods of development, methods for analysis, design and evaluation of a particular software, generalization or characterization schemes and feasibility studies. • Research Results: The answers to research questions are research results. Typical research results in software engineering can be classified as procedures or techniques (new or better ways to solve a problem), qualitative or descriptive models (taxonomy for a problem area, checklist), empirical models, analytic models (structural models for formal analysis and automatic manipulation), notations or tools (language and tool support for this language), specific solutions, judgments and reports. • Research Validation: Validation can be accomplished through experience with the newly developed program or through systematic analysis [147]. The list of validation techniques used in software engineering includes analysis, experience, toy example, slice of life and evaluation.
2.2
Research Questions and Methods
The research questions of this work are motivated by several initial case studies [7, 8, 32] of tool chain development for embedded systems. The initial case studies used state-of-the-art tool integration technologies, such as model transformations and tool integration frameworks. This exposed the challenges of developing tool chains (see Section 1.2.3) and lead to the main research question addressed in this work: • RQ1: How can the development of tool chains be systematized and automated? To be able to phrase the main research question more sharply, the hypothesis of domain-specific languages is applied as an auxiliary hypothesis, which can be phrased as AUX-HYP: A domain-specific language offers appropriate constructs
2.2. RESEARCH QUESTIONS AND METHODS
15
and notations from the domain and is the basis for automated development support [123]. With the auxiliary hypothesis, the hypothesis of this work on tool chain development can be phrased as • HYP: The development of tool chains can be supported by a systematic description of tool chains and by automated development methods based on the description. With this hypothesis, RQ1 can be refined into RQ2 and RQ3. • RQ2: How can tool chains be described systematically? The results for RQ2 are presented in Chapter 5. Based on an initial case study [32], a modular approach for data-integration in tool chains is proposed (Appended Paper A), identifying two separate stages of data-transfer. Based on an additional case study with a tool integration framework [7, 8], the modularization is extended (Appended Paper B). A domain analysis [71] of tool chains is performed to identify common building blocks, which are organized into a modeling language. This modeling language can be applied to express a tool chain from an industrial research project (Appended Paper C). After evaluating the descriptive use of the modeling language, we explore its constructive use for supporting various development tasks. • RQ3: To what extent can the development of tool chains be supported by automated methods? Since the development of tool chains covers several development phases, we refine RQ3 into more refined research questions addressing automated methods for specific phases in the tool chain development process, such as specification, refinement, analysis and synthesis. The refined research questions and the results for RQ3 are presented in Chapter 6. Support for the specification of tool chains is proposed (Appended Paper E) and support for the refinement of tool chains (Appended Papers F and G). In addition, support for the analysis of tool chains is proposed (Appended Papers H and I) and the synthesis of tool chains (Appended Papers C and D).
2.2.1
Application of the Methodological Frameworks
Applying the methodological framework for engineering design research (see Section 2.1.1) shows that the research was performed in three cycles, as depicted in Figure 2.1. Each cycle started with a research clarification and descriptive work to enhance the understanding of the state of the art through literature studies and case studies, followed by prescriptive work for describing new methods and tools and another round of descriptive work to evaluate the feasibility and usefulness of the proposed methods using case studies to extract the lessons learned. The case studies are used to evaluate proposed approaches, but also to gain insights into the problem, which are used as a starting point for the next cycle of research. Each
16
CHAPTER 2. RESEARCH QUESTIONS AND METHODS
Figure 2.1: Three cycles of the design research methodology
cycle builds on the results and insights from the previous cycle. The first cycle in Figure 2.1 represents the development of a specific instance of a tool chain and is described in the Licentiate Thesis [27]. The second cycle describes a generalization of previous results, by proposing a language that can be used to describe tool chains. The results are described in Chapter 5. The third cycle explores possibilities for automating parts of the tool chain development process based on the developed language. The results are described in Chapter 6. Applying the methodological framework for software engineering research (see Section 2.1.2) yields the classification presented in Table 2.1. For each tackled research question, the type of research question, the type of research result and the type of research validation are identified. The research questions address methods of development and characterization schemes. The results are descriptive models, methods and tools. The results are validated both qualitatively and quantitatively by case studies that were provided by industrial partners in the iFEST [2] and the CESAR [1] project in the form of textual descriptions. Due to their practical relevance, they can be classified as a slice of life according to Shaw’s terminology [147]. Our choice of case studies as validation method is in line with the statistics on research in software engineering presented by Shaw [147], where validation is typically performed by examples, when the research questions are classified as development methods, and research results are classified as notation and tool. Table 2.1: Classification of research questions, results and validation RQ RQ1 RQ2 RQ3
Type of Research Question Method of Development Characterization Scheme Method of Development
Type of Result Method and Tool Descriptive Model Method and Tool
Type of Validation Slice of Life Slice of Life Slice of Life
2.2. RESEARCH QUESTIONS AND METHODS
2.2.2
17
Case Studies
The following case studies are used for the validation of different parts of the approach: 1. As part of the CESAR project [1], a tool chain of MATLAB/Simulink, PapyrusUML and the HiP-HOPS tool has been created with representatives from the automotive industry. For this case study a previous implementation was carried out using state-of-the-art integration technology [7, 8]. Executing the case study with TIL, provides opportunities for comparison. This case study is used for evaluating several methods supporting the development of tool chains, including code generation. 2. As part of the iFEST project [2], a case study is provided by our industrial partner, who develops embedded systems characterized by tightly coupled hardware and software components: The application logic is partitioned into software running on a Freescale PowerPC and hardware logic realized by a Xilinx FPGA. The scenario requires a number of tools for modeling, simulation, analysis, code-generation and coding. Today, no tool chain is in place to support the development process. The vision of an industrial tool chain for hardware-software co-design is described textually and in the form of sketches. This case study is used for evaluating several methods supporting the development of tool chains. 3. SPEM process models from the AUTOSAR (Automotive Open Software Architecture) [15] specification defined by the automotive industry are used as a case study for the construction of a tool chain that is aligned to a process model. This case study is selected, because of the industrial relevance of AUTOSAR specification and the public accessibility of the process models in the specification. Case studies are applied in a specific context, and thus the possibility to generalize the obtained results requires particular discussion. Case studies have limitations regarding their generalizability, which can be controlled to the effect that the ”generalizability of case studies can be increased by the strategic selection of cases” [76]. The literature [145, 146] differentiates between representative and extreme case studies. To cover a wide range of cases and to increase the generalizability, both representative and extreme cases need to be chosen for the evaluation. Case study 2 reflects the tool chain of an industrial partner in the iFEST project. It is representative for the tool chains of other industrial partners studied in the iFEST project regarding the following parameters: • Number of tools: The tool chains in the iFEST project contain less than ten tools. • Types of tools: A mix of mostly COTS tools and in-house developed tools are used. COTS tools typically include MATLAB/Simulink and UML tools.
18
CHAPTER 2. RESEARCH QUESTIONS AND METHODS • Size of the exposed data and services of the tools: The size of roughly 10 entities with each up to 10 attributes. The templates for the exposed data and services proposed by the integration convention OSLC (Open Services for Lifecycle Collaboration) [141] have a similar or smaller size. • Different aspects of integration: The integration aspects data-transfer, datatracing, control-invocation, control-notification and process integration are considered. • Types of users in the tool chain: Four user roles are defined, representing different engineering disciplines: a systems engineer, control engineer, software engineer and hardware engineer. The disciplines are typical for embedded systems engineering (see Section 1.1).
Apart from representative cases, also extreme cases are studied, since the latter can reveal more information and increase the generalizability of the case study [76]. The case studies presented in Appended Paper D focus on extreme values of a critical part of the tool chain, namely the size of the exposed data and services of the tools. The behavior of the generator is explored for a metamodel (the complete metamodel of UML1 ) that has over 20 times the typical size.
1 http://www.eclipse.org/uml2
Chapter 3
Criteria for the Description and Development of Tool Chains The research questions introduced in the previous section provide the general direction towards the high-level goals stated in Section 1.3. To make these goals more concrete and measurable, a number of criteria for characterizing the description and development of tool chains are identified in this section. For selecting the criteria in a structured way, the Goal Question Metric (GQM) approach [18] is applied: starting from high level goals, a number of questions are defined that make these goals operational, and a number of metrics for each question that make the answers measurable. For simplicity, the questions and associated metrics are called criteria in the following. These criteria are used in later sections for characterizing related work and for evaluating the research results. In this work, the two main high-level goals address the description and development of tool chains. The first goal is to provide an appropriate description of a tool chain; this goal is related to RQ2. In Section 3.1, a number of questions are elicited to cover several viewpoints for the description of tool chains, including appropriate metrics for measurement of the respective questions. The second goal is to provide development support for tool chains; this goal is related to RQ3. In Section 3.2, a number of questions are elicited to capture the extent of the provided support for the specification, analysis and synthesis of tool chains. The metrics measure if appropriate support is provided and the degree to which the support is automated. The criteria presented in this section originate from various sources: the analysis of the literature, earlier case studies and interactions with industrial stakeholders. The lessons learned have been gathered from earlier case studies with manually programmed tool chains built with model transformations [32, 39] and with a state of the art tool integration framework [7, 8]. In addition, the research project iFEST [2] provided a forum to work with different types of stakeholders in tool chains: potential industrial users of tool chains, vendors of development tools and vendors 19
CHAPTER 3. CRITERIA FOR THE DESCRIPTION AND DEVELOPMENT 20 OF TOOL CHAINS of integration platforms.
3.1
Criteria for the Description of Tool Chains
Tool chains can be described from various viewpoints, leading to views addressing different concerns and aspects of tool chains. In addition, an overview of the tool chain can be described. The description can be domain-specific to tool integration and have a graphical representation to support communication among stakeholders. Each of these criteria will be further detailed below.
3.1.1
Coverage of Integration Concerns
The description of a tool chain may address different integration concerns, which can be classified as follows: • The technical concern describes the technical means to access the data and services of a tool. Examples for describing technical concerns are source code, data files, communication protocols or APIs (Application Programming Interfaces) of the tools in a tool chain. • The structural concern describes the structure of the data and the signature of functions exposed by the tools in a tool chain. Examples of approaches describing structural concerns are metamodels or grammars. • The semantic concern describes the meaning of data and services of different tools in a tool chain. Examples of approaches describing semantic concerns are semantics-preserving model transformations or ontologies. • The architectural concern describes the “fundamental concepts or properties of a tool chain embodied in its elements and relationships” [93]. An approach describing the architectural concern of a tool chain may describe tools as components and the integration between tools as connectors. To build a tool chain, usually all concerns need to be addressed, however, not all concerns are explicitly described. To describe a tool chain, the characteristics of integrated tools need to be described, which are covered by technical and structural concerns, and the characteristics of sets of integrated tools, which are covered by semantic and architectural concerns. In Figure 3.1 the integration concerns are ordered, so the scope is decreasing and the amount of details is increasing (from top to bottom). This criterion addresses the description of the concerns, in contrast to related classifications, which address the features of interoperability. The features of interoperability can be classified, for example by the Levels of Conceptual Interoperability Model (LCIM) used in the simulation community [162]. This criterion addresses the question: Which integration concerns are covered by the description of the tool chain? The criterion is measured in terms of the set
3.1. CRITERIA FOR THE DESCRIPTION OF TOOL CHAINS
21
Figure 3.1: Tool integration concerns
of covered concerns: technical concern, structural concern, semantic concern and architectural concern.
3.1.2
Coverage of Integration Aspects
Wasserman introduced several integration dimensions to delimit the scope of tool integration [163]: data integration, control integration, process integration, platform integration and presentation integration. This classification is refined by splitting both data integration and control integration into two classes to provide finer distinctions. The resulting classes are called integration aspects. This criterion addresses the question: Which integration aspects are explicitly described at an appropriate level of abstraction? For measurement of this criterion, we use a set of the values data-transfer, data-tracing, control-invocation, controlnotification, process, platform and presentation. The different aspects of tool integration are visualized in Figure 3.2 and explained in the following. • Data-Transfer Integration Aspect: Data integration can be realized by transferring data between the integrated tools. In general, the integrated tools expect the data according to different structures, which requires conversion of the tool data in a semantics-preserving manner. • Data-Tracing Integration Aspect: Data integration can also be realized by linking data between the integrated tools by traces. The linking of fine-grained data elements of the tools requires support for creation and management of links. In this context it is important to distinguish between the description of trace instances and the description of the possibility to create traces between certain types of data.
CHAPTER 3. CRITERIA FOR THE DESCRIPTION AND DEVELOPMENT 22 OF TOOL CHAINS
Figure 3.2: The tool integration aspects
• Control-Invocation Integration Aspect: Control-invocation allows users or parts of the tool chain to invoke services of other tools or parts of the tool chain. • Control-Notification Integration Aspect: Control-notification allows tools or parts of the tool chain to pass information to the tool chain user. • Process Integration Aspect: Process integration allows the tools of the tool chain to interact according to a description of the development process. To realize process integration, the tool chain needs to be aligned to the development process. In addition, the tool chain needs to have a notion of the state of the development process, which can be either realized dynamically, using events, or statically, using a predefined sequence. Tool chains with eventtriggered process integration stay in the background monitoring events that trigger tool chain activity. The events can be caused by users or by other tool chain activities. Tool chains with sequence-based process integration perform a number of activities in sequence, with little user interaction. The need for alignment between the tool chain and the development process, requires the possibility to describe how the tool chain reacts to certain events in the development process. • Platform-Distribution Integration Aspect: In globally distributed product development, specific phases of the development process might be handled at remote locations, thus the description of the tool chain needs to allow for describing the tool chain as a distributed system. To enable a smooth, distributed development process, the tools from different locations need to be integrated into a globally distributed tool chain [87]. Here the explicit description of platform integration is of interest. • Presentation Integration Aspect: Presentation integration provides a common user interface with a unified look and feel for the data and services of the tools
3.2. CRITERIA FOR THE DEVELOPMENT OF TOOL CHAINS
23
in the tool chain.
3.1.3
Overview of the Tool Chain
As tool chains become larger in size and span multiple integration aspects, an overview of the tool chain is important to take all relevant integration aspects into account. This criterion addresses the question: Can the description provide a coherent and complete overview of the whole tool chain including all integration aspects? The criterion is measured in terms of the values support and missing support for an overview of the tool chain.
3.1.4
Domain-Specific Description
Describing systems using general purpose languages or languages created for different domains, may introduce accidental complexity, i.e., make the description of the system more complex than necessary. This criterion addresses the question: Is the tool chain described using specific concepts from the domain of tool integration? For measurement of this criterion, a distinction is made between a description that uses concepts from the domain of tool integration, a description that uses generic concepts or borrows concepts from other domains. The use of source code is not considered.
3.1.5
Graphical Representation to Support Communication
Problems in interdisciplinary communication often arise from the lack of a shared terminology [4]. A boundary object is defined as “an analytic concept of those scientific objects, which both inhabit several intersecting social worlds and satisfy the informational requirements of both of them” [149] and can thus be a means to support interdisciplinary communication. Here the tool chain description is an object in the world of the various stakeholders of tool chains (see Section 1.2.2). A description of the tool chain that the various stakeholders can relate to, can become a boundary object that may facilitate communication. The tool chain description should allow communication of an envisioned or already existing tool chain to different stakeholders, and should have a graphical representation. Furthermore, the graphical representation should be consistent with the implementation of the tool chain. This criterion addresses the question: Which parts of the tool chain can be graphically represented by the description? For measurement of this criterion, the values whole tool chain or parts of the tool chain are used to describe the scope of the graphical representation.
3.2
Criteria for the Development of Tool Chains
As described in Section 1.2, there is a need for methods and tools for supporting the development of tool chains. The goals of this support are to provide a structure
CHAPTER 3. CRITERIA FOR THE DESCRIPTION AND DEVELOPMENT 24 OF TOOL CHAINS for the development process and to reduce the overall effort required for developing tool chains. Methods and tools should support the various activities of tool chain development. In this work we focus on the following activities: • Specification: The description should allow specification of a tool chain and capture the important design decisions involved in creating a tool chain. Specification methods should support the creation and refinement of the description of a tool chain. • Analysis: The description of a tool chain should be analyzable to check and estimate the properties of the tool chain. Analysis methods should be available to analyze both functional and non-functional properties of the tool chain. Analysis methods can be used to determine if the described tool chain can fulfill the requirements. For an envisioned tool chain, the analysis should be performed early in the development process, before the tool chain is implemented. For an existing tool chain, the analysis can provide guidance for improvements of the design. • Synthesis: The description of a tool chain should be a blueprint for the realization of the tool chain. Synthesis methods should be available to create an implementation of the complete tool chain, which should be consistent with the description of the tool chain. Besides the above activities, which are in the scope of this work, additional activities could be supported. Support could be provided by methods for validating the tool chain against the expectations of the users, methods for testing the implementation of the tool chain, methods for the evolution and maintenance of tool chains and methods for the deployment of tool chains. We leave the criteria for evaluating the support for these development activities to future work.
3.2.1
Specification Support: Tool Chain
A tool chain needs to be tailored to the set of development tools and the product development process that it is intended to support. This criterion addresses the question: To what extent is the creation of an overall specification of the tool chain supported? It is measured in terms of the values automated, semi-automated and manual and unavailable specification support.
3.2.2
Specification Support: Tool
The data and services of the tools that are integrated by the tool chain need to be specified. The criterion addresses the question: To what extent is the activity of specifying the integrated tools supported? The extent of automation is measured in terms of the values automated, semi-automated, manual and unavailable specification support.
3.2. CRITERIA FOR THE DEVELOPMENT OF TOOL CHAINS
3.2.3
25
Specification Support: Other Tool Chain Parts
Besides the tools, other parts of the tool chain, such as the data-transfer, invocation, notification and tracing, also need to be specified. The criterion addresses the question: To what extent is the activity of creating the specification of the remaining tool chain parts supported? It is measured in terms of the values automated, semiautomated, manual and unavailable specification support.
3.2.4
Analysis Support: Verification
The description of the tool chain needs to be correct and it needs to fulfill the given requirements. This criterion addresses the question: To what extent is the creator of a tool chain supported by methods that check that the requirements are met by the tool chain description and that the tool chain description is correct? This criterion is measured in terms of the values automated, semi-automated, manual and unavailable verification support.
3.2.5
Analysis Support: Non-Functional Properties
Besides the functional correctness of the tool chain, the non-functional properties (NFPs) of tool chains need to be within acceptable limits. For the largest possible leverage, the analysis should be performed before the tool chain has been built. This criterion addresses the question: To what extent is the creator of a tool chain supported in analyzing the non-functional properties of a tool chain, such as the construction cost of the tool chain? This criterion is measured in terms of the values automated, semi-automated, manual and unavailable support for analysis of NFPs.
3.2.6
Synthesis Support: Tool Chain
The tool chain realization consists of a number of parts that realize the connections between the tools. This criterion addresses the question: To what extent can the implementation of the complete tool chain be synthesized from the specification? This criterion is measured in terms of the values automated, semi-automated, manual and unavailable support for synthesis.
3.2.7
Synthesis Support: Tool
To realize the tool chain, wrappers for each of the integrated tools are created to expose the data and services of the tools. This criterion addresses the question: To what extent can the wrappers for the integrated tools be synthesized from their specification? This criterion is measured in terms of the values automated, semiautomated, manual and unavailable support for synthesis.
CHAPTER 3. CRITERIA FOR THE DESCRIPTION AND DEVELOPMENT 26 OF TOOL CHAINS
3.3
Summary
The goal of this work is to devise methods and tools for the description and development of tool chains. A number of criteria to characterize the description and development of tool chains were selected and consist of a question and a metric. The criteria and will be used to evaluate both existing approaches (Chapter 4) and the results of this work (Chapter 7).
Chapter 4
State of the Art In this chapter, an overview of the state of the art in tool integration is provided. First, some relevant basic concepts (Section 4.1) are introduced. Then, state of the art tool integration approaches are presented (Section 4.2) with a focus on model-based tool integration approaches (Section 4.2.1) and service-oriented tool integration approaches (Section 4.2.2). Finally, selected state of the art approaches are characterized according to the previously elicited criteria (Section 4.3).
4.1
Basic Concepts and Terminology
In this section, some basic concepts relevant to the area of tool integration are introduced. The concepts are from the area of models, languages and architecture and are relevant since they are used throughout the thesis. Model-based and model-driven approaches: use explicitly represented models as primary artifacts for describing a system [131]. Model-based approaches focus on models as important artifacts for describing a system [156]. Model-driven approaches are a specialization of model-based approaches, where models are not just used descriptively, but they are used as construction tools [156]. During development, a series of such models are specified, refined and transformed. The goals of these approaches are the management of complexity, the reduction of the risks of development, the improvement of the quality of the developed system and the improvement of the development efficiency. Model: “A model is a simplification of a system built with an intended goal in mind. The model should be able to answer questions in place of the actual system” [24]. Several kinds of models exist [156], such as mental models, conceptual models, formal models and executable models. Metamodeling Levels M0-M3: are defined by the OMG [132]. They describe the conformance relation between objects of the real world (M0), models (M1), 27
28
CHAPTER 4. STATE OF THE ART metamodels (M2) and metametamodels (M3), as depicted in Figure 4.1: a model conforms to a metamodel and a metamodel conforms to a metametamodel. Some metametamodels can be used for their own definition, a concept called meta-circularity [80]. (For a discussion on the definition of a metamodel, which is in conflict with the use of the Metamodeling Levels by the OMG, see [108].)
Figure 4.1: The metalevels of models and model transformations [27] Model Transformation: is the “automatic generation of one or multiple target models from one or multiple source models, according to a transformation description” [122]. The model transformation description is expressed in a model transformation language, such as QVT (Query/View/Transformations) [137] or ATL (ATLAS Transformation Language) [96]. To produce the target model, the model transformation description is interpreted by a model transformation engine. A model transformation description can be modeled as well, so the model transformation description conforms to a model transformation metamodel (see Figure 4.1). In [26] the state of the art in model transformation is reviewed, including the terminology, usage scenarios, a classification scheme of the problems that are solved by model transformations, a classification scheme of model transformation languages and an overview of several model transformation languages and engines. Language: comprises “the set of abstract syntax models. No meaning is given to these models” [80]. Concrete Language: “comprises both the abstract syntax and a concrete syntax mapping function. A single language may have several concrete languages associated with it” [80]. Formalism: “consists of a language, a semantic domain and a semantic mapping function giving meaning to a model in the language” [80].
4.1. BASIC CONCEPTS AND TERMINOLOGY
29
Concrete Formalism: “comprises a formalism together with a concrete syntax mapping function” [80]. Semantic Mapping Function: maps the abstract syntax of a language to a semantic domain and can be described formally or informally [57]. Domain-Specific Modeling Language: is a modeling language tailored to a specific application domain that captures the concepts of this domain and typically has a narrow scope [102, 123]. In contrast, a general purpose modeling language has a broad scope and is often standardized, an example is the Unified Modeling Language (UML) [139]. Customizations of a general purpose modeling language to capture the concepts of a specific domain, are a compromise between the above options. An example is the UML profile mechanism, a lightweight extension for UML [139]. Architecture: is defined as the “fundamental concepts or properties of a system in its environment embodied in its elements, relationships and in the principles of its design and evolution” [93]. Architecture Description: is a “work product used to express an architecture” [93] and typically comprises the architectural concepts configuration, component, connector and interface [153]. Architecture Description Language (ADL): is defined as “any form of expression for use in architecture descriptions” [93] and describe and formalize a highlevel decomposition of a system. A number of surveys compare the ADLs with respect to their ability to describe generic architectures [60, 89, 119] or architectures of a specific domain. In that case, the ADL is capable of representing domain concepts, e.g. architectures of embedded systems [72]. An example is EAST-ADL [63], which is capable of representing concepts from the automotive embedded systems domain. Specialized ADLs for the tool integration domain are not available. Standardized Exchange Format: Several standards and conventions for exchange formats have been proposed [104], but due to their large number, their generic applicability is limited. The XMI (XML Metadata Interchange) [133] format defined by the OMG (Object Management Group) is often used for serializing models. XMI is quite generic and does not specify the metamodels to be used for representing data for specific domains. More restrictive exchange formats specify the metamodels to be used for the data of certain domains, such as the STEP standard (ISO 10303) [92] and the OSLC (Open Services for Lifecycle Collaboration) [141] initiative. STEP defines several application protocols for specific domains, such as AP233 for systems engineering. Building OSLC-compliant tool chains requires the use of many technologies and is thus complex.
30
CHAPTER 4. STATE OF THE ART
Ontology: is defined as a ”formal, explicit specification of a shared conceptualization” [83]. This shared conceptualization can provide a common reference for several tools [126, 161] and each tool uses a view of the shared conceptualization [79]. Typically, a manual approach is used to define an ontology, but automated approaches exist as well [151]. Approaches either define a single, comprehensive ontology or a collection of several ontologies. When several ontologies are used, the links between the ontologies need to be defined separately. To reduce the effort of defining the mappings between ontologies, small domain ontologies are proposed [17].
4.2
Tool Integration
In the context of this work, we are concerned with the integration of development tools. The data that a development tool operates on is called tool data. The functionality or services that a development tool provides are called tool services. Tool integration is defined as the activity of producing an environment of tools that supports the development process by sharing and reusing artifacts created with different tools, tracing between these artifacts, invoking services of several tools and notifying developers (according to [163]). Tool integration is thus concerned with the relationships among tools, the properties of the relationship and the degree to which tools agree [154]. The outcome of tool integration is a seamless engineering environment of several development tools [52], and if it is a realized in software, it is called tool chain. The assumption of the research community is that a tool chain of several integrated tools increases productivity and product quality [164]. A broad overview of the literature on tool integration is provided in the annotated bibliographies of Brown [52] and Wicks [165]. The scope of tool integration is defined by the classification of integration dimensions [163], which is refined in Section 3.1.2 into the following integration aspects: data-transfer, data-tracing, control-invocation, control-notification, process, platform and presentation. The technology, which is used to realize tool integration, is called integration technology. Typically, integration technology is generic technology that is applied in a specific way to the tool integration challenge. Often one technology may be used to realize a specific aspect of tool integration. For example, the data integration aspect may be realized using modeling technology, i.e. models, metamodels and model transformations (see Section 4.2.1) and the control and platform integration aspect may be realized using middleware technology and services (see Section 4.2.2). The technical space (also called technological space) concerns the technology used for representation of the tool data [74, 109, 122]. Examples for technical spaces are EMF (Eclipse Modeling Framework) [150] or XML (Extensible Markup Language) [49]. Each technical space defines a format or protocol for representation and a set of technologies to work with the representation. The technical space for integration is the technical space used as common ground for integration of tools (see Figure 4.2). A commonly used approach for tool integration is a tool adapter,
4.2. TOOL INTEGRATION
31
which is software that provides the data and services of a tool in the technical space for integration (see Figure 4.2).
Figure 4.2: Tools, tool adapters and the technical space for integration
4.2.1
Model-Based Tool Integration
Model-based tool integration uses modeling technologies, such as models, metamodels and model transformations, to realize tool integration. Model-based tool integration focuses on the data integration aspect [100] and usually covers both data-transfer and data-tracing. The tool data is stored in tool-specific models, which correspond to tool-specific metamodels. Model-based tool integration provides means for specifying mappings between tool-specific metamodels to overcome the semantic, syntactic and technical heterogeneity between the tool data [100]. Model-based tool integration is primarily used for integrating modeling tools, but can also be applied to other types of tools that do not define an explicit metamodel. For such tools, a metamodel is ascribed to the tool allowing the data of the tool to be represented as a model. Almost all approaches use model transformations as the operational basis for data integration. Model transformations are either directly specified or generated from other representations. In the following, we present different building blocks for realizing model-based tool integration. Model Transformations for Tool Integration: Model transformations are typically used as an executable representation for the mappings between metamodels, which describe the data of the tools [157]. Model transformations are either specified manually, generated from weaving models [65, 66] or generated from ontologies [90]. Several approaches explore the use of manually specified model transformations for tool integration, for example the MOFLON language [6] and Eclipse-based languages [70]. Model transformations can be applied for model synchronization [55, 81], to keep two or more models in a consistent state. A change in either of the models leads to an appropriate, incremental update of the other model(s). Annotation-based Approaches: Annotation-based approaches allow the user to define annotations on the elements of one of the models (M1-level) involved
32
CHAPTER 4. STATE OF THE ART in the integration. The annotations are a support for realizing more accurate mappings, and are complimented with an executable mapping, usually in the form of model transformations. The model transformation rules use the information provided by the annotations and are relatively simple. For UMLbased approaches, the annotations can be realized by stereotypes of the UML Profile mechanism. An example is the integration of SysML and Modelica [142]. The BIZYCLE approach uses annotations to prevent both structural and semantic inconsistencies [125].
Pivot Metamodel: If each tool had a connection to each other tool, the number of connections would be in O(n2 ), with n being the number of tools. The pivot metamodel serves as a lingua franca, which reduces the number of connections between the tools to O(n). Since each tool only needs to map to and from the pivot metamodel. The pivot metamodel is instantiated at run-time, and the resulting model is used as an intermediate model to represent data from several tools or modeling languages. Pivot metamodels are typically established for a specific domain, such as EAST-ADL2 [63] for the automotive embedded systems domain and the CESAR Common Metamodel [19] for the domain of safety-critical embedded systems. Pivot metamodels are also used for mappings between different development environments [54] and between architecture description languages with DUALLY [115], for visualization tools [114] and business processes [170]. The approach by Herzog [88] proposes to establish a common information metamodel for the exchange of systems engineering data. Model Management Frameworks: Frameworks for model management provide a model repository, model registry, model transformation tools, editing tools and browsing tools. Model management also provides operations on models, for example match, diff, copy, merge, compose, invert [22]. A model registry is provided for identifying, storing and retrieving both models and metamodels. An example of an early model management framework is Rondo [121]. It is increasingly recognized that not only the model, but also the mapping between different models needs to be managed by these platforms [23]. However, model management frameworks assume that the tool data is available in a shared technical space and thus typically do not cover the technical integration concern (see Section 3.1.1). Model-Based Tool Integration Frameworks: Frameworks for tool integration provide reusable components for building tool chains. Model-based tool integration frameworks focus on the data integration aspect, and control integration is typically not present or a secondary issue. Examples are MOFLON [6], OTIF [101, 152], ModelBus [85] and ModelCVS [107]. The tool integration frameworks ToolNet [5] and TiE [105] are based on MOFLON, which provides MOF-based metamodeling and a model transformation engine. The Open Tool Integration Framework (OTIF) [101, 152] provides reusable com-
4.2. TOOL INTEGRATION
33
ponents and libraries to build tool chains and focuses on data integration. OTIF uses the GReAT model transformation language [16] for data integration, but control integration is out of scope. ModelBus [85] is a model-based and service-oriented integration framework and thus provides data and control integration. In addition it provides a repository for EMF models and support for ATL [96] and QVT [137] transformations. An example of a modelbased tool integration approach using ontologies is the ModelCVS framework [97, 99, 107]. ModelCVS maps tool-specific metamodels to an ontology and relationships between the tool-specific ontology elements are defined.
4.2.2
Service-Oriented Tool Integration
In global engineering settings, engineers from different locations participate in the product development process [86]. Thus the development tools and activities are distributed over several locations [87] and as a result, tool chains become distributed systems that are realized on heterogeneous platforms. Service-oriented tool integration approaches use services to realize the control integration and platform integration aspects. A wrapper for each development tool exposes the tool services. This wrapper is called a service-oriented tool adapter. Tool chains are realized by orchestrating the services provided by service-oriented tool adapters. In the following, we present different building blocks for realizing service-oriented tool integration. Languages for Service Engineering: General purpose modeling languages such as UML can be applied for modeling general service-oriented solutions. Domainspecific modeling languages for services strive to expose the properties of services, resulting in a fine-granular description of services. Examples are the Service Oriented Modeling Framework [20] and approaches using UML profiles, such as the UML profile for software services [95], the SOAML UML profile for services [138] or the UML4SOA profile [82]. While these languages can be used for building tool chains, they provide a technology-centric description at a low-level of abstraction. Languages for Workflows and Orchestration: Workflows are defined as “the organization of a structured application in an abstract fashion, such that the implementation of the atomic tasks being organized is independent from the organization itself ” [117]. Workflow languages can thus be used for realizing process integration. A comparison of different workflow languages is provided in [159]. Orchestration is the centrally controlled interaction of services and is thus a means for expressing process integration. The orchestration of web services can for example be modeled with BPMN (Business Process Modeling Notation) [140], which is not executable, or with BPEL (Business Process Execution Language) [127], which can be executed. The Service Component Architecture (SCA) [128] is a middleware architecture for building serviceoriented solutions and includes a language for describing the composition
34
CHAPTER 4. STATE OF THE ART of components. While these languages can be used for manually building service-oriented tool integration solutions, the languages do not provide specific support for tool integration.
Service-Oriented Tool Integration Frameworks: Jazz [78] is a service-oriented tool integration framework that provides storage and version management. The services implemented in Jazz use a RESTful (Representational State Transfer) [75] architecture and are compliant with the specification of the OSLC initiative (Open Services for Lifecycle Collaboration) [141, 166]. Another service-oriented tool integration framework is jETI [116], focuses on control, process and platform integration but data integration is not supported. It assumes that the integrated tools are command-line tools, thus tool chains are realized as sequences of tools. ModelBus [85] combines a model-based and service-oriented tool integration approach. It provides a repository for EMF models and support for ATL and QVT transformations. For each tool, a tool adapter is created that uses SOAP-based web services. These services can be orchestrated using a BPEL [127] engine for process integration. CORSET [68] is an emerging framework for the integration of web applications based on a domain-specific language. Since the integrated tools are web-applications, data and functionality are available in a common technical space for integration and no tool adapters are needed. The integration is realized using a browser-based mechanism to add a user interface and integration functionality to the integrated web applications. While the previous tool integration frameworks were generic, there are also integration frameworks for specialized application domains, such as the Kepler framework [113] for tool integration in scientific workflows and BiojETI [110] for remote tool integration for bioinformatics applications. The OSLC initiative (Open Services for Lifecycle Collaboration) is an industrial effort that aims at standardizing different choices for tool integration solutions [141], such as the technical space for integration, the communication protocols and architecture for tool adapters, directory services, data representation, data structures and metadata. OSLC proposes a RESTful architecture [75] and the use of the use of the Linked Data Model [21]. An OSLC-compliant tool or tool adapter represents tool data in the form of an OSLC Resource, a protocol on top of the Resource Description Format (RDF) [106], and offers it for integration with other tools. A Resource Shape describes the data structure of the Resource and can be requested at run-time. An OSLC tool adapter furthermore consists of a ServiceProvider, ServiceCatalog, Resources and ResourceShapes. Resources represent the data of the tool and correspond to a model. ResourceShapes describe the structure of the Resource and are needed for reflection and discovery. The ServiceCatalog lists all the available services of the tool, such as data access methods. Each service in the ServiceCatalog is specified by a QueryCapability to retrieve data and a CreationFactory to create new data. The necessary effort and cost for creating service-oriented
4.3. CHARACTERIZATION OF TOOL INTEGRATION APPROACHES
35
tool chains that are compliant to OSLC are considerable. The tool chains are complex service-oriented systems, which require web servers, configuration files, an implementation that conforms to the service-oriented standards and various metadata for the data and services. OSLC provides standardized communication protocols and data structures, but the heavy technological constraints contribute to the increasing complexity of tool chain development.
4.3
Characterization of Tool Integration Approaches
The following model-based and service-oriented tool integration frameworks are selected for a deeper analysis and characterization: ModelBus [85], OTIF [152], jETI [116], MOFLON [6], ModelCVS [98], OSLC [141] and CORSET [68]. These frameworks are analyzed according to the criteria for the description and development of tool chains that were introduced in Chapter 3.
4.3.1
Characterization of the Description of Tool Chains
The surveyed approaches provide different means for the description of tool chains. In the following the characteristics of these descriptions are analyzed according to the criteria introduced in Section 3.1. Coverage of Integration Concerns To analyze the coverage of integration concerns provided by the different approaches, the classification in Figure 3.1 is used. The descriptions used in the surveyed approaches cover the integration concerns to different extent. All model-based integration approaches provide possibilities to describe semantic concerns by semantics-preserving model transformations and structural concerns by metamodels. MOFLON focuses on the description of semantic concerns by graph transformations and structural concerns are realized by MOF-conform metamodels. ModelCVS describes semantic concerns by an ontology for the integrated tool data and by the pattern-based model transformation language CAR. In addition to descriptions for structural and semantic integration concerns, OTIF covers the architectural integration concern by specifying two patterns for tool integration. The service-oriented approaches jETI and OSLC explicitly describes structural concerns by the definition of data structures. CORSET focuses on structural concerns by using syntactic analysis of web-pages that present tool data. An outcome of the above analysis is that the technical and architectural integration concerns are often not described by dedicated languages. While the technical integration concern is typically described using source code, the architectural integration concern is not described at all by most approaches in the scope of this survey. OTIF is the only approach, which stresses the importance of the architecture for tool chains by suggesting two design patterns for tool integration that can provide conceptual guidance for creating the architecture of a tool chain. To use,
36
CHAPTER 4. STATE OF THE ART
apply and combine these patterns for constructing a practically useful tool chain, additional support is needed. Coverage of Integration Aspects To analyze the coverage of integration aspects provided by the different approaches, the classification in Figure 3.2 is used. • Data-Transfer: Model-based approaches, such as MOFLON, OTIF, ModelCVS and ModelBus, use a model transformation language or a pivot language to describe data-transfer. Service-oriented approaches such as jETI and OSLC do not offer specific descriptions for data-transfer. • Data-Tracing: Model-based approaches, such as MOFLON and ModelBus, support traces as a byproduct of the execution of model transformations, however, tracing is not explicitly supported independently from the datatransfer realized by model transformations. Separate approaches for tracing need to be used, such as described in [124]. The service-oriented approach jETI does not offer specific descriptions for data-tracing, but OSLC provides concepts for tracing based on the linked data model. • Control-Invocation: Service-oriented approaches, such as jETI, CORSET and ModelBus, can describe the invocation of tool services. Model-based approaches, such as MOFLON and ModelCVS, do not offer possibilities to describe invocation. • Control-Notification: ModelBus is the only surveyed approach that allows for an explicit description of user notification. Other approaches may be able to realize user notification by implementation. • Process Integration: Service-oriented approaches use either general-purpose workflow languages, languages for enacting business processes or executable process modeling languages. ModelBus uses BPEL [127] workflows, which were originally designed for automating business processes. ModelBus is able to describe sequence-based process integration, and defines a limited number of events on its repository, which allow for event-triggered invocation. jETI provides a sequence-based description of process integration, however, an events-based description is not available. The OSLC specification for automation offers an interface for sequence-based systems, but it needs to be described using source code. CORSET provides an event-triggered description of process integration. • Platform Integration: Model-based tool integration approaches typically assume that all tools are deployed locally. Service-oriented tool integration approaches, such as jETI and ModelBus, support the integration of distributed tools.
4.3. CHARACTERIZATION OF TOOL INTEGRATION APPROACHES
37
• Presentation Integration: OSLC is the only surveyed approach that offers a description for presentation integration by the concept of delegated user interfaces. Presentation integration is not explicitly described by the other surveyed approaches. While most of the surveyed approaches are able to describe several integration aspects, no approach covers all integration aspects. For integration aspects that are not explicitly described by a specific approach, an implementation may still be created using source code. Overview of the Tool Chain The surveyed approaches cover the description of several integration aspects of tool chains and to express these integration aspects, separate descriptions are typically used: workflows are used to describe process integration (e.g. in jETI or ModelBus) and model transformation languages (e.g. in ModelBus or MOFLON) are used to describe data-transfer. A dedicated overview of the tool chain is not available and neither workflows nor model transformations provide an overview of the tool chain for several reasons: • The workflow language and the model transformation language each capture a partial view of the tool chain. Each view describes the tool chain from the perspective of the respective integration aspect. An overview of the tool chain, however, needs to consider all relevant integration aspects. • To describe a tool chain, several artifacts representing each integration aspect are needed, for example several instances of model transformations to describe the data-transfer aspect and several workflows to describe the process integration aspect. An overview of the artifacts. This disintegrated view might be sufficient for the execution of the tool chain, but development of a tool chain could be better supported by an additional overview of different integration aspects and artifacts used for describing a tool chain. Domain-Specific Description CORSET provides a domain-specific description for the integration of web applications and focuses on the control, process and platform integration aspects. ModelCVS provides a domain-specific pattern-based model transformation language for the data integration aspect. The surveyed approaches provide domain-specific descriptions for tool chains, but these cover only a limited set of integration aspects. The descriptions provided by the other surveyed tool integration approaches use general purpose languages for representing specific integration aspects, such as a MOF-conform model transformation language in MOFLON. Also, languages from other domains are borrowed for describing tool integration aspects, for example ModelBus uses BPEL [127] from the business process domain.
38
CHAPTER 4. STATE OF THE ART
Since the various approaches focus on a subset of the integration aspects, missing integration aspects need to be realized using source code. In MOFLON the data-transfer is described using a transformation language, but control or process integration is not supported. jETI supports control, process and platform integration, but no explicit language for data integration is available. The unsupported integration aspect of the respective approach can be added, but requires the use of source code. Graphical Representation to Support Communication The surveyed approaches provide graphical representations for dedicated integration aspects and thus for parts of the tool chain. ModelBus and jETI provide dedicated graphical representations for process integration. MOFLON and ModelCVS provide dedicated graphical representations of the model transformations for data-transfer. However, a graphical representation of an overview of the tool chain including all relevant integration aspects has not been found among the surveyed approaches.
4.3.2
Characterization of the Development of Tool Chains
In this section, the development support for specification, analysis and synthesis provided by the surveyed approaches is characterized according to the criteria introduced in Section 3.2. Specification Support: Tool Chain To support the specification of tool chains built from web-applications, CORSET allows recording sequences of user interactions with web-applications. For the other surveyed approaches, the specification of a complete tool chain is assumed to be performed manually. Specification Support: Tool The specification of the data and services of a newly integrated tool is a manual, code-centric task for all surveyed approaches. Semi-automated specification support is available when an existing tool adapter is reused. For service-oriented approaches that describe their services using WSDL (Web Service Description Language) [58], such as ModelBus, standard service discovery can be used for obtaining a specification of the services in the interface of the tool adapter. However, only a specification of the tool services and no specification of the tool data can be discovered. The tool data, e.g. in the form of a metamodel, still needs to be manually specified in ModelBus. For OSLC, no automated support for specification is available.
4.3. CHARACTERIZATION OF TOOL INTEGRATION APPROACHES
39
Specification Support: Other Tool Chain Parts The specification of tool chain parts such as format conversions and model transformations requires a substantial manual programming effort. In model-based approaches, such as ModelBus and MOFLON, the model transformation rules need to be specified manually. In service-oriented approaches, such as jETI and OSLC, data integration is unsupported. Analysis Support: Non-Functional Properties Non-functional properties of tool chains have not received much attention, a finding that is supported by a systematic literature review [164]. The analysis of nonfunctional properties is not explicitly supported by the surveyed approaches, thus it can be performed manually, or it is unsupported. Analysis Support: Verification While generic verification techniques can always be applied on the source code realizing a tool chain, this type of verification support does not take the domainspecific properties of tool chains and the specific requirements of tool chains into account. The specific requirements of tool chains include the development process supported by the tool chain and the specific tools used. Verification of the specific requirements of tool chains is not supported by the surveyed approaches. Synthesis Support: Tool Chain As a purely service-oriented approach, jETI provides support for the synthesis of tool chains, which cover control, platform and sequence-based process integration. However, to support embedded systems development, all integration aspects need to be supported by the synthesized tool chain. If a description of a tool chain was available, which covers all integration aspects, this description could be used for generating source code and infrastructure configurations for a comprehensive tool chain. The surveyed approaches do not provide synthesis support for all integration aspects of a complete tool chain. Synthesis Support: Tool MOFLON provides semi-automated code generation for a skeleton of a MOFcompliant repository access method, but it is limited to tool data, tool services are not supported. OSLC does not have a synthesis mechanism, but the Lyo1 tool provides support for producing an OSLC-compliant implementation, based on annotations in Java source code. For the other approaches, the tool chain parts need to be created by manual programming, which requires knowledge in the implementation technologies. 1 http://www.eclipse.org/lyo
40
4.3.3
CHAPTER 4. STATE OF THE ART
Summary
Out of the reviewed state of the art approaches, several tool integration frameworks were selected for a closer analysis, since the goals regarding description and development support are aligned to the work in this thesis. The selected tool integration approaches were analyzed according to the criteria selected in Chapter 3. The descriptions provided by current approaches are limited in the concerns covered and in the aspects of integration covered. Most approaches describe several – but not all – aspects of integration. The aspects are described separately, so an overview that expresses the relationships between the aspects is difficult to obtain. Tool chains are described using domain specific languages covering a subset of the integration aspects, general purpose modeling languages, source code or specific languages for other domains, such as languages for business processes, which contributes to the accidental complexity of the description of tool chains. While the focus of model-based tool integration is on the explicit description of tool data and its relation (expressed as models, metamodels and transformations), the entire tool chain is not explicitly modeled. While all approaches have an implicit integration architecture, this architecture is either not made explicit or the architecture is purely conceptual and no explicit link between the architecture and the implementation exists. In addition, the support for the specification, synthesis and analysis of tool chains could be improved by automated methods that take the specific properties of the tool integration domain into account. The approach presented in this work intends to fill these gaps. After presenting the approach (Sections 5 and 6), we will evaluate it using the same criteria to check if the gaps could be filled (Section 7). To fill the gaps, we envision the following approach. Support for the development of a tool chain could be provided by a holistic description of the architecture of the tool chain. By describing the concerns of tool chains at an architectural level of abstraction, it could be possible to achieve an overview of all integration aspects and provide an information model for the detailed descriptions of different integration concerns. With a graphical representation, such a description of the tool chain could be used as a boundary object for communication among the stakeholders of the tool chain. The description can also serve as a basis for the automated support for specification, synthesis and analysis of tool chains and could have a central, coordinating role for the different activities of tool chain development.
Part II
Overview of Results and Evaluation
41
Chapter 5
A Modeling Language for Tool Chains This chapter explains the approach used to answer RQ2 (How can tool chains be described systematically? ). The approach aims to create a modeling language for tool chains, the Tool Integration Language (TIL). First, the objectives for the language are set (Section 5.1), then the relevant language concepts for the domain are elicited (Section 5.2), and the language is introduced in terms of abstract syntax, concrete graphical syntax and semantics (Section 5.3). A process for systematically developing tool chains based on the language is also proposed (Section 5.4). More details are available in the Appended Papers A, B and C.
5.1
Objectives for the Tool Integration Language
The objectives for TIL are set, to overcome the gaps identified by the characterization of state of the art approaches presented in Section 4.3. Thus, the objectives for TIL are expressed using the criteria for the description of tool chains introduced in Section 3.1: • Coverage of the architectural integration concern, with explicit links to semantic, structural and technical concerns. • Coverage of all relevant integration aspects. • An overview of the tool chain. • An explicit and domain-specific description of the tool chain that is independent of implementation technologies. • A graphical representation of the language that is consistent with the implementation of the tool chain, to support communication among the stakeholders of the tool chain. 43
44
CHAPTER 5. A MODELING LANGUAGE FOR TOOL CHAINS
5.2
Domain Analysis for Tool Chains
We follow a systematic approach for creating a domain-specific modeling language for tool chains. In a first step, a number of domain concepts for tool integration are identified using domain analysis [71]. In a second step, the identified domain concepts are mapped to architecture concepts. Due to the objective of TIL to focus on the architectural concern, domain concepts are mapped to appropriate architectural concepts that are required for any architectural description. For the first step, a top-down approach is employed and tool integration is broken down into successively smaller building blocks. A starting point is the definition of the scope of tool integration [11, 163], which spans several integration aspects: data integration, control integration, platform integration, process integration and presentation integration. Typical realizations of each integration aspect are further analyzed and domain concepts are extracted (emphasized in italic). • Data Integration: Tool data is the product data (of the embedded system) that a specific tool operates on. Tool data can be tightly integrated by datatransfer or it can be loosely linked by traces. For realizing both data-transfer and data-tracing, the structure of the data of each tool (e.g. in the form of a hierarchy) needs to be described. • Control Integration: Control integration allows for invocation of tool services and notification of users. The signatures of the functions of each tool need to be described. • Platform Integration: Tools may be deployed on a local or remote machine. The data and services need to be uniformly accessible, independent of the deployment of the tools. • Process Integration: To support a development process, all previously identified concepts need to be coordinated and combined into a tool chain that is aligned with the development process. The process can be specified as a sequence or it can be based on events triggered by users or parts of the tool chain. • Presentation Integration: A common user interface is provided for all functionality of the tool chain that can be triggered by a user. The identified domain concepts and their originating integration aspects are summarized in Table 5.1. A more detailed description of the domain analysis can be found in Appended Paper C. In the second step, the previously identified domain concepts are mapped to the concepts of an architectural description. Since an objective for the language is coverage of the architectural integration concern, the meaning of architecture in the context of tool chains is elaborated in more detail. In general, an architecture covers the “fundamental concepts or properties” [93] of a system. An architecture
45
5.2. DOMAIN ANALYSIS FOR TOOL CHAINS
X X X
X X
X X X X X X X
X X X X
X X X X X X X X X
Presentation
X X
Process
Platform-Distribution
X X
Control-Invocation
X X
Control-Notification
Data-Tracing
Identified Domain Concept Tool Chain Tool User Data Transfer Tracing Notification Invocation Sequence Events Signatures of the Tool Services Structure of the Tool Data
Data-Transfer
Table 5.1: Identified domain concepts and their originating integration aspects
X
X
can also be expressed in terms of the “principal design decisions made about the system” [153]. Typical architectural design decisions relate to structure, behavior, interaction, non-functional properties and implementation [153]. Applied to the context of tool chains, the architectural design decisions relate to: • Structure: the tools and their interfaces. • Functional behavior: how the tool chain reacts to events and the order of the activities in a tool chain. • Interaction: how the tools are connected and the nature of these connections. • Non-functional properties: e.g. the cost for realizing the tool chain, the cost savings achievable by the introduction of the tool chain, or the effort related to certification of tools and tool chains. • Implementation: e.g. the use of certain technical space for integration and integration conventions, such as OSLC [141]. These design decisions are captured by architecture descriptions, which are typically expressed using the following basic concepts [153]: configuration, component, connector and interface. The basic concepts of architecture descriptions have also been identified as the shared concepts among several architecture description languages [119].
46
CHAPTER 5. A MODELING LANGUAGE FOR TOOL CHAINS
To cover the architectural integration concern with the tool integration language, the domain concepts for tool integration identified in the first step are mapped to the basic concepts of an architecture description. This mapping of domain concepts to architectural concepts is summarized in Table 5.2 and the resulting language concepts are described in Section 5.3. Table 5.2: Mapping of the identified domain concepts to architectural concepts and the resulting TIL concepts Identified Domain Concept Tool Chain Tool User Data Transfer Tracing Notification Invocation Sequence Events
Architectural Concept Configuration Component Component Connector Connector Connector Connector Component Part of Connector
Signatures of the Tool Services
Interface
Structure of the Tool Data
Interface
5.3
Language Concept ToolChain ToolAdapter User DataChannel TraceChannel ControlChannel ControlChannel Sequencer Events of a a ControlChannel ToolAdapter Metamodel for Services ToolAdapter Metamodel for Data
The Tool Integration Language
In this section, we describe the design of a language that is built from the identified domain concepts. The language is designed in such a way that the concepts of the language are composable with each other, i.e. that a tool chain can be described as a composition of instances of the language concepts. The resulting language, the Tool Integration Language (TIL) can be considered both a domain-specific language [123] and an architecture description language [93]. In the following, TIL is briefly introduced in terms of abstract syntax, concrete syntax and semantics. A more detailed description can be found in Appended Paper C and in the TIL Report [29]. The abstract syntax of TIL is presented as a class diagram in Figure 5.1. The graphical concrete syntax of each language concept is introduced by a simple example in Figure 5.2, the concrete mapping function, which maps abstract to concrete syntax, is defined by corresponding circled numbers .. 0 7 in Figure 5.2 and the following text. This section also briefly introduces the semantics of TIL concepts. A ToolChain 0 provides a container for instances of TIL concepts. An instance of the ToolChain concept describes the tool chain by the composition of its contained instances of TIL concepts.
5.3. THE TOOL INTEGRATION LANGUAGE
47
Figure 5.1: A class diagram illustrating the abstract syntax of TIL
Figure 5.2: A simple TIL model illustrating the graphical concrete syntax of the language concepts
48
CHAPTER 5. A MODELING LANGUAGE FOR TOOL CHAINS
A ToolAdapter 1 is a software component that describes the role of a tool in the tool chain by exposing the services and data of the tool, which are relevant for the specific role. Exposing the services of a tool enables control integration. Exposing the data of a tool enables data integration. A ToolAdapter makes two kinds of adaptation: (1) It adapts between the technical space of the tool and the technical space of integration for both data and services. (2) It adapts the structure of data and the signature of services available in the development tool to the data structure and service signatures defined by the ToolAdapter metamodel. Each ToolAdapter has two associated ToolAdapter metamodels: one that specifies the structure of the exposed tool data and another that specifies the signature of the exposed services. In addition to the services defined in the metamodel, all ToolAdapters provide the default services activate to start the tool, injectData to load data (which is an instance of the ToolAdapter data metamodel) into the tool and extractData to access the tool data (as an instance of the ToolAdapter data metamodel). The ToolAdapter metamodels serve as an interface specification for the ToolAdapter and describe which data and services of the tool are exposed. See Appended Papers C and D for more information on the structure of the ToolAdapter metamodels and for examples. Subtypes of ToolAdapters are defined, such as a GeneratedToolAdapter, whose service implementation is generated based on the specification provided by the ToolAdapter metamodels; a DiscoveredToolAdapter, which is specified by its deployment address, allowing for discovery of the services and binding to the tool chain; and a Repository , 7 which provides storage and version management, e.g. a ToolAdapter for Subversion [144]. A DataChannel 5 describes the possibility to transfer and transform data from a source ToolAdapter to a target ToolAdapter at the run-time of the tool chain; it is a directed connection. The data originates from the source service of the source ToolAdapter (default service: extractData), is transformed and is finally received by the target service of the target ToolAdapter (default service: injectData). A model transformation is attached to the DataChannel; the source and target metamodels of the transformation need to match the respective data metamodels of source and target ToolAdapters. A TraceChannel 6 describes the possibility to establish trace links between the data of two ToolAdapters at the run-time of the tool chain; it is an undirected connection. A TraceChannel is a design-time representative for a number of trace links at run-time. At design-time one can specify the type of data that can be linked by traces. The endpoints of the traces can be restricted to a subset of the tool data by specifying the source service and target service (default service: extractData), which provide the data. At run-time, these services provide a list of all the source and target elements that are offered as endpoints for specifying a trace. A ControlChannel 2 describes an invocation or notification, it is a directed connection originating from a source component and ending in a target component. If the target of the ControlChannel is a ToolAdapter, the ControlChannel denotes the invocation of a tool service; if the target is a DataChannel, the data-transfer is
5.3. THE TOOL INTEGRATION LANGUAGE
49
executed; if the target is a TraceChannel, a dialog for creating traces is presented. If the target is a User, it denotes notification of the User. A condition for the execution of the ControlChannel can be specified by a guard expression. A service of the source component, called source service (default value: activate), can be specified as the event that triggers the ControlChannel. The invoked service in the target component is specified as the target service (default value: activate) of the ControlChannel. A Sequencer 3 describes a sequence of invocations or notifications. When a Sequencer is activated by an incoming ControlChannel, it activates the outgoing ControlChannels in the specified order. The order is specified by the events (0..n), which are specified as the source service in the outgoing ControlChannels from the Sequencer. Only after the service executed by the previous ControlChannel is finished, will the next ControlChannel be activated. A User 4 represents a real-world tool chain user. The concept is used to describe the possible interactions of the real-world users with the tool chain. Outgoing ControlChannels from the User denote the invocation of tool chain services by the real-world user. Incoming ControlChannels to a User denote a notification sent to the real-world user, e.g. by e-mail. By default, all TIL concepts describe parts of an automated tool chain, however some parts of the tool chain may not need to be automated and are manually integrated. TIL allows marking ControlChannels, DataChannels and TraceChannels as manually executed, in which case they are depicted by dashed lines. The semantics of TIL is defined in the text above. The denotational (translational) semantics is defined by the model transformation for code generation described in Section 6.6. In addition, compatible formal semantics of the behavior of TIL can be described by a mapping of TIL concepts to networks of finite state machines (FSMs). Initial work on the semantic mapping function for the formal specification of the behavior of TIL and its implementation as a model transformation for semantic anchoring [57] has been performed [31]. The TIL models are mapped to UPPAAL-style FSM models, since these models are formally defined and can be simulated and analyzed using the UPPAAL model checker1 [111]. The model transformation is defined in two steps. The first step defines for each model element in TIL a template of a corresponding FSM2 . The second step instantiates an FSM template for each element of the TIL model, so that the type of the FSM template matches the type of the TIL model element. In addition, the transitions of the FSMs are synchronized using UPPAAL channels reflecting the connections between the model elements in the TIL model. 1 In fact, UPPAAL supports networks of timed automata. Timed automata are an extension of finite state machines. The mapping from TIL to UPPAAL, however, does not use any of the advanced properties of timed automata, such as clocks. 2 For most language concepts the FSM template is defined by the type (language concept), only for ToolAdapters and Sequencers the FSM template depends on the model element.
50
5.4
CHAPTER 5. A MODELING LANGUAGE FOR TOOL CHAINS
Proposed Tool Chain Development Process with TIL
The intention of this section is to illustrate and explain the development of a tool chain using TIL. For this purpose, one possible tool chain development process is proposed, which uses platform-based design [103] as a reference model – other development processes are possible. Platform-based design structures the development process into two processes. The application development process maps functional requirements to a platform representation. The architecture implementation process is concerned with mapping the platform representation to an executable representation. A platform serves as a connection between the two processes. Platform-based design is often depicted by an hourglass shape, where the two processes are described by an upper and lower triangle [103]. The structure of platform-based design is applied to tool chain development with TIL, the result is depicted in Figure 5.3. As a modeling language for explicitly representing the tool chain at an architectural level of abstraction, TIL can be considered as a platform in the sense of platform-based design.
Figure 5.3: Platform-based design of a tool chain with TIL The role of the application development process (upper triangle) of platformbased design is to map the requirements of the tool chain to a TIL model. The requirements are partly given by the set of tools to be integrated, their data and services, and partly by the product development process, best practices and company policies for tool usage.
5.4. PROPOSED TOOL CHAIN DEVELOPMENT PROCESS WITH TIL
51
The architecture implementation process (lower triangle) is concerned with mapping TIL to an executable representation. The architecture implementation process resolves the concerns in tool chain construction (c.f. Section 3.1.1) regarding all covered integration aspects (c.f. Section 3.1.2). To realize this mapping, the TIL model is refined with further details to handle the semantic, structural and technical concerns. Model transformations are used for realizing semantics-preserving data-transfer. Metamodels are used for defining the structure of the data of each tool. The mapping between technical spaces is taken care of by the mapping to the implementation, integration conventions (such as OSLC [141]) and the tool APIs. In the following, the abstract platform-based development process is concretized by an explicit process model for tool chain development. In Figure 5.4 the process for developing a tool chain with TIL and its connection to the run-time of the tool chain is illustrated using the SPEM [135] notation. The development process for tool chains with TIL is structured into five phases: requirements engineering, conceptual design, detailed design, analysis and implementation. These phases are presented according to the order in which they are traversed during tool chain development. Platform-based design can be related to the concrete tool chain development process (c.f. with the ordinal number of the phases in Figure 5.4) by mapping the application development process to phases 1 – 3, and by mapping the architecture implementation process to phases 4 – 6. The complete tool chain development process has the following phases: 1. The requirements of the tool chain are elicited from the selection of tools and from the dependencies of tasks and tool usages in the product development process. 2. In the conceptual design phase, a conceptual model of the tool chain is described using TIL based on the requirements stipulated by the product development process. The conceptual model conveys the overall architecture of the tool chain, including the existing ToolAdapters, Users and connections between the ToolAdapters. 3. The alignment of the conceptual TIL model with the process model can be verified to highlight any intended or unintended discrepancies between tool chain design and the requirements stipulated by the product development process. Depending on the outcome of the analysis, the conceptual design phase can be iterated in order to create a conceptual model which is better aligned with the requirements. 4. In the detailed design phase, the conceptual TIL model is refined by different types of Channels and ToolAdapter metamodels. ToolAdapter metamodels are attached to each ToolAdapter in the TIL model to describe the data and services of the tool, which are exposed by the ToolAdapter. The connections between ToolAdapters and other components are refined by choosing the type of the connector (ControlChannel, DataChannel or TraceChannel).
52
CHAPTER 5. A MODELING LANGUAGE FOR TOOL CHAINS A model transformation is attached to each DataChannel in the TIL model; it describes the translation of data from the source tool to the target tool. The model transformation can be specified in different ways, either manually or computed based on the information in an ontology or weaving model (see Section 4.2.1). The conceptual TIL model with attached metamodels and model transformations yields a complete TIL model. 5. Additional analyses are possible based on the detailed design. The syntactic correctness of the model can be checked and non-functional properties, such as the development cost of the tool chain, can be estimated. Depending on the outcome of the analyses, the tool chain design can be corrected before proceeding to the implementation phase. 6. In the implementation phase, the TIL model can serve as a blueprint for implementing the tool chain. The code of the tool chain is compiled and deployed. 7. At run-time3 of the tool chain, the embedded developers use the deployed tool chain, which integrates several embedded systems tools.
There are different stakeholders of the tool chain, who are in contact with the tool chain at different points in the lifecycle of the tool chain. For this purpose, a distinction is made between the design-time of a tool chain and the run-time. At design-time of the tool chain, the tool chain development process is executed, which involves a process engineer, tool chain architect and tool chain developers. A process engineer may model the product development process that is supported by the tool chain. The tool chain architect defines the conceptual and detailed design of the tool chain. One or several tool chain developers implement the tool chain as software based on the tool chain design. At run-time, the tool chain software is executed to realize the data-transfer, traceability, invocation and notification to support the product development process of the embedded system. The embedded systems developers have the role of tool chain users. The role of the tool chain architect has been explicitly introduced to cover the responsibility of specifying, refining and analyzing the architecture of the tool chain. Since TIL allows the tool chain to be described independently of implementation technology, the role of the tool chain architect can be separated from that of the tool chain developer. As the tool chain users, embedded systems developers are familiar with the requirements for the tool chain, but not with their implementation. Thus, embedded systems developers may be suitable candidates to take on the role of the tool chain architect and leave the implementation to dedicated tool chain 3 Strictly
speaking, the run-time is outside the scope of the development process but has been added here for illustrating the connection between the tool chain and the embedded systems developers.
5.4. PROPOSED TOOL CHAIN DEVELOPMENT PROCESS WITH TIL
53
Figure 5.4: Process for developing a tailored tool chain with TIL, illustrated using SPEM [135] notation
54
CHAPTER 5. A MODELING LANGUAGE FOR TOOL CHAINS
developers. This separation of responsibilities is one attempt to resolve the unclear responsibility for the creation of tool chains observed in industry (see Section 1.2.2).
Chapter 6
Support for the Development of Tool Chains The previous chapter proposed a language for defining tool chain product models and a process model for developing tool chains with various phases. In this chapter, RQ3 is addressed (To what extent can the development of tool chains be supported by automated methods? ). Semi-automated development support for the various phases of tool chain development is provided, enabled by the explicit description of the tool chain in TIL. Figure 6.1 provides an overview of the tool chain development process, which extends the manual tool chain development process presented in Figure 5.4 through the following automated support: • The TIL Workbench, a development environment for tool chains (Section 6.1, Appended Paper C). • Construction of a conceptual TIL model from an existing SPEM process model (Section 6.2, Appended Paper E). • Refinement of a conceptual TIL model by adding metamodels to ToolAdapters (Section 6.3, Appended Paper F). • Refinement of a conceptual TIL model by creating model transformations for DataChannels (Section 6.4, Appended Paper G). • Correctness check of the tool chain design (Section 6.5.1, Appended Paper F). • Structural verification of the tool chain design (Section 6.5.2, Appended Paper H). • Cost analysis of the tool chain implementation (Section 6.5.3, Appended Paper I). • Code generation of the tool chain (Section 6.6, Appended Papers D and C). 55
56 CHAPTER 6. SUPPORT FOR THE DEVELOPMENT OF TOOL CHAINS
Figure 6.1: Process for developing a tailored tool chain with semi-automated support based on TIL, illustrated using SPEM [135] notation
6.1. A DEVELOPMENT ENVIRONMENT FOR TIL
6.1
57
A Development Environment for TIL
The TIL Workbench (see Figure 6.2) is intended to support the tool chain architect in specifying a tool chain with TIL. It consists of the TIL language defined as a modeling language and a graphical modeling environment for TIL in Eclipse1 . The TIL Workbench ensures that the specified models conform to the abstract syntax of the language. Some of the automated methods for development support introduced later in this chapter can be executed from within the TIL Workbench.
Figure 6.2: The TIL Workbench
6.2
Construction of a Conceptual TIL Model
In early design phase of the tool chain development process, a conceptual TIL model is created, which only describes the components and connections of the tool chain without any additional details. The conceptual model of the tool chain should be aligned to the product development process and the choice of development tools, so the tool chain can support the integration-related tasks in the development process. Development processes can be modeled for different purposes [64], however here we focus on process models that have been created as a means for documentation, and are expressed by the Software and Process Engineering Metamodel (SPEM) [135]. The following research questions (RQ3.1) guided the work: What is the relationship between a SPEM process model and the tool chain? How can tool chains be tailored, so they support a specific development process and development practice? 1 http://www.eclipse.org
58 CHAPTER 6. SUPPORT FOR THE DEVELOPMENT OF TOOL CHAINS If in addition to describing the tool chain as a model (e.g. using TIL), the process is also modeled (e.g. using SPEM), the relationship between the process model and tool chain model can be described. Possible relationships between SPEM and TIL models are identified and expressed by a mapping of a pattern of SPEM metaclasses to a pattern of TIL metaclasses. This mapping is implemented as a model transformation. Using the transformation and an existing process model, an initial conceptual design model of the tool chain is created. The main benefit of an automated mapping between process models and tool chain models is that an alignment between the design of the tool chain and the process can be achieved. This approach is detailed in Appended Paper E.
6.3
Refinement of ToolAdapters in a TIL Model
The conceptual TIL model needs to be refined by adding ToolAdapter metamodels that describe the data and the services exposed by each ToolAdapter and thus serve as interface specifications. If the ToolAdapter is to be newly implemented, the ToolAdapter metamodels need to be manually specified. However, if a ToolAdapter implementation already exists, has been developed by a third party, is deployed and needs to be reused in a new tool chain, it might be possible to gather the information necessary for the ToolAdapter metamodel from the interface of the deployed ToolAdapter. We study this problem in the context of OSLC-compliant [141] ToolAdapters (i.e. the interface of ToolAdapters follows OSLC conventions), since these may be provided by third parties; for example an OSLC-compliant ToolAdapter for the requirements engineering tool DOORS2 is available as a plugin. The following research question (RQ3.2) guided the work: How can the metamodels used for interface specifications of ToolAdapters in TIL be automatically discovered and re-engineered from deployed ToolAdapters? If an existing, already deployed ToolAdapter is to be reused and integrated into a tool chain, such as an OSLC-compliant [141] ToolAdapter provided by a third party, the integration of the ToolAdapter would be possible on implementation level. In this approach, however, we explore the integration at model level, since a complete model of the tool chain enables correctness checks, analysis of the tool chain and complete synthesis of the implementation. The integration on modellevel entails representing the interface of the remotely deployed ToolAdapter by ToolAdapter metamodels. This work explores, how the ToolAdapter metamodels of the remotely deployed ToolAdapter can be automatically discovered and integrated into a comprehensive TIL model of the tool chain. The approach is depicted in Figure 6.3 and detailed in Appended Paper F. Automated discovery and reverse engineering of the ToolAdapter metamodel is used during the design of the tool chain, when an unknown, remotely deployed ToolAdapter is integrated into the tool chain. The discovered and reverse engineered ToolAdapter metamodel is checked for consistency with the TIL model. If 2 http://www.ibm.com/software/awdtools/doors
6.4. REFINEMENT OF DATACHANNELS IN A TIL MODEL
59
Figure 6.3: Reverse engineered ToolAdapter metamodel enables correctness check
the models are consistent, the reverse engineered ToolAdapter metamodel is used for automatic generation of a local proxy for the remote ToolAdapter. The approach allows for the efficient reuse of deployed ToolAdapters in a new tool chain, ensures the consistency between the ToolAdapter metamodel and the deployed implementation, and the consistency between the ToolAdapter metamodel and the TIL model, enabled by the representation of all relevant information on the model level.
6.4
Refinement of DataChannels in a TIL Model
The conceptual TIL model needs to be further refined with detailed specifications for each DataChannel. DataChannels denote the transfer of data from a source ToolAdapter to a target ToolAdapter. The tool data is exposed by the ToolAdapter in the form of a model that conforms to the ToolAdapter metamodel. If the metamodels of source and target ToolAdapters are the same, the data can be simply copied between the ToolAdapters. In the more common case that the metamodels are different, the data needs to be transformed before it can be transferred to the target ToolAdapter. For this purpose, TIL offers the possibility to link a model transformation to each DataChannel. The model transformation converts the data between the metamodels of source and target ToolAdapters. The following research question (RQ3.3) guided the work: How and under which circumstances can the detailed specification of DataChannels be computed automatically? Typically, the details of a DataChannel are manually specified in the form of a model transformation, which requires time and effort. Especially if the requirements for the tool chain are still changing and prototypes of a tool chain are developed, an automated approach for the specification of model transformations can be valuable. In this setting, the intention is to rapidly and automatically create a first prototype of a model transformation, which can be manually refined later on.
60 CHAPTER 6. SUPPORT FOR THE DEVELOPMENT OF TOOL CHAINS Under certain conditions it might be possible to provide support for specifying a prototype model transformation automatically. The TIL model contains relevant information for generating the transformation, such as its execution direction and both its source and target metamodels. This information is not sufficient for an algorithmic approach, but a heuristic approach for prototyping model transformations can be realized. With the assumption that similar metaclasses of the metamodels of source and target ToolAdapters should be mapped, a model transformation can be computed using heuristics. As a measure for the similarity of the metaclasses, the similarity of the reference structure and the names of the metaclasses are used. The heuristic identifies corresponding elements between the source and target metamodels using similarity flooding [120] and the Levensthein distance [112]. The result of the algorithm is a matching table [73], which maps elements of the source metamodel to elements in the target metamodel. The matching table is automatically refined into a matching model by taking the containment hierarchy of the target metamodel into account. The model transformation T1 is a prototype, which may require manual refinement. Based on the corresponding elements that are specified in the matching model, a model transformation T1 is produced, which maps the data between the source and target ToolAdapters. T1 is produced by a higher-order model transformation T2 based on the information in the matching model. While matching algorithms have been applied previously [73], we focus on the applicability and evaluation of a matching algorithm in the context of prototyping tool chains. This step is detailed in Appended Paper G.
6.5
Analysis of TIL Models
The analysis of a tool chain design is intended to support the tool chain architect when designing a tool chain. An advantage of using an explicit model-based description of the tool chain is the possibility for early analysis. Early analysis allows for evaluating different designs of the tool chain and especially allows finding problems during design that would be more expensive to correct if discovered later [94]. Instead of applying generic, existing analysis techniques, we here focus on domain-specific analyses that make use of the additional knowledge of the domain of tool integration, which is encoded in TIL models.
6.5.1
Correctness Checks of the Tool Chain Design
Correctness checks are used to detect specification errors in TIL models. Syntactic correctness of the TIL model is checked by the TIL Workbench when a TIL model is created. In addition, the following checks for semantic correctness are performed. A TIL model provides language concepts for both specifying service signatures and invoking the services. All service calls need to be consistent with their respective specification. Correctness checks compare the usage with the specification. The services and data structures are specified in the ToolAdapter metamodels and are
6.5. ANALYSIS OF TIL MODELS
61
used in the ControlChannels. The TIL model is checked for correctness by analyzing whether all service usages in the ControlChannels comply with their definitions in the ToolAdapter metamodels. The correctness check in the current implementation checks whether the used services are defined in the ToolAdapter metamodels by using the name of the services. Future work on the implementation could also take the parameters of the services into account. Since the consistency between the metamodels for ToolAdapters and the TIL model has been checked at the model level, the consistency for the generated implementation can be ensured, as depicted in Figure 6.3 on p. 59.
6.5.2
Early Structural Design Verification of Tool Chain Design
In general, design verification checks if the design fulfills the specified requirements. The requirements for a tool chain are provided by the selection of tools, the product development process and additional information. Here the verification effort focuses on structural design verification, which is concerned with the extent to which the structure of the design of the tool chain is aligned to the structure required by the product development process. Early verification of tool chain design can detect possible misalignments between the structure of the product development process and the structure of the tool chain, when corrections are still relatively simple and cheap. By automating the early verification of tool chain design, it can be performed repeatedly with little effort, supporting the iterative refinement of tool chains. The work was guided by the following research question (RQ3.4): How can the alignment of a tool chain to a specific development process be determined? The alignment of the design provided by a TIL model is checked against the requirements provided by a SPEM model [136]. This alignment can be expressed by a mapping of a pattern of SPEM metaclasses to a pattern of TIL metaclasses. Even if the conceptual model has been constructed based on a SPEM model as described in Section 6.2, unintended changes might have been introduced by manual refinements. The verification produces a list of misalignments and a measurement indicating the degree of alignment between the tool chain and the product development process using precision/recall metrics [158], where a tool chain that is well-aligned to the process model has both a high degree of precision and a high degree of recall. This approach is described in more detail in Appended Paper H. Structural design verification is only one part of a comprehensive design verification, since other requirements besides the structure, such as the behavior and non-functional requirements, need to be checked as well. Even a comprehensive design verification is a complement – not a replacement – to testing and verification of the final implementation.
6.5.3
Early Cost Analysis of Tool Chain Design
When a tool chain is constructed, it is important to estimate both the cost of its development and the potential savings achievable when the tool chain is used. These
62 CHAPTER 6. SUPPORT FOR THE DEVELOPMENT OF TOOL CHAINS estimates can be used to compare alternative tool chain designs. The following research question (RQ3.5) guided the work: How can the development costs for tool chains and the cost savings of tool chains be estimated to allow or the comparison of tool chain designs? A cost-efficiency model for tool chains is proposed that quantifies and relates the development costs of tool chains to the cost savings expected from using the tool chain. The net value of a tool chain is given by the cost savings that occur for each product development project that uses the tool chain minus the development cost of the tool chain. netvalueT C = costsavings ∗ #uses − costT C
(6.1)
Equation 6.1 describes the cost-efficiency model and its main variables, which can be determined by three separate estimates. The variable costsavings describes the estimated cost savings for each development project that is executed with support of the tool chain. The achievable savings are dependent on the current tool integration situation and the feature set of the new tool chain. The variable #uses is an estimate of the number of product development projects that are executed by using this tool chain. The variable costT C is the estimated cost of tool chain development, which depends on the feature set of the tool chain. The Constructive Cost Model II (COCOMO II) [46, 47] is used to estimate the costsavings in the product development process of the embedded system and a second instance of COCOMO II is used to estimate the costT C of developing the tool chain. By relying on the estimation made by the COCOMO II model, the netvalueT C of the tool chain can be estimated. The calculation of the net value allows a break-even analysis to be made, and can support industrial users when comparing alternative tool chain designs. For such a decision, many aspects need to be considered and cost is only one of them, albeit an important one. The model can help to identify an appropriate feature set for the tool chain and find a balanced tradeoff between the cost savings and the cost of development. This approach is described in more detail in Appended Paper I.
6.6
Code Generation from TIL Models
To support the implementation phase of the tool chain development process, the TIL approach provides a code generator. For any correct TIL model the code generator synthesizes a corresponding implementation automatically. TIL is designed to be independent of any particular implementation technology and thus code for different implementation technologies could be generated for a TIL model. For the purpose of showing that code generation is feasible, a particular implementation technology was chosen as a target platform and a code generator was built for it. The work was guided by the following research questions (RQ3.6): How can the
6.6. CODE GENERATION FROM TIL MODELS
63
implementation of a tool chain be synthesized from a tool chain model? To what extent can the tool chain implementation be generated automatically? The generated implementation is realized using Java and the Service Component Architecture (SCA) [128], a component model for implementing and composing services. The implementation is compliant to the principles of OSLC [141], which stipulates technical conventions for tool integration. A tool chain described in TIL is realized as an SCA composite, which is a composition of SCA components. Each model element of a TIL model (except those of type ControlChannel) is realized as an SCA component with an implementation in Java. The realization of the SCA component and implementation depends on the properties of the model element and the language concept it is an instance of. The generator maps a TIL model to an implementation and is defined as a set of mapping rules, as depicted in Figure 6.4. Specific mapping rules for each TIL language concept have been developed as model-to-text transformations, which produce SCA components, Java code and corresponding OSLC descriptions.
Figure 6.4: Overview of the TIL generator for different language concepts and the generated artifacts. For a detailed description of the technical terms, see Appended Paper C. The generator creates a part of the implementation of the tool chain and thus reduces the amount of manual work necessary for implementation. Code generation can be completely automated for the language concepts ToolChain, User, Sequencer, Repository, ControlChannel, DataChannel and TraceChannel, as ex-
64 CHAPTER 6. SUPPORT FOR THE DEVELOPMENT OF TOOL CHAINS plained in Appended Paper C. Code generation for ToolAdapters is partially automated as described in Appended Paper D. In the following, we illustrate code generation for the two language concepts DataChannel and ToolAdapter. For the DataChannels, it is assumed that a model transformation description in any of the supported model transformation languages (ATL [96], Henshin [44], Acceleo MTL[134] or medini QVT-R [137]) is linked to the TIL model. The code generator for DataChannels creates the code for extracting the source model from the source ToolAdapter, invoking the transformation engine with the supplied model transformation description and the source model, and injecting the target model into the target ToolAdapter. The implementation of a ToolAdapter consists of an external and an internal part, as illustrated in Figure 6.5. The external part consists of the interface and code for providing the tool data and services which are compliant to OSLC conventions. The internal part of the ToolAdapter realizes the services by communicating with the integrated tool. The generator ensures that the implementation of the external part of the ToolAdapter complies with relevant OSLC conventions; the developer still needs to manually develop the internal part of the ToolAdapter, which is responsible for interacting with the tool via the interface technology of the tool, e.g. the API or file format. For specific interface technologies used by the tools, the communication with the tools can be supported by templates (e.g. for Eclipse, RMI or command line tools). In this way, even the complete implementation of the ToolAdapter can be generated for specific interface technologies, as explained in detail in Appended Paper D.
Figure 6.5: Implementation of a ToolAdapter
Chapter 7
Evaluation of TIL In this chapter, an evaluation of TIL and its automated development support is presented, which uses the criteria selected in Chapter 3 regarding the description of tool chains (Section 7.1) and the development of tool chains (Section 7.2). The details of the evaluation in the form of qualitatively and quantitatively assessed case studies can be found in the appended papers.
7.1 7.1.1
TIL for the Description of Tool Chains Coverage of Integration Concerns
The coverage of integration concerns of TIL according to the reference model described in Section 3.1.1 is assessed. As an architecture description language, TIL primarily describes the architectural concern of a tool chain. At the same time, there are dedicated links from the architectural description to more detailed descriptions addressing structural and semantic concerns. The structural concern is covered by ToolAdapter metamodels, which are referenced from the ToolAdapter concepts in a TIL model. The semantic concern is covered by semantics-preserving model transformations, which are referenced from the DataChannel concepts in a TIL model. For technical concerns, there is a need to differentiate between the concerns of integration technology and the technical concerns for accessing tool data. Technical concerns regarding integration technology, such as OSLC-compliance and service-oriented programming, are hidden from the tool chain architect and do not need to be explicitly described, these are handled by the code generator. Technical concerns regarding the access of tool data are described by source code in the internal part of the ToolAdapter. Even though TIL covers a range of concerns, it mainly focuses on the architectural concern. In the state of the art survey (see Section 4.3), OTIF is the only approach which recognizes the importance of the tool chain architecture. OTIF identifies high-level tool integration patterns, namely Integrated Datamodel and Process Flows [101]. In the Integrated Datamodel pattern, the integrated tools 65
66
CHAPTER 7. EVALUATION OF TIL
are connected to a central database, which uses a pivot metamodel as its schema. Bidirectional transformations are used to connect each tool to the schema of the database. In the Process Flow pattern, tools are connected to a bus, called ModelBackplane, using transformations. The transformations are executed according to a process description. In the following we evaluate, to which extent TIL can be used to model both patterns. Figure 7.1 expresses the pattern of the Integrated Datamodel [101] in TIL. A ToolAdapter is used to represent the Integrated Datamodel and the schema of the Integrated Datamodel is assigned as the ToolAdapter metamodel. If an additional tool is added to the tool chain, two DataChannels with attached model transformations are required for both import and export of data from the ToolAdapter of the integrated tool to the ToolAdapter of the Integrated Datamodel. Interestingly, the Integrated Datamodel pattern does not describe any control integration. Using TIL, an adequate control integration could be added to the pattern.
Figure 7.1: Modeling the Integrated Datamodel pattern [101] in TIL Figure 7.2 models the pattern for Process Flows [101] in TIL. A uni-directional DataChannel is used to represent the data-transfer in the Model Backplane of OTIF. In addition, a User and ControlChannels are used to represent control-integration.
Figure 7.2: Modeling the Process Flow pattern [101] in TIL
The architecture description language TIL is expressive enough to instantiate both patterns. With the language, it is furthermore possible to instantiate variants of the patterns, mix both design patterns or instantiate completely new patterns. TIL provides more flexibility at design-time and allows abstracting further from
7.1. TIL FOR THE DESCRIPTION OF TOOL CHAINS
67
implementation details than in the original description of the patterns [101]. For example, TIL simplifies the description of event registrations. Since TIL provides an architectural description, TIL can be compared to other architecture description languages. Can existing ADLs (see Section 4.1) be used to describe tool chains? Existing ADLs are compared and classified in several surveys [60, 72, 119], but some of the surveyed ADLs are not in use any more. Some ADLs are only used for communication, and additional support, such as code generation and analysis, is not available. Medvidovic [118] explains the short lifespan of some ADLs by their focus on technological aspects and their lack of consideration of the application domain, business context and development context. As a result, Medvidovic proposes domain-specific ADLs [118] focusing on a particular domain and business context. This finding is confirmed by another report on the use of ADLs in practice, which emphasizes that ADLs need to be aligned more closely with industrial software practice [167]. TIL addresses the identified shortcomings of generic ADLs by proposing a domain-specific architectural modeling language for tool chains. TIL considers the business context by addressing cost estimation for tool chain construction. TIL addresses the industrial software practice and development context by producing OSLC-compliant implementations. The application domain is considered by using domain analysis for selecting language concepts from the domain of tool integration. Thus the domain-specificity of TIL provides additional value compared to general purpose ADLs.
7.1.2
Coverage of Integration Aspects
By design, TIL covers a range of tool integration aspects. TIL represents each integration aspect with dedicated language concepts. Each language concept provides more detailed information in the form of properties. Some language concepts contain references to more detailed descriptions, which are expressed in other languages, such as model transformations and metamodels. • The data-transfer aspect is explicitly modeled by DataChannels, which are independent of the approach used for data conversion. The data conversion of the DataChannels could be realized by pivot metamodels or ontologies, but for practical reasons, we limit the realization of data conversions to model transformations. At the tool chain design-time, the model transformations are specified and linked to the TIL model, at tool chain run-time, the model transformations are executed. • The data-tracing aspect is explicitly modeled by TraceChannels. At designtime the possibility to create traces can be specified and limited to certain types of data elements exposed by the connected ToolAdapters. The trace instances can be created manually by the tool chain user at run-time of the tool chain. In addition, traces can be created automatically as by-products of model transformations.
68
CHAPTER 7. EVALUATION OF TIL • The control-invocation aspect is expressed by ControlChannels targeting a ToolAdapter, DataChannel or TraceChannel. • The control-notification aspect is expressed by ControlChannels targeting a User. • The process integration aspect is expressed by the ToolChain language concept, which is a composition of all other TIL concepts. The relationship between the process and the tool chain can be described both in an eventtriggered manner using ControlChannels and in a sequence-based manner using Sequencers. • The platform-distribution aspect is partly abstracted by the code generator, and partly expressed by the language concept DiscoveredToolAdapter. Remotely deployed ToolAdapters can be integrated into a new TIL model using the DiscoveredToolAdapter language concept and the discovery functionality described in Section 6.3. By mapping the TIL model to an implementation based on SCA (see Section 6.6), the code generator realizes the tool chain described by the TIL model as a distributed system. • The presentation integration aspect is expressed by all the ControlChannels that originate from Users, since these represent the interactions of the realworld users with the tool chain. Code generation produces a website as a common user interface, which allows the real-world user to interact with the tool chain, as specified by the User concept in TIL. Additional forms of presentation integration are part of future work (see Section 9.2.6).
7.1.3
Overview of the Tool Chain
TIL can provide an overview of the tool chain by representing tool chain at the architectural level of abstraction. At this level of abstraction, each tool integration aspect is represented by specific language concepts of TIL (see Table 5.2). In addition, two mechanisms are used: • Composition: To describe a tool chain in a TIL model, instances of the TIL language concepts are composed. The composition provides an overview of the tool chain and its various integration aspects. • Reference: Detailed descriptions for each of the integration aspects are referenced from the TIL model. References from a TIL model to detailed descriptions of structural concerns (i.e. metamodels) and semantic concerns (i.e. model transformations) provide an information model for the tool chain and provide an overview of the various detailed descriptions. By following the references, it is possible to “zoom in” on specific parts of the tool chain to obtain additional details.
7.2. TIL FOR THE DEVELOPMENT OF TOOL CHAINS
69
From the overview provided by a TIL model, specific views of the tool chain can be generated. An example is the implementation view, which is created by the code generator.
7.1.4
Domain-Specific Description
The language concepts of TIL are the outcome of a domain analysis for tool chains (see Section 5.2). TIL is thus a domain-specific description. A TIL model is independent of the implementation technology used in the tool chain; the source code is introduced by the code generator. TIL depends on model transformations as detailed descriptions of the DataChannel. However, no particular transformation engine is assumed, since several alternative model transformation engines are supported (see Section 6.6). Only the internal part of the ToolAdapters needs to be described using implementation technology.
7.1.5
Graphical Representation to Support Communication
TIL has a graphical concrete syntax and is supported by a graphical modeling environment. This graphical representation of the tool chain can be used to communicate with the various stakeholders of a tool chain (see Section 1.2.2). In Appended Paper C, a case study is used to determine if TIL is sufficiently expressive to describe a tool chain, which was provided by an industrial partner in the form of text and sketches. The need to express the features of this tool chain using the given structure of the modeling language forced us to be more precise in the description of the tool chain, for example regarding the directionality of the transformations or the desired granularity of the tool data. In contrast to a description of the tool chain in source code, the architecture description of the tool chain with its graphical representation can be used as a boundary object. Different stakeholders, such as the tool chain architect and tool chain users, can relate to the boundary object, which thus provides a common ground for communication. Other studies confirm that architecture description languages can be used as boundary objects [143].
7.2
TIL for the Development of Tool Chains
Due to its focus on tool chains, the development support provided by TIL can take the specific properties of tool chains into account. The development support for the various phases of tool chain development has been evaluated separately, as described in the appended papers, and briefly summarized here.
7.2.1
Specification Support: Tool Chain
A TIL model of a tool chain can be specified manually or with automated support. For the manual specification of the tool chain, the TIL Workbench provides a
70
CHAPTER 7. EVALUATION OF TIL
graphical modeling environment for tool chains. Automated support for specifying a conceptual TIL model is provided, based on a model of the development process described in SPEM. An existing SPEM model is used as a source for the structure of the tool chain and parts of the tool chain design can be deduced from the development process. The automated approach was applied in two case studies. The SPEM model of the first case-study was created according to the development process of an industrial partner. The SPEM model of the second case-study was taken from the official methodology description of AUTOSAR R3.2 (Automotive Open Software Architecture) [15]. In both case studies, a cohesive design of a tool chain could be created based on existing SPEM models, and the resulting tool chain model was actually aligned to the process. A detailed description of the evaluation is available in Appended Paper E.
7.2.2
Specification Support: Tool
The tool chain architect is supported in specifying the ToolAdapters manually and with automated support. For the manual specification of the ToolAdapter, the TIL Workbench is provided, which offers support for specifying the ToolAdapter metamodels. The TIL approach supports the tool chain architect in building the tool chain by facilities to include remotely deployed ToolAdapters into the tool chain. Remotely deployed ToolAdapters are discovered and the ToolAdapter metamodel is automatically reverse-engineered. This allows for a comprehensive model-based description of the tool chain that can be analyzed and for which proxies for the invocation can be synthesized. A case study is designed to discover an existing, remotely deployed OSLC-compliant ToolAdapter for MATLAB/Simulink. This involves reengineering the ToolAdapter metamodel of the discovered ToolAdapter, which allows for integration into a TIL model. The original metamodel of the MATLAB/Simulink ToolAdapter, which was used for specification and code generation, is compared to the discovered metamodel. The case study is described in Appended Paper F.
7.2.3
Specification Support: Other Tool Chain Parts
The TIL approach provides automated support for specifying data-transfer in tool chains. Automated support for data-transfer is typically limited to an automated execution of a manually specified data-transfer method. The TIL approach supports the tool chain architect in semi-automatically specifying model transformations as a part of the DataChannels. The algorithm for creating model transformations can be used when the metamodels of the ToolAdapter connected by the DataChannel are similar. In the general case, the creation of a semantics-preserving model transformation between two given metamodels is difficult, since an understanding of the semantics of the involved metamodels is required. However, the semantics of metamodels is
7.2. TIL FOR THE DEVELOPMENT OF TOOL CHAINS
71
usually not explicitly specified and thus not available for computation. A heuristic approach can compute a model transformation automatically, only if additional assumptions about the metamodels and their semantics are made. The presented heuristic makes the assumption that structurally similar elements and elements with similar names are also semantically related. This assumption is reasonable when tools with similar functionality need to be connected, e.g. for migration to a new version of the same tool, or for migration to a corresponding tool from another vendor. Another scenario is covered by this assumption as well: the ToolAdapter metamodel represents a view of the data in the tool and can be chosen by the tool chain architect, depending on the viewpoint taken (see Section 5.3). Thus the metamodels for several tools could be created from a common viewpoint, resulting in a similarity of the respective ToolAdapter metamodels. As a preparation for the evaluation, three different ToolAdapter metamodels were selected, which were partially similar. To evaluate the algorithm, these three metamodels were used to calculate model transformations for all six pairwise combinations. The generated mappings were compared to the respective manually created reference mapping using the precision/recall metric [158]. The generated transformation code for the DataChannels provides a precise mapping (93% precision on average), but does not cover all mappings required by the reference mapping (56% recall on average). Due to the conservative characteristic of the approach (high precision, average recall), the generated mapping can be manually extended into a comprehensive mapping. The generated artifacts can serve as a starting point for manual extensions and refinements of the generated tool chain implementation. A detailed description of the evaluation is available in Appended Paper G.
7.2.4
Analysis Support: Verification
The TIL approach provides automated support for checking the alignment between tool chain design and a model of the development process. The development process that is intended to be supported by the tool chain constitutes a part of the requirements of the tool chain. The alignment check can thus be used as a verification method for the tool chain design. The automated alignment check between a SPEM model and a TIL model is evaluated using a case study. The alignment check could detect deviations between a process and the supporting tool chain. A deviation should be regarded as a warning flag for tool chain design or process modeling. Expert judgment is needed to determine whether the cause of the inconsistency is in the process model or the TIL model. A detailed description of the evaluation is available in Appended Paper H.
7.2.5
Analysis Support: Non-Functional Properties
Several non-functional properties of tool chains are relevant for analysis, such as performance, safety and cost. We focus here on a method for estimating the cost
72
CHAPTER 7. EVALUATION OF TIL
of implementing the tool chain and an estimate of the cost savings that are made possible by the use of the tool chain. The resulting cost estimation can be used as a relative measure, to make tradeoff decisions and compare tool chains resulting from different design decisions, and not as an absolute measure. Work on non-functional properties of tool chains, especially on the economic implications of tool chains, is relevant for industrial practice but has not received much attention from academia [164]. Thus the work on cost estimation for tool chains focuses on the feasibility of automated support based on the TIL description, as described in Appended Paper I. An in-depth evaluation of the cost analysis and an exploration of analysis methods for additional non-functional properties is a part of future work.
7.2.6
Synthesis Support: Tool and Tool Chain
Synthesis support allows for the automated code generation of the tool chain implementation from a TIL model. The effectiveness of the code generator is determined by comparing the effort necessary for developing the tool chain with and without the TIL code generator using the case study described in Appended Paper C: (1) In previous work, parts of the studied tool chain have been implemented manually [8, 32, 39] and are extended to reflect the same case study; the result is referred to as the CM (completely manual) approach. (2) The implementation for the tool chain is generated from a TIL model and is referred to as the TIL implementation. Both qualitative and quantitative evaluations of the case study are used to compare the CM and TIL approaches. The qualitative evaluation shows that writing the manually added code of the TIL approach only requires making a subset of the design decisions necessary in the CM approach. The quantitative evaluation shows that the manually added code in TIL only makes up 20% of the code of a comparable, completely manually written tool chain with the CM approach. The qualitative and quantitative evaluations together provide evidence that the TIL approach can effectively support the implementation of the tool chain. Besides the representative case study described in Appended Paper C, we also studied extreme values of a critical part of the tool chain, the size of the ToolAdapter metamodel, as described in Appended Paper D. While a typical metamodel has roughly 10 metaclasses, the behavior of the generator was explored for a metamodel that has over 20 times the typical size (complete metamodel of UML1 ). From this extreme case, some insight for the usage of TIL was gained. While the technology of the automated code generation was scalable and even allowed for complete code generation of the ToolAdapter, the understandability of the large metamodels decreased. The native metamodels of tools, such as the UML metamodel in this case, are large and contain a wealth of information that is typically not relevant in a tool integration scenario. Often, smaller amounts of data are relevant for other tools, so the ToolAdapter metamodel can provide a simplified 1 http://www.eclipse.org/uml2
7.2. TIL FOR THE DEVELOPMENT OF TOOL CHAINS
73
view of the tool’s native metamodel. In addition, a tradeoff was identified between reusing an existing but large metamodel, and creating a new simplified metamodel: if the native metamodel is used, the ToolAdapter does not require any mapping and can be generated completely automatically. However, for the solution with the simplified metamodel, the internal part of the ToolAdapter needs to be developed manually to ensure the mapping between the native and the new metamodels.
Part III
Reflection
75
Chapter 8
Discussion In this chapter, we discuss the implications of the TIL approach from several alternative perspectives. We discuss the challenges of tool integration and realize that not only development tools need to be integrated into a tool chain, but also the integration technologies used for realizing tool chains (Section 8.1). We also discuss the properties of tool chains, for which a model-driven approach for tool chain development has advantages (Section 8.2). We explain that tools can have different roles in a tool chain and the implications for the development of ToolAdapters (Section 8.3). Finally, we discuss possible implications of this work for the industrial practice (Section 8.4).
8.1
Primary and Derivative Integration Challenge
Tool integration is motivated by the multitude of unconnected development tools and the need to use data and services across tool boundaries. We call this challenge the primary integration challenge. For solving the different aspects of the primary integration challenge, various integration technologies (tracing tools, transformation tools ...) are typically used. These technologies typically focus on one integration aspect and describe the integration limited to this aspect. A tool chain, however, typically needs to take care of several integration aspects and thus needs to use several integration technologies. The integration of integration technologies is called the derivative integration challenge. The primary and derivative integration challenges are illustrated in Figure 8.1. While the primary challenge of tool integration is defined as the activity of producing an environment of tools that supports the embedded systems development process, the derivative challenge of tool integration is the activity of producing an environment of integration technologies that supports the tool chain development process. The derivative integration challenge becomes relevant for larger tool chains, which require integration according to several integration aspects. For these inte77
78
CHAPTER 8. DISCUSSION
Figure 8.1: Illustrating the Primary and Derivative Integration Challenge
gration scenarios, an overview of the tool chain and its functionality is required. This overview of the tool chain is not sufficiently provided by the surveyed state of the art approaches for tool integration (see Section 4). Current integration technologies focus on solving the primary challenge, while the derivative challenge has not received much attention. To deal with the derivative integration challenge, both mechanisms to describe the derivative integration challenge for a particular tool chain and mechanisms to build a tool chain from separate integration technologies are needed, which each focus on a particular integration aspect or possibly on a subset of integration aspects. The goal for describing a tool chain is an overview of a tool chain realized with different integration technologies. The goal for building a tool chain is a coordination of the different integration technologies.
8.1.1
Description of Tool Chains
As a first step towards describing the derivative integration challenge, Wasserman [163] identifies five aspects of tool integration, namely data integration, control integration, process integration, platform integration and presentation integration. Each integration aspect is supported by different integration technologies (see Figure 8.1). All the different integration aspects are equally valid and contribute to the comprehensive description of a tool chain. The practice of viewing the tool integra-
8.1. PRIMARY AND DERIVATIVE INTEGRATION CHALLENGE
79
tion problem from different angles, resulting in separate views, has its advantages, but is also a challenge. The advantage is that dedicated languages and mechanisms for single integration aspects can be developed independently, each realizing a part of the overall tool chain; the challenge is that it leads to a fragmented description of tool chains. The fragmented description of tool chains in itself would not be a problem, but existing approaches neither provide an overview of the integration aspects nor an adequate way to compose a tool chain from the separate descriptions.
8.1.2
Building Tool Chains
When building tool chains, the challenge is the integration of the fragmented and specialized integration technologies. An example is a tool chain for which the data integration aspect is described by an ATL model transformation and the process integration aspect is described in BPEL. Even though both are domain-specific descriptions for the respective integration aspect, they cannot be readily combined without using source code1 .
8.1.3
TIL Approach to the Derivative Integration Challenge
The derivative integration challenge surfaces both when describing and when building tool chains. The TIL approach offers a possible solution to the derivative integration challenge. Since TIL describes tool chains at an architectural level of abstraction, the different integration aspects can be represented as language concepts. By including different language concepts into a TIL model, several integration aspects of a tool chain can be described and thus an overview of the integration aspects is provided. To illustrate this point, we use the example from the previous section: When a data-transfer is triggered by an event in a process, this can be expressed in the same TIL model by a ControlChannel ending in a DataChannel, as illustrated in Figure 7.2 on p. 66. The abstract syntax of TIL can be regarded as a pivot metamodel (see Section 4.2.1) for the domain of tool integration. The concepts of TIL serve as a reference for relating alternative integration technologies that cover the same integration aspect and also to relate integration technologies of different aspects among each other. To build a tool chain that covers several integration aspects, TIL provides a code generator that synthesizes the integration solution from a TIL model. The synthesized integration solution might involve several separate integration technologies. There can be one integration technology for each of the various aspects, or even several integration technologies for the same aspect. For example, several transformation engines are supported for realizing the data-transfer aspect. New integration technologies can be added to TIL by adding a specific generator. 1 A possible solution for realizing the composition is providing a wrapper for the ATL engine with an interface supported by the BPEL engine.
80
CHAPTER 8. DISCUSSION
8.1.4
Summary
Paradoxically, the state-of-the-art solutions for tool integration face an integration challenge: The solutions for the challenge of the primary tool integration among development tools for embedded systems, yield another integration challenge, the derivative integration challenge among the integration technologies. To improve tool integration, not only improved integration technologies for each integration aspect are needed. This allows only for local improvements. To improve tool integration as a whole and to build more powerful tool chains, also an improved integration of the various integration technologies is needed. TIL provides an approach to tackle the derivative integration challenge. By describing tool chains at a higher level of abstraction than each of the integration aspects does, an integrated description for several integration aspects becomes possible. The synthesis mechanism of TIL enables the construction of tool chains, which realize several integration aspects.
8.2
From Model-Based to Model-Driven Tool Integration
Model-based approaches explicitly represent the main artifact that is developed by a model. Accordingly, model-based tool integration approaches explicitly model the data of the integrated tools to realize data-transfer among tools (see Section 4.2.1). In contrast, the main artifact in the TIL approach is the tool chain; the tool chain is thus modeled explicitly, in addition to modeling the data of the integrated tools. Furthermore, the explicit model of the tool chain drives the development of a tool chain. Since an explicit model of the tool chain exists, several tasks in the tool chain development process can be supported. Thus TIL realizes what we call model-driven tool integration 2 . Model-driven tool integration has advantages, but also requires an upfront investment in the infrastructure, i.e., the definition of metamodels, transformations and development environments. In the following sections, the circumstances are characterized that justify a model-driven development approach for tool chains and the key features that the model-driven development approach for tool chains needs to expose.
8.2.1
Size of the Tool Chain
Tool chains may need to support many of the tools used for the embedded systems development process. In addition, several integration aspects may need to be taken into account, requiring the use of different integration technologies. These two factors contribute to the size of the tool chain. 2 Note,
that our use of the term requires that the tool chain development process is modeldriven. Others use the term for tool integration that supports a model-driven product development process e.g. of an embedded system.
8.2. FROM MODEL-BASED TO MODEL-DRIVEN TOOL INTEGRATION 81 The larger the size of the tool chain, the more leverage can be provided by an explicit model of the tool chain for improved management of the information about the tool chain. A structured description of the tool chain at an appropriate level of abstraction is a means to manage this information efficiently and reduce the accidental complexity. The larger the size of the tool chain, the more leverage can be provided by automated development support for the tool chain. Especially for larger tool chains, synthesis is preferably automated. Early analysis of the tool chain can help to ensure that the right tool chain is developed, before effort is wasted on implementing a tool chain that cannot fulfill the requirements.
8.2.2
Extensive Use of Integration Conventions
The goal of many tool integration initiatives is to create standards and conventions for data and control integration on a technological level (see Section 3.1.1). An example is the OSLC initiative, which proposes the use of RDF for representing tool data and the use of RESTful services for representing tool services. This complicates the development of the components, since they need to be realized using predefined technology, libraries, protocols and formats. This contributes to an increase in development effort, necessary training in the technologies and potential bugs in the implementation of the tool chain. With a model-driven tool integration approach, implementation technology and conventions are hidden from the tool chain architect. The explicit tool chain model abstracts from implementation details and provides a technology-independent representation of the tool chain reducing the perceived complexity of the problem. The generator takes care of the synthesis of an implementation of the tool chain that is compliant with industrially relevant conventions for integration. The generator only needs to be written once (for each supported implementation technology) and can then be reused for building many tool chains. The more tool chains are built with the generator, the sooner the additional effort for generator development is amortized.
8.2.3
Tailoring
Seamless tool chains with a process scope are ideally built in such a way that they accommodate the development process and the set of tools used. Each company uses a different selection of COTS development tools and even some company-specific tools that are developed in-house. Each company uses a development process which is customized to the needs and circumstances. One-size-fits-all tool chains do not accommodate the requirements of tool chains with a process scope. If tool chains are built from predefined components, some tools used by the company might not be available, such as company-specific tools, leading to tool chains that do not support the complete development process. To support tool chains with a process scope, a model-driven tool integration approach offers the possibility to build tool
82
CHAPTER 8. DISCUSSION
chains that are tailored to specific needs, by describing tool chains at a high level of abstraction using a graphical modeling language. The generator supports the efficient construction of a tool chain implementation from the description of the tool chain. Many European projects (iFEST [2], CESAR [1], MBAT [3]) develop OSLCcompliant libraries of tool adapters, however, there is less emphasis on support for tailoring and composing these components into a customized tool chain. The TIL approach supports specifying the whole tool chain and its components according to custom requirements and is thus complementary to the component-based approach. A combination of both approaches is possible, using the discovery approach described in Section 6.3.
8.2.4
Changing Requirements
A tool chain may evolve over time, as new tools are included into the tool chain, which may require changing existing parts of the tool chain. A particular situation with changing requirements and the subsequent need for flexibility of the tool chain, is the prototyping of tool chains. Prototyping is characterized by frequent cycles of specification, synthesis and testing. The model-driven approach for tool integration makes the most important design decisions concerning the tool chains and its parts explicit and expresses them in the form of a TIL model and the ToolAdapter metamodel. Using an explicit representation of the tool chain, the specification can be tailored to fit the requirements of the tool chain and can simplify the process of changing and evolving the tool chain. An important factor for dealing with changing requirements is the support for the synthesis of the implementation. The synthesis mechanism assures the consistency between the design and the implementation. Ideally, the synthesis should support iterative development, i.e. manually added code for the internal parts of the ToolAdapter is preserved, when the implementation is regenerated after the tool chain model is updated. TIL supports this feature by realizing the code generation with the concept of protected regions for the user-defined source code that will not be overwritten. Another important factor for dealing with changing requirements, is support for checking that the tool chain implementation fulfills the requirements. TIL can be used to check the consistency between the structural requirements and the design. If the tool chain changes during prototyping, the changed tool chain needs to be communicated to its stakeholders. A model of the tool chain – as provided by TIL – not only documents and communicates the tool chain graphically, but the model also describes how the tool chain is used.
8.2.5
Summary
Model-driven tool integration can provide advantageous support especially for the case, when tool chains are larger in size, when the use of integration conven-
8.3. ROLES OF TOOLS IN THE TOOL CHAIN
83
tions complicates tool chain development, when tool chains need to be tailored or when changing requirements need to be accommodated, e.g., for prototyping of tool chains.
8.3
Roles of Tools in the Tool Chain
A development tool can be used in different ways, and depending on its usage, the tool can take on different roles in the development process or tool chain. A ToolAdapter captures the role of the tool and its ToolAdapter metamodel describes only the data and services, which is relevant for this role. Thus, there can be several ToolAdapters for each tool. TIL supports the creation of these role-dependent ToolAdapters by synthesis methods. The ToolAdapter model represents the tool data according to the ToolAdapter metamodel. The mapping from the tool data to the ToolAdapter model is not necessarily a projection, but may include an interpretation of the tool data. This allows us to build more specific ToolAdapters. Let us consider the example of a word processing tool, which may in industrial practice take the role of a requirements engineering tool. Without the role-specific interpretation, a ToolAdapter for a word processing tool can only consider the formatting of the document. With the interpretation, a ToolAdapter for a word processing tool may interpret certain text passages of the document as requirements. Not only can tools take on various roles in a tool chain, but also several tools can take on the same role, which makes them replaceable with respect to that role. Since the ToolAdapter metamodel only depends on the role – not on the specific tool – the impact of tool replacement can be contained, and the rest of the tool chain remains unaffected by the replacement. As a consequence of using rolespecific ToolAdapters, tool replacement in a tool chain can be simplified. Support for the replacement of tools is an issue in industry, since the ability to replace a tool ensures the independence of a specific tool and tool vendor.
8.4
Potential Implications for Industrial Practice
The TIL approach offers new opportunities for the industrial practice of embedded systems development. TIL enables embedded systems developers to create tailored tool chains for their different projects instead of relying on one-size-fits-all tool chains. Since tool chains can be tailored to the development process using TIL, the tool chain can better support the embedded systems developers, in their tasks along the development process. Since the TIL approach allows building tool chains with reduced effort, i.e., relatively fast and at low cost, companies may be in the position to build several tool chains. Each tool chain can take the specific needs of each software development project into account, when creating a new tool chain. Since much of the integration
84
CHAPTER 8. DISCUSSION
technology is hidden by the generator and thus the necessary knowledge of integration technologies is reduced, embedded systems developers may be able to build tool chains themselves, instead of buying tool chains from external consultants. At the same time, the tool chain implementation still follows integration conventions and can be reused. Embedded systems developers themselves best know the requirements for a tool chain that can support their work. If embedded systems developers are closely involved in the tool chain development process, and are not only tool chain users, but also become tool chain architects, this is likely to result in an improved alignment of the tool chain to the industrial practice. Due to this alignment, tailored tool chains may have the potential to increase developer productivity and speed up the development process of the product. Another concern for industry is the dependence on development tools form a particular tool vendor, even though a better competing tool from another vendor is available. This phenomenon is common among competing technologies and is known as lock-in [9]. TIL reduces the lock-in by role-specific ToolAdapters, which simplify tool replacement with competing tools, as described in Section 8.3.
Chapter 9
Conclusion In this chapter, we describe the contribution of the thesis by reviewing the research questions (Section 9.1) and outline possibilities for future work (Section 9.2). This work contributes to the area of tool integration. Tool chains for embedded systems, and specifically their development have been studied. Tool chains are needed for handling the heterogeneity of industrial development tools for embedded systems. In practice, the development of tool chains, which are tailored to the needs of a specific company, is still a code-centric and time-consuming effort. State-ofthe-art model-based tool integration approaches create models of the data of the integrated tools, but not an architectural model of the tool chain that captures all relevant integration aspects. In this work, possibilities for modeling a tool chain as a whole are studied and the resulting implications for tool chain development are evaluated. To model a tool chain holistically and systematically, a domain-specific modeling language for tool chains is created. It describes a tool chain at an architectural level of abstraction, provides concepts from the domain of tool integration, covers all relevant integration aspects, and is independent of particular implementation technology. A graphical representation of the tool chain model can be used for documentation and communication. The modeling language is the cornerstone for semi-automated development support for the specification, refinement, analysis, and in particular the synthesis of a tool chain. According to the model-driven development terminology, we call this approach model-driven tool integration, since an explicit model of the tool chain drives the development.
9.1
Review of Research Questions
The work has been guided by the overall research questions RQ1-3 presented in Section 2.2. Based on the results presented in Chapters 5 and 6 and the evaluation in Chapter 7, the research questions can be answered as follows. 85
86
CHAPTER 9. CONCLUSION
RQ1: How can the development of tool chains be systematized and automated? Instead of developing the tool chain in an ad-hoc manner, the tool chain development can be systematized by regarding the tool chain as a product that is developed according to a model-driven development process. This allows us to systematize the development by both product models describing the developed tool chains and a process model describing the tool chain development process. To provide the means for a systematic description of tool chains as product models, a modeling language for tool chains is proposed. To describe the tool chain and its parts explicitly, the modeling language is domain-specific and its language concepts are from the domain of tool integration. To describe the tool chain holistically, with consideration of all integration aspects and to reduce the accidental complexity of the technical tool integration concerns, the language is at the architectural level of abstraction. The modeling language also serves as an enabler for a structured tool chain development process and semi-automated development support for various tasks in the process. The development process can be structured into distinct phases: specifying a conceptual design from the requirements; refining the conceptual design into a detailed design; analyzing the design and code generation from the design. For each phase, specific tasks need to be performed with the product model and semi-automated support for these tasks is provided. The support for describing and developing tool chains is especially relevant for those tool chains which are larger, are tailored to specific tools or processes, need to accommodate changing requirements, or comply to implementation conventions. Tool chains for embedded systems development typically exhibit all or several of these properties, so the provided support is applicable in this context, as demonstrated in several case studies. RQ2: How can tool chains be described systematically? Tool chains can be described systematically by a modeling language that is domainspecific and at an architectural level of abstraction. The language is domain-specific to reduce the gap between the description and the terms used in the domain of tool integration and to cover all relevant integration aspects and concerns. The architectural level of abstraction is appropriate, since it allows for an overview of the tool chain by expressing the most important design decisions for building tool chains. Describing tool chains as domain-specific models on the architectural level of abstraction reduces the accidental complexity and allows focusing on the specification and analysis of the overall tool chain design. Potential language concepts for the domain-specific modeling language are identified by an analysis of the tool integration domain. The broad scope of the tool integration domain is broken down into several integration aspects. Each integration aspect contributes with domain concepts for describing tool chains. Since the
9.1. REVIEW OF RESEARCH QUESTIONS
87
language concepts originate from different integration aspects, a holistic description of the tool chain can be achieved. By mapping the domain concepts to the basic concepts of architecture descriptions, the languages can be seen as an architecture description language for tool chains. The architecture of a tool chain can be systematically described with the language by composing instances of the language concepts. The domain-specific architectural modeling language TIL is built according to these principles. TIL is applied in several case studies for systematically describing tool chains. RQ3: To what extent can the development of tool chains be supported by automated methods? The domain-specific architectural modeling language provides the means for describing tool chains explicitly and systematically as models. A model-driven approach for the construction of tool chains can make use of the tool chain model during conceptual design, detailed design, analysis and implementation. For each of these phases, possibilities for automated development support are proposed and evaluated. In the conceptual design phase, the overall architecture of the tool chain is determined and described in a conceptual tool chain model. A model of the embedded systems development process that needs to be supported by the tool chain may already be available and describe some of the requirements of the tool chain. Automated support for specifying a conceptual tool chain model can reuse relevant, existing information from models of the development process. In the detailed design phase, the conceptual tool chain model is refined by detailed specifications of the data and services exposed by each tool and rules for data conversions. When reusing existing, remotely deployed tool chain parts to build a new tool chain, the specifications of the exposed data and services can be automatically re-engineered allowing for consistency checking and early analysis of the tool chain. The creation of prototypical data conversion rules can be semiautomated by a heuristic if the connected tools are similar, which is relevant for scenarios such as data migration or tool replacement. Early automated analysis can help to ensure that the right kind of tool chain is built and thus prevent wasting effort on tool chains that do not fulfill the basic functional and non-functional requirements. A tool chain model can be automatically analyzed for various properties. The alignment of a tool chain model with a process model can be checked automatically; the correctness of a tool chain model can be checked; and to compare alternative tool chains, the development cost of the tool chain can be estimated and put in relation to the expected cost savings. Code generation can transform a holistic tool chain model that covers several integration aspects into an implementation, which is compliant with integration conventions. The code generation is generally semi-automated for the realization of tool adapters, but can be fully automated in certain cases. The code generation
88
CHAPTER 9. CONCLUSION
is fully automated for the rest of the tool chain. Code generation thus reduces the effort for implementing the tool chain. To show the feasibility of the automated support for tool chain development, the above described methods for the different phases of tool chain development have been implemented and applied in case studies. The implementation is based on the systematic description of tool chains provided by the modeling language TIL.
9.2
Future Work
The presented results provide opportunities for continuing this work. Existing work can be extended by deepening unexplored paths spotted along the way and by reducing some of the delimitations (see Section 1.4). Some of the listed future work has already started.
9.2.1
Synthesis for Different Integration Frameworks
By design, TIL describes a tool chain independently of a particular implementation technology or tool integration framework. Thus the TIL approach could be used as a platform for generating tool chain implementations for different integration technologies. In this work a code generator for TIL is presented, which produces OSLC-compliant tool chains. Future work is needed to evaluate whether alternative code generator for TIL can be created for generating an implementation that uses an existing tool integration framework, such as ModelBus [85] or Jazz [78]. Generators targeting different integration frameworks might share commonalities, which can be reused. The reuse among generator parts can be described using variability management of the code generators.
9.2.2
Evolution of Tool Chains and Integrated Tools
Tool chains need to co-evolve with the tools they integrate. Such an evolution can occur if a new version of an integrated tool becomes available or if an integrated tool needs to be replaced by a tool with similar functionality. These changes may affect the internal part of the ToolAdapter but not necessarily require a change of the ToolAdapter metamodel, so the rest of the tool chains is not affected by the change. If the change requires an adaptation of the ToolAdapter metamodel, additional support for managing this change by migrating the tool data to the new tool may become necessary. Initial experiences with automatically migrating data between two similar tools have been explored, using a variant of the heuristic approach for generating model transformation described in Appended Paper G. Future work needs to extend and evaluate the approach and provide case studies for different migration scenarios.
9.2. FUTURE WORK
9.2.3
89
Formal Semantics and Simulation
Initial work on formalizing the behavioral semantics of TIL has been performed [31] by defining a mapping from TIL models to networks of finite state machines (FSMs). The mapping is implemented as a model transformation, which can be used for the semantic anchoring [57] of TIL. The tool chain architect may want to explore the dynamic behavior of the tool chain early in the development process, without code generation and deployment. Simulation can be used for early validation of the behavior of a tool chain described by a TIL model. The mapping from TIL to FSMs can be used for producing a simulation model of the behavior of a TIL model. UPPAAL [111] provides a graphical environment for creating and simulating networks of finite state machines, so the simulation model resulting from the model transformation can be interpreted by the UPPAAL simulator for step-by-step analysis of the tool chain behavior and to produce execution traces. Initial work on the simulation of tool chain behavior has been described [31].
9.2.4
Analysis of Additional Properties and Tradeoffs
Work on non-functional properties of tool chains, especially on the economic implications, has not received much attention from academia [164]. Section 6.5.3 explored the feasibility of analyzing the development cost and the cost savings achievable by tool chains based on the TIL model. The work on cost estimation for tool chains has an explorative character, focusing on the feasibility of automated support based on the TIL description. An in-depth evaluation of the results is part of future work. Analysis of additional properties, such as scalability or performance, can complement the analysis support for tool chains. To analyze these properties, additional information is required besides the structural information available in the TIL model. This information can be provided by extending TIL with annotations for the analyzed property. Further work is needed to choose appropriate analysis methods for these properties and evaluate them. The analysis results can be used to make well-informed design choices. When there are several analysis methods available that target different properties, their analysis results need to be combined. Future work needs to investigate the trade-offs between different tool chain properties.
9.2.5
Qualification of Tool Chains
If tool chains are used to develop a safety critical system, the tools and the tool chain might need to be qualified according to safety regulations. Due to the safetycriticality of embedded systems, safety standards are in place, such as IEC 61508 [61], ISO26262 [77] for the automotive industry and DO-178C/DO-330 [129, 130] for the aviation industry. These standards put strong demands on the development
90
CHAPTER 9. CONCLUSION
process regarding certification of the embedded system, and require qualification of the development tools. In addition, tool chains might need to be further qualified [13] by detecting potential hazards. An initial approach [12] for the qualification of tool chains with TIL has been proposed. Future work needs to investigate to what extent the hazards related to tool integration can be identified from an explicit model of a tool chain expressed in TIL.
9.2.6
Enhanced Support for Presentation Integration
Current support for modeling presentation integration with TIL focuses on the user interface (UI) for the complete tool chain. Future work needs to evaluate different strategies for presentation integration based on the user interfaces of existing tools. This might require the introduction of new language concepts and extensions to the code generator. One strategy for presentation integration is the replacement of existing tool UIs with a unified UI for all involved tools. An example for this strategy are the OSLC-compliant concepts for Delegated User Interfaces [141], which are web pages that provide a simplified view of the data and services of the tool. While a novice user might appreciate the simplified and unified UI, an expert might be disturbed by the change to the accustomed environment. Another strategy for presentation integration is the extension of existing UIs. This is, however, only possible for tools that allow an extension of their UI. For the scope of web applications, this strategy has been realized by overlays through browser-based plugins by CORSET [68]. Since the ToolAdapters created by TIL are web application for desktop tools, synergies can be achieved by combining both approaches.
9.2.7
Enhanced Support for Data Management
Data management is currently either supported by a repository that is part of a development tool, such as offered by DOORS 1 , or by using an SCM system that is external to the tool, such as Subversion 2 . In an industrial context, tool data needs to be handled by software configuration management (SCM) systems or product lifecycle management (PLM) systems for mechanical products. In the future we would like to combine the tool integration provided by TIL with these approaches for data management. TIL currently offers the Repository language concept, realizes data storage and versioning functionality. This language concept of TIL could be extended to reflect more functionality of data management systems. This would allow the tool chain architect to explicitly model the chosen strategy for data management in the TIL model. Alternatively, data management could become a part of each ToolAdapter. This alternative builds on the idea that the tool data is managed and owned by the 1 http://www.ibm.com/software/awdtools/doors 2 http://subversion.tigris.org
9.2. FUTURE WORK
91
ToolAdapter. Thus data management would be transparent in the TIL model, and the code for realizing data management for each tool is created by the code generator as part of the implementation of each ToolAdapter. As this example shows, there is a tradeoff between making concepts for tool integration explicit in the TIL model by dedicated language concepts and hiding the tool chain functionality by introducing the functionality in the generator. Future work needs to evaluate these – and potentially additional – approaches for both modeling and using data management in tool chains, including the implications for other parts of the tool chain, such as data-tracing and data-transfer.
9.2.8
Extended Evaluation of TIL
This work on tool integration was performed and evaluated in the context of embedded systems development, which has an extensive demand for tool integration, as the heterogeneity of the system requires a wide range of different development tools (see Section 1.2). Other areas of software and system development also face the challenge of tool integration to a certain extent. The work presented here may thus be applicable in the wider context of software and system development. Future work needs to evaluate the applicability and suitability of TIL in these new areas. As a complement to the evaluation through case studies, a controlled experiment could be designed to compare the TIL approach to other approaches for developing tool chains, such as the completely manual (CM) implementation approach. Of interest is a comparison regarding the time necessary for tool chain development or the quality of the tool chain implementation. To implement such a controlled experiment, a number of engineers would be divided into two groups, where one group uses TIL, while the control group uses an alternative approach. On the one hand, using a controlled experiment has the advantage that many relevant variables can be controlled. On the other hand, controlled experiments would need to take the tool chain into a laboratory setting and drastically limit the size of the developed tool chain, which conflicts with the need for a more realistic tool chain. In addition, there are a number of practical limitations, such as the availability of a sufficiently large number of engineers and their time commitment. Future work may thus include a controlled experiment for the development of a small tool chain with students as subjects.
Bibliography [1]
CESAR Project: Cost-Efficient Methods and Processes for Safety Relevant Embedded Systems. [Online]. Available: http://www.cesarproject.eu
[2]
iFEST Project: Industrial Framework for Embedded Systems Tools. [Online]. Available: http://www.artemis-ifest.eu
[3]
MBAT Project: Combined Model-based Analysis and Testing of Embedded Systems. [Online]. Available: http://www.mbat-artemis.eu
[4]
T. Adler, J. A. Black, and J. P. Loveland, “Complex Systems: Boundary-Spanning Training Techniques,” Journal of European Industrial Training, vol. 27, pp. 111–124, 2004.
[5]
F. Altheide, “An architecture for a sustainable tool integration,” in Workshop on Tool integration in system development, D¨ orr and Schurr, Eds., 2003.
[6]
C. Amelunxen, F. Klar, A. K¨ onigs, T. R¨ otschke, and A. Sch¨ urr, “Metamodel-based tool integration with MOFLON,” in ICSE ’08, 2008, pp. 807–810. [Online]. Available: http://dx.doi.org/10.1145/1368088.1368206
[7]
E. Armengaud, M. Biehl, Q. Bourrouilh, M. Breunig, S. Farfeleder, C. Hein, M. Oertel, A. Wallner, and M. Zoier, “Integrated tool chain for improving traceability during the development of automotive systems,” in ERTS2 2012 — Embedded Real Time Software and Systems, Feb. 2012.
[8]
E. Armengaud, M. Zoier, A. Baumgart, M. Biehl, D. Chen, G. Griessnig, C. Hein, T. Ritter, and R. T. Kolagari, “Model-based Toolchain for the Efficient Development of Safety-Relevant Automotive Embedded Systems,” in SAE 2011 World Congress & Exhibition, Apr. 2011. [Online]. Available: http://papers.sae.org/2011-01-0056
[9]
W. B. Arthur, “Competing Technologies, Increasing Returns, and Lock-In by Historical Events,” The Economic Journal, vol. 99, no. 394, pp. 116–131, Mar. 1989. [Online]. Available: http://dx.doi.org/10.2307/2234208
[10]
F. Asplund, M. Biehl, J. El-khoury, D. Frede, and M. T¨ orngren, “The Impact of Tool Chain Qualification on ISO 26262,” in SAE 2012 World Congress & Exhibition, Apr. 2012. [Online]. Available: http://papers.sae.org/2012-01-0026
[11]
F. Asplund, M. Biehl, J. El-Khoury, and M. T¨ orngren, “Tool integration beyond Wasserman,” in First Workshop on Integration of Information Systems Engineering Tools (INISET 2011), Jun. 2011.
93
94
BIBLIOGRAPHY
[12]
F. Asplund, M. Biehl, and F. Loiret, “Towards the Automated Qualification of Tool Chain Design,” in Safecomp Workshops 2012, Sep. 2012.
[13]
F. Asplund, J. El-khoury, and M. T¨ orngren, “Qualifying Software Tools, a Systems Approach,” in Proceedings of SAFECOMP 2012, Sep. 2012.
[14]
C. Atkinson and T. K¨ uhne, “Reducing accidental complexity in domain models,” Software & Systems Modeling, vol. 7, pp. 345–359, 2008. [Online]. Available: http://dx.doi.org/10.1007/s10270-007-0061-0
[15]
AUTOSAR Consortium. (2011, Apr.) Automotive open software architecture (AUTOSAR) 3.2. [Online]. Available: http://autosar.org/
[16]
D. Balasubramanian, A. Narayanan, C. Van, and G. Karsai, “The Graph Rewriting and Transformation Language: GReAT,” in Proceedings of the Third International Workshop on Graph Based Tools, 2006.
[17]
N. Barnickel and M. Fluegge, “Towards a conceptual framework for semantic interoperability in service oriented architectures,” in Proceedings of the 1st International Conference on Intelligent Semantic Web-Services and Applications, ser. ISWSA ’10. New York, NY, USA: ACM, 2010. [Online]. Available: http://dx.doi.org/10.1145/1874590.1874602
[18]
V. Basili, G. Caldiera, and D. H. Rombach, “The goal question metric approach,” in Encyclopedia of Software Engineering, J. Marciniak, Ed. Wiley, 1994. [Online]. Available: https: //docweb.lrz-muenchen.de/cgi-bin/doc/nph-webdoc.cgi/000110A/http/scholar. google.de/scholar=3fhl=3dde&lr=3d&cluster=3d4068380033007143449
[19]
A. 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), Jun. 2010.
[20]
M. Bell, Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture. Wiley, Feb. 2008. [Online]. Available: http://www.worldcat.org/ isbn/0470141115
[21]
T. Berners-Lee, “Linked Data,” W3C, Tech. Rep., Jul. 2006. [Online]. Available: http://www.w3.org/DesignIssues/LinkedData
[22]
P. Bernstein, “Applying model management to classical meta data problems,” 2003. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10. 1.1.12.772
[23]
P. A. Bernstein and S. Melnik, “Model management 2.0: manipulating richer mappings,” in SIGMOD ’07: Proceedings of the 2007 ACM SIGMOD international conference on Management of data. New York, NY, USA: ACM, 2007, pp. 1–12.
[24]
J. B´ezivin and O. Gerb´e, “Towards a Precise Definition of the OMG/MDA Framework,” in ASE ’01: Proceedings of the 16th IEEE international conference on Automated software engineering. Washington, DC, USA: IEEE Computer Society, 2001, p. 273.
BIBLIOGRAPHY
95
[25]
M. Biehl, “Documenting Stepwise Model Refinement using Executable Design Decisions,” in Proceedings of the International Workshop on Models and Evolution (ME 2010), Oct. 2010.
[26]
——, “Literature Study on Model Transformations,” Royal Institute of Technology, Tech. Rep. ISRN/KTH/MMK/R-10/07-SE, Jul. 2010.
[27]
——, Supporting Model Evolution in Model-Driven Development of Automotive Embedded Systems, ser. Trita ISRN/KTH/MMK/R-10/08-SE. Stockholm, Sweden: Royal Institute of Technology, Nov. 2010. [Online]. Available: http://www.md.kth.se/∼biehl/files/papers/licavhandling.pdf
[28]
——, “Analysis of Tool Chains,” Royal Institute of Technology (KTH), Tech. Rep. ISRN/KTH/MMK/R-11/17-SE, Nov. 2011. [Online]. Available: http://www1.md.kth.se/∼biehl/files/papers/analysis.pdf
[29]
——, “Tool Integration Language,” Royal Institute of Technology (KTH), Tech. Rep. ISRN/KTH/MMK/R-11/16-SE, Sep. 2011. [Online]. Available: http://www1.md.kth.se/∼biehl/files/papers/til.pdf
[30]
——, “Early Automated Verification of Tool Chain Design,” in Proceedings of the International Conference on Computational Science (ICCSA2012), Jun. 2012.
[31]
——, “Semantic Anchoring of TIL,” Royal Institute of Technology, Tech. Rep. ISRN/KTH/MMK/R-12/19-SE, Oct. 2012. [Online]. Available: http: //www1.md.kth.se/∼biehl/files/papers/semantics.pdf
[32]
M. Biehl, C. DeJiu, and M. T¨ orngren, “Integrating Safety Analysis into the Modelbased Development Toolchain of Automotive Embedded Systems,” in Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), Apr. 2010, pp. 125+.
[33]
M. Biehl, J. El-Khoury, F. Loiret, and M. T¨ orngren, “A Domain Specific Language for Generating Tool Integration Solutions,” in 4th Workshop on Model-Driven Tool & Process Integration (MDTPI2011) at the European Conference on Modelling Foundations and Applications (ECMFA 2011), Jun. 2011. [Online]. Available: http://www1.md.kth.se/∼biehl/files/papers/mdtpi2011.pdf
[34]
——, “On the modeling and generation of service-oriented tool chains,” Journal of Software and Systems Modeling, vol. 0275, Sep. 2012. [Online]. Available: http://dx.doi.org/10.1007/s10270-012-0275-7
[35]
M. Biehl, J. El-Khoury, and M. T¨ orngren, “High-Level Specification and Code Generation for Service-Oriented Tool Adapters,” in Proceedings of the International Conference on Computational Science (ICCSA2012), Jun. 2012.
[36]
M. Biehl, W. Gu, and F. Loiret, “Model-based Service Discovery and Orchestration for OSLC Services in Tool Chains,” in International Conference on Web Engineering (ICWE2012), Jul. 2012.
[37]
M. Biehl, J. Hong, and F. Loiret, “Automated Construction of Data Integration Solutions for Tool Chains,” in Seventh International Conference on Software Engineering Advances (ICSEA2012), Nov. 2012.
96
BIBLIOGRAPHY
[38]
M. Biehl and W. L¨ owe, “Automated Architecture Consistency Checking for Model Driven Software Development,” in Proceedings of the Fifth International Conference on the Quality of Software Architectures (QoSA 2009), Jun. 2009, pp. 36–51. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02351-4 3
[39]
M. Biehl, C.-J. Sj¨ ostedt, and M. 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), Jun. 2010.
[40]
M. Biehl and M. T¨ orngren, “An Executable Design Decision Representation using Model Transformations,” in 36th EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2010), Sep. 2010.
[41]
——, “A Cost-Efficiency Model for Tool Chains,” in International Conference on Global Software Engineering Workshops (ICGSE2012), Aug. 2012.
[42]
——, “An Estimation Model for the Savings Achievable by Tool Chains,” in 2012 IEEE 36th International Conference on Computer Software and Applications, Jul. 2012.
[43]
——, “Constructing Tool Chains based on SPEM Process Models,” in Seventh International Conference on Software Engineering Advances (ICSEA2012), Nov. 2012.
[44]
E. Biermann, S. Jurack, C. Krause, T. Arendt, and G. Taentzer, “Henshin: Advanced concepts and tools for in-place EMF model transformations,” in MODELS 2010, Oct. 2010. [Online]. Available: http://www.eclipse.org/modeling/ emft/henshin
[45]
L. T. M. Blessing and A. Chakrabarti, DRM, a Design Research Methodology, 1st ed. Springer, Jun. 2009. [Online]. Available: http://www.worldcat.org/isbn/1848825862
[46]
B. W. Boehm, Software Engineering Economics, 1st ed. Prentice Hall, Nov. 1981. [Online]. Available: http://www.worldcat.org/isbn/0138221227
[47]
B. W. Boehm, C. Abts, A. W. Brown, S. Chulani, B. K. Clark, E. Horowitz, R. Madachy, D. J. Reifer, and B. Steece, Software Cost Estimation with Cocomo II. Prentice Hall, Aug. 2000. [Online]. Available: http://www.worldcat.org/isbn/0130266922
[48]
D. A. Bradley, “The what, why and how of mechatronics,” Engineering Science and Education Journal, vol. 6, no. 2, pp. 81+, 1997. [Online]. Available: http://dx.doi.org/10.1049/esej:19970210
[49]
T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and F. Yergeau, “Extensible markup language (XML) 1.0 (fifth edition),” W3C, Tech. Rep., Nov. 2008. [Online]. Available: http://www.w3.org/TR/REC-xml
[50]
F. P. Brooks, “No Silver Bullet Essence and Accidents of Software Engineering,” Computer, vol. 20, no. 4, pp. 10–19, Apr. 1987. [Online]. Available: http://dx.doi.org/10.1109/MC.1987.1663532
[51]
A. W. Brown, D. J. Carney, E. J. Morris, D. B. Smith, and P. F. Zarrella, Principles of CASE tool integration. New York, NY, USA: Oxford University Press, Inc., 1994. [Online]. Available: http://portal.acm.org/citation.cfm?id=199265
BIBLIOGRAPHY
97
[52]
A. W. Brown and M. H. Penedo, “An annotated bibliography on integration in software engineering environments,” SIGSOFT Softw. Eng. Notes, vol. 17, no. 3, pp. 47–55, 1992. [Online]. Available: http://dx.doi.org/10.1145/140938.140944
[53]
M. Broy, M. Feilkas, M. Herrmannsdoerfer, S. Merenda, and D. Ratiu, “Seamless Model-Based Development: From Isolated Tools to Integrated Model Engineering Environments,” Proceedings of the IEEE, vol. 98, no. 4, pp. 526–545, Apr. 2010. [Online]. Available: http://dx.doi.org/10.1109/JPROC.2009.2037771
[54]
H. Bruneli`ere, J. Cabot, C. Clasen, F. Jouault, and J. B´ezivin, “Towards Model Driven Tool Interoperability: Bridging Eclipse and Microsoft Modeling Tools,” in Modelling Foundations and Applications, ser. Lecture Notes in Computer Science, T. K¨ uhne, B. Selic, M.-P. Gervais, and F. Terrier, Eds. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2010, vol. 6138, ch. 5, pp. 32–47. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-13595-8 5
[55]
S. Burmester, H. Giese, J. Niere, M. Tichy, J. P. Wadsack, R. Wagner, L. Wendehals, and A. Z¨ undorf, “Tool integration at the meta-model level: the Fujaba approach,” Int. J. Softw. Tools Technol. Transf., vol. 6, no. 3, pp. 203–218, Aug. 2004. [Online]. Available: http://dx.doi.org/10.1007/s10009-004-0155-8
[56]
J. Buur, “A theoretical approach to mechatronics design,” Ph.D. dissertation, Technical University of Denmark, 1990.
[57]
K. Chen, J. Sztipanovits, S. Abdelwalhed, and E. Jackson, “Semantic anchoring with model transformations,” in In ECMDA-FA, volume 3748 of LNCS. Springer, 2005, pp. 115–129.
[58]
E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, “Web Service Definition Language (WSDL),” W3C, Tech. Rep., Mar. 2001.
[59]
A. Christie, L. Levine, E. J. Morris, B. Riddle, and D. Zubrow, “Software Process Automation: Interviews, Survey, and Workshop Results,” SEI, Tech. Rep., 1997. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10. 1.1.115.9896
[60]
P. C. Clements, “A Survey of Architecture Description Languages,” in IWSSD ’96: Proceedings of the 8th International Workshop on Software Specification and Design. Washington, DC, USA: IEEE Computer Society, 1996. [Online]. Available: http://portal.acm.org/citation.cfm?id=858261
[61]
I. E. Commission, “BS/IEC 61508:2010, functional safety of electrical/electronic/programmable electronic safety-related systems.”
[62]
I. Crnkovic, “Component-based Software Engineering - New Challenges in Software Development,” in Proceedings of the 25th International Conference on Information Technology Interfaces 2003 (ITI 2003), vol. 2, 2001, pp. 127–133. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.2203
[63]
P. Cuenot, P. Frey, R. Johansson, H. L¨ onn, Y. Papadopoulos, M.-O. Reiser, A. Sandberg, D. Servat, R. T. Kolagari, M. T¨ orngren, and M. Weber, “The EAST-ADL Architecture Description Language for Automotive Embedded Software,” Model-Based Engineering of Embedded Real-Time Systems, 2010.
98
BIBLIOGRAPHY
[64]
B. Curtis, M. I. Kellner, and J. Over, “Process modeling,” Commun. ACM, vol. 35, no. 9, pp. 75–90, Sep. 1992. [Online]. Available: http: //dx.doi.org/10.1145/130994.130998
[65]
M. Del Fabro, J. B´ezivin, F. Jouault, and E. Breton, “AMW: A generic model weaver,” in Premiered Journees sur l’Ingenierie Dirigee par les Modeles, Jul. 2005. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10. 1.1.108.1294
[66]
M. Del Fabro, J. B´ezivin, and P. Valduriez, “Weaving models with the Eclipse AMW plugin,” in In Eclipse Modeling Symposium, Eclipse Summit Europe, 2006. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.7255
[67]
P. Derler, E. A. Lee, and A. S. Vincentelli, “Modeling Cyber-Physical Systems,” Proceedings of the IEEE, vol. 100, no. 1, pp. 13–28, Jan. 2012. [Online]. Available: http://dx.doi.org/10.1109/JPROC.2011.2160929
[68]
O. D’ıaz, J. D. Sosa, C. Arellano, and S. Trujillo, “Web-Based Tool Integration: A Web Augmentation Approach,” in Web Engineering, ser. Lecture Notes in Computer Science, M. Brambilla, T. Tokuda, and R. Tolksdorf, Eds., vol. 7387. Springer, 2012.
[69]
C. Ebert and C. Jones, “Embedded Software: Facts, Figures, and Future,” Computer, vol. 42, no. 4, pp. 42–52, Apr. 2009. [Online]. Available: http://dx.doi.org/10.1109/MC.2009.118
[70]
K. Ehrig, G. Taentzer, and D. Varro, “Tool integration by model transformations based on the Eclipse Modeling Framework,” in EASST Newsletter, vol. 12, 2006. [Online]. Available: http://mycite.omikk.bme.hu/doc/16597.pdf
[71]
U. W. Eisenecker and K. Czarnecki, Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000.
[72]
J. El-khoury, D. Chen, and M. T¨ orngren, “A Survey of Modelling Approaches for Embedded Computer Control Systems,” Royal Institute of Technology, KTH, Stockholm, Sweden, Tech. Rep., 2003.
[73]
J.-R. Falleri, M. Huchard, M. Lafourcade, and C. Nebut, “Metamodel Matching for Automatic Model Transformation Generation,” in Model Driven Engineering Languages and Systems, ser. LNCS, K. Czarnecki, I. Ober, J.-M. Bruel, A. Uhl, and M. V¨ olter, Eds. Springer-Verlag, 2008, vol. 5301, ch. 24, pp. 326–340. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-87875-9 24
[74]
J. M. Favre, “Towards a basic theory to model model driven engineering,” in In Workshop on Software Model Engineering, WISME 2004, joint event with UML2004, 2004.
[75]
R. T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures,” Ph.D. dissertation, University of California, Irvine, 2000.
[76]
B. Flyvbjerg, “Five Misunderstandings About Case-Study Research,” Qualitative Inquiry, vol. 12, no. 2, pp. 219–245, Apr. 2006. [Online]. Available: http://dx.doi.org/10.1177/1077800405284363
[77]
I. O. for Standardization, “ISO 26262:2011, road vehicles - functional safety,” 2011.
BIBLIOGRAPHY
99
[78]
R. Frost, “Jazz and the Eclipse way of collaboration,” IEEE Software, vol. 24, no. 6, pp. 114–117, Nov. 2007. [Online]. Available: http://dx.doi.org/10.1109/MS. 2007.170
[79]
D. Garlan, “Views for tools in integrated environments Advanced Programming Environments,” in Advanced Programming Environments, ser. Lecture Notes in Computer Science, R. Conradi, T. M. Didriksen, and D. H. Wanvik, Eds., vol. 244. Berlin, Heidelberg: Springer Berlin / Heidelberg, 1986, pp. 314–343. [Online]. Available: http://dx.doi.org/10.1007/3-540-17189-4 105
[80]
H. Giese, T. Levendovszky, and H. Vangheluwe, “Summary of the Workshop on Multi-Paradigm Modeling: Concepts and Tools,” in MoDELS Workshops, ser. Lecture Notes in Computer Science, T. K¨ uhne, Ed., vol. 4364. Springer, 2006, pp. 252–262. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-69489-2 31
[81]
H. Giese and R. Wagner, “From model transformation to incremental bidirectional model synchronization,” Software and Systems Modeling, vol. 8, no. 1, pp. 21–43, Feb. 2009. [Online]. Available: http://dx.doi.org/10.1007/s10270-008-0089-9
[82]
S. Gilmore, L. G¨ onczy, N. Koch, P. Mayer, M. Tribastone, and D. Varr´ o, “Non-functional properties in the model-driven development of service-oriented systems,” Software and Systems Modeling, vol. 10, no. 3, pp. 287–311, Jul. 2011. [Online]. Available: http://dx.doi.org/10.1007/s10270-010-0155-y
[83]
T. Gruber, “A translation approach to portable ontology specifications,” Knowledge Acquisition, vol. 5, no. 2, pp. 199–220, Jun. 1993. [Online]. Available: http://dx.doi.org/10.1006/knac.1993.1008
[84]
R. Hamann, S. Kriso, K. Williams, J. Klarmann, and J. Sauler, “ISO 26262 release just ahead - remaining problems and proposals for solutions,” in SAE 2011 world congress & exhibition, Apr. 2011. [Online]. Available: http://papers.sae.org/2011-01-1000/
[85]
C. Hein, T. Ritter, and M. Wagner, “Model-Driven Tool Integration with ModelBus,” in Workshop Future Trends of Model-Driven Development, 2009.
[86]
J. D. Herbsleb, D. J. Paulish, and M. Bass, “Global software development at Siemens: experience from nine projects,” in Proceedings of the 27th International Conference on Software Engineering, 2005, pp. 524–533. [Online]. Available: http://ieeexplore.ieee.org/xpls/abs all.jsp?arnumber=1553598
[87]
J. D. Herbsleb, “Global Software Engineering: The Future of Socio-technical Coordination,” in 2007 Future of Software Engineering, ser. FOSE ’07. Washington, DC, USA: IEEE Computer Society, 2007, pp. 188–198. [Online]. Available: http://dx.doi.org/10.1109/FOSE.2007.11
[88]
E. Herzog, “An Approach to Systems Engineering Tool Data Representaton and Exchange,” Ph.D. dissertation, Link¨ oping University, 2004.
[89]
R. Hilliard and T. Rice, “Expressiveness in architecture description languages,” in ISAW ’98: Proceedings of the third international workshop on Software architecture. New York, NY, USA: ACM Press, 1998, pp. 65–68. [Online]. Available: http://dx.doi.org/10.1145/288408.288425
100
BIBLIOGRAPHY
[90]
P. H¨ offerer, “Achieving business process model interoperability using metamodels and ontologies,” in Proceedings of the 15th European Conference on Information Systems (ECIS 2007), 2007, pp. 1620–1631.
[91]
IEEE, “IEEE Standard Glossary of Software Engineering Terminology,” IEEE, Tech. Rep., 1990. [Online]. Available: http://dx.doi.org/10.1109/IEEESTD.1990. 101064
[92]
ISO, “Industrial automation systems and integration – product data representation and exchange (ISO 10303),” ISO, Tech. Rep., 1994. [Online]. Available: http:// www.iso.org/iso/iso catalogue/catalogue tc/catalogue detail.htm?csnumber=20579
[93]
Iso, “Software and systems engineering – Architecture description (ISO/IEC/IEEE 42010),” ISO, Tech. Rep., Dec. 2011.
[94]
D. Jackson and M. Rinard, “Software analysis: a roadmap,” in Proceedings of the Conference on The Future of Software Engineering, ser. ICSE ’00. New York, NY, USA: ACM, 2000, pp. 133–145. [Online]. Available: http://dx.doi.org/10.1145/336512.336545
[95]
S. Johnsto, “UML 2.0 Profile for Software Services,” IBM, Tech. Rep., Apr. 2005. [Online]. Available: http://www.ibm.com/developerworks/rational/library/ 05/419 soa/
[96]
F. Jouault, F. Allilaire, J. B´ezivin, and I. Kurtev, “ATL: a model transformation tool,” Science of Computer Programming, vol. 72, pp. 31–39, Jun. 2008.
[97]
G. Kappel, E. Kapsammer, H. Kargl, G. Kramler, T. Reiter, W. Retschitzegger, W. Schwinger, and M. Wimmer, “Lifting Metamodels to Ontologies: A Step to the Semantic Integration of Modeling Languages,” MODELS, vol. 4199, pp. 528–542, 2006. [Online]. Available: http://dx.doi.org/10.1007/11880240 37
[98]
G. Kappel, M. Wimmer, W. Retschitzegger, and W. Schwinger, Leveraging Model-Based Tool Integration by Conceptual Modeling Techniques The Evolution of Conceptual Modeling, ser. Lecture Notes in Computer Science. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2011, vol. 6520, ch. 12, pp. 254–284. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-17505-3 12
[99]
E. Kapsammer, H. Kargl, G. Kramler, T. Reiter, W. Retschitzegger, and M. Wimmer, “On Models and Ontologies - A Layered Approach for Modelbased Tool Integration,” in MOD2006, 2006, pp. 11–27. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.86.3053
[100] E. Kapsammer and T. Reiter. Model-Based Tool Integration- State of the Art and Future Perspectives. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/ summary?doi=10.1.1.90.1751 [101] G. Karsai, A. Lang, and S. Neema, “Design patterns for open tool integration,” Software and Systems Modeling, vol. 4, no. 2, pp. 157–170, May 2005. [Online]. Available: http://dx.doi.org/10.1007/s10270-004-0073-y [102] S. Kelly and J.-P. Tolvanen, Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society Pr, Mar. 2008. [Online]. Available: http://www.worldcat.org/isbn/0470036664
BIBLIOGRAPHY
101
[103] K. Keutzer, S. Malik, R. Newton, J. Rabaey, and A. Sangiovanni-Vincentelli, “System Level Design: Orthogonolization of Concerns and Platform-Based Design,” IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, vol. 19, no. 12, Dec. 2000. [Online]. Available: http: //www.gigascale.org/pubs/98.html [104] H. M. Kienle, “Exchange format bibliography,” SIGSOFT Softw. Eng. Notes, vol. 26, no. 1, pp. 56–60, Jan. 2001. [Online]. Available: http: //dx.doi.org/10.1145/505894.505908 [105] F. Klar, S. Rose, and A. Sch¨ urr, “TiE - A Tool Integration Environment,” in Proceedings of the 5th ECMDA Traceability Workshop, ser. CTIT Workshop Proceedings, vol. WP09-09, 2009, pp. 39–48. [106] G. Klyne and J. J. Carroll, “Resource description framework (RDF): Concepts and abstract syntax,” W3C, Tech. Rep., Feb. 2004. [Online]. Available: http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ [107] 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. New York, NY, USA: ACM, 2006, pp. 43–46. [Online]. Available: http://dx.doi.org/10.1145/1138304.1138314 [108] T. K¨ uhne, “Matters of (Meta-) Modeling,” Software and Systems Modeling, vol. 5, no. 4, pp. 369–385, Dec. 2006. [Online]. Available: http://dx.doi.org/10.1007/ s10270-006-0017-9 [109] I. Kurtev, J. B´ezivin, and M. Aksit, “Technological spaces: An initial appraisal,” in CoopIS, DOA 2002 Federated Conferences, Industrial track, 2002. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.332 [110] A.-L. L. Lamprecht, T. Margaria, and B. Steffen, “Bio-jETI: a framework for semantics-based service composition.” BMC bioinformatics, vol. 10 Suppl 10, no. Suppl 10, pp. S8+, 2009. [Online]. Available: http://dx.doi.org/10.1186/ 1471-2105-10-S10-S8 [111] K. G. Larsen, P. Pettersson, and W. Yi, “Uppaal in a Nutshell,” Int. Journal on Software Tools for Technology Transfer, vol. 1, no. 1–2, pp. 134–152, Oct. 1997. [112] V. I. Levenshtein, “Binary Codes Capable of Correcting Deletions, Insertions and Reversals,” Doklady Akademii Nauk SSSR, vol. 163, no. 4, pp. 845–848, 1965. [113] B. Lud¨ ascher, I. Altintas, C. Berkley, D. Higgins, E. Jaeger, M. Jones, E. A. Lee, J. Tao, and Y. Zhao, “Scientific workflow management and the Kepler system,” Concurrency and Computation: Practice and Experience, vol. 18, no. 10, pp. 1039–1065, 2006. [Online]. Available: http://dx.doi.org/10.1002/cpe.994 [114] V. Mah´e, H. Bruneli`ere, F. Jouault, J. B´ezivin, and J.-P. Talpin, “ModelDriven Interoperability of Dependencies Visualizations,” in Proceedings of the 3rd Workshop on Model-Driven Tool & Process Integration (co-located with ECMFA 2010, France, Jun. 2010, pp. 128–140. [Online]. Available: http://hal.archives-ouvertes.fr/hal-00534441
102
BIBLIOGRAPHY
[115] I. Malavolta, H. Muccini, P. Pelliccione, and D. A. Tamburri, “Providing Architectural Languages and Tools Interoperability through Model Transformation Technologies,” IEEE Transactions on Software Engineering, vol. 36, no. 1, pp. 119–140, Jan. 2010. [Online]. Available: http://dx.doi.org/10.1109/TSE.2009.51 [116] T. Margaria, “Web services-based tool-integration in the ETI platform,” Softw Syst Model, 2005. [117] A. Mayer, S. Mcgough, N. Furmento, W. Lee, M. Gulamali, S. Newhouse, and J. Darlington, “Workflow Expression: Comparison of Spatial and Temporal Approaches,” in Workflow in Grid Systems, 2004. [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.87.404 [118] N. Medvidovic, E. M. Dashofy, and R. N. Taylor, “Moving architectural description from under the technology lamppost,” Information and Software Technology, vol. 49, no. 1, pp. 12–31, Jan. 2007. [Online]. Available: http://dx.doi.org/10.1016/j.infsof.2006.08.006 [119] N. Medvidovic and R. N. Taylor, “A Classification and Comparison Framework for Software Architecture Description Languages,” IEEE Transactions on Software Engineering, vol. 26, no. 1, pp. 70–93, 2000. [Online]. Available: http://dx.doi.org/10.1109/32.825767 [120] S. Melnik, H. Garcia-molina, and E. Rahm. (2002) Similarity flooding: A versatile graph matching algorithm. [Online]. Available: http://citeseerx.ist.psu. edu/viewdoc/summary?doi=10.1.1.135.2192 [121] S. Melnik, E. Rahm, and P. A. Bernstein, “Rondo: a programming platform for generic model management,” in Proceedings of the 2003 ACM SIGMOD international conference on Management of data, ser. SIGMOD ’03. New York, NY, USA: ACM, 2003, pp. 193–204. [Online]. Available: http://dx.doi.org/10.1145/872757.872782 [122] T. Mens and P. Van Gorp, “A Taxonomy of Model Transformation,” Electr. Notes Theor. Comput. Sci, vol. 152, pp. 125–142, 2006. [123] M. Mernik, J. Heering, and A. M. Sloane, “When and how to develop domain-specific languages,” ACM Comput. Surv., vol. 37, no. 4, pp. 316–344, Dec. 2005. [Online]. Available: http://dx.doi.org/10.1145/1118890.1118892 [124] D. Merschen, R. Gleis, J. Pott, and S. Kowalewski, “Analysis of Simulink Models Using Databases and Model Transformations,” in COMPSAC Workshops 2012, Jul. 2012. [125] N. Milanovic, M. Cartsburg, R. Kutsche, J. Widiker, and F. Kschonsak, “ModelBased Interoperability of Heterogeneous Information Systems: An Industrial Case Study Model Driven Architecture - Foundations and Applications,” in ECMDA-FA 2009, ser. Lecture Notes in Computer Science, R. F. Paige, A. Hartman, and A. Rensink, Eds., vol. 5562. Berlin, Heidelberg: Springer Berlin / Heidelberg, 2009, pp. 325–336. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-02674-4 24 [126] N. F. Noy, “Semantic integration: a survey of ontology-based approaches,” SIGMOD Rec., vol. 33, no. 4, pp. 65–70, Dec. 2004. [Online]. Available: http://dx.doi.org/10.1145/1041410.1041421
BIBLIOGRAPHY
103
[127] OASIS, “OASIS Web Services Business Process Execution Language (WSBPEL) TC,” ”OASIS”, Tech. Rep., Apr. 2007. [128] OASIS Committee, “Service Component Architecture Assembly Model Specification Version 1.1,” Open SOA, Tech. Rep., May 2011. [Online]. Available: https: //www.oasis-open.org/committees/sca-assembly/ [129] S. C. of RTCA, “DO-178C, software considerations in airborne systems and equipment certification,” 2011. [130] ——, “DO-330, software tool qualification considerations,” 2011. [131] D. W. Oliver, T. P. Kelliher, and James, Engineering Complex Systems With Models and Objects. McGraw-Hill Companies, 1997. [Online]. Available: http://www.worldcat.org/isbn/0070481881 [132] OMG, “Meta Object Facility (MOF), v2.0,” OMG, Tech. Rep., Jan. 2006. [Online]. Available: http://www.omg.org/spec/MOF/2.0/ [133] ——, “MOF 2.0 / XMI Mapping Specification, v2.1.1,” OMG, Tech. Rep., Dec. 2007. [Online]. Available: http://www.omg.org/technology/documents/formal/xmi.htm [134] Omg, “MOF Model to Text Language (MTL),” OMG, Tech. Rep., Jan. 2008. [Online]. Available: http://www.omg.org/spec/MOFM2T/1.0/ [135] OMG, “Software & Systems Process Engineering Metamodel Specification (SPEM),” ”OMG”, Tech. Rep., Apr. 2008. [Online]. Available: http: //www.omg.org/spec/SPEM/2.0 [136] ——, “Software & Systems Process Engineering Metamodel specification (SPEM) 2.0,” OMG, Tech. Rep., 2008. [Online]. Available: http://www.omg.org/spec/ SPEM/2.0/PDF [137] ——, “MOF 2.0 Query / View / Transformation,” OMG, Tech. Rep., Dec. 2009. [Online]. Available: http://www.omg.org/spec/QVT [138] ——, “SoaML,” OMG, Tech. Rep., 2009. [Online]. Available: http://www.omg. org/spec/SoaML/ [139] ——. (2010) Unified Modeling Language (UML). [Online]. Available: //www.omg.com/uml/
http:
[140] ——, “Business Process Model And Notation (BPMN),” ”OMG”, Tech. Rep., Jan. 2011. [Online]. Available: http://www.omg.org/spec/BPMN/2.0/ [141] OSLC Core Specification Workgroup, “OSLC core specification version 2.0,” Open Services for Lifecycle Collaboration, Tech. Rep., Aug. 2010. [Online]. Available: http://open-services.net/bin/view/Main/OslcCoreSpecification [142] C. J. J. Paredis, “System-Level Model Intergration of Design & Simulation for Mechatronic Stystems Based on SysML,” in Mechatronics Vol. 21 No. 6, ser. Journal of Computing and Information Science in Engineering, vol. 21, American Society of Mechanical Engineers (ASME). New York, NY: American Society of Mechanical Engineers (ASME), Aug. 2010, pp. 1063–1075.
104
BIBLIOGRAPHY
[143] L. Pareto, P. Eriksson, and S. Ehnebom, “Architectural descriptions as boundary objects in system and design work,” in Proceedings of the 13th international conference on Model driven engineering languages and systems: Part II, ser. MODELS’10. Berlin, Heidelberg: Springer-Verlag, 2010, pp. 406–419. [Online]. Available: http://portal.acm.org/citation.cfm?id=1929141 [144] C. M. Pilato, B. Collins-Sussman, and B. W. Fitzpatrick, Version Control with Subversion, 1st ed. O’Reilly Media, Jun. 2004. [Online]. Available: http://www.worldcat.org/isbn/0596004486 [145] C. C. Ragin and H. S. Becker, What is a case? : exploring the foundations of social inquiry. Cambridge University Press, Jul. 1992. [Online]. Available: http://www.worldcat.org/isbn/0521421888 [146] E. Rosch, Principles of Categorization. John Wiley & Sons Inc, 1978, pp. 27–48. [Online]. Available: http://www.worldcat.org/isbn/0470263776 [147] M. Shaw, “What makes good research in software engineering?” International Journal on Software Tools for Technology Transfer (STTT), vol. 4, no. 1, pp. 1–7–7, Oct. 2002. [Online]. Available: http://dx.doi.org/10.1007/s10009-002-0083-4 [148] M. Shaw and D. Garlan, Software architecture.
Prentice Hall, 1996.
[149] S. L. Star and J. R. Griesemer, “Institutional Ecology, ’Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39,” Social Studies of Science, vol. 19, no. 3, pp. 387–420, 1989. [Online]. Available: http://dx.doi.org/10.2307/285080 [150] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, EMF: Eclipse Modeling Framework (2nd Edition), 2nd ed. Addison-Wesley Professional, Jan. 2008. [Online]. Available: http://www.worldcat.org/isbn/0321331885 [151] W. D. Sunindyo, T. Moser, D. Winkler, and S. Biffl, “A process model discovery approach for enabling model interoperability in signal engineering,” in Proceedings of the First International Workshop on Model-Driven Interoperability, ser. MDI ’10. New York, NY, USA: ACM, 2010, pp. 15–21. [Online]. Available: http://dx.doi.org/10.1145/1866272.1866276 [152] J. Sztipanovits, G. Karsai, S. Neema, and T. Bapty, “The Model-Integrated Computing Tool Suite Model-Based Engineering of Embedded Real-Time Systems,” in MBERTS, ser. LNCS, H. Giese, G. Karsai, E. Lee, B. Rumpe, and B. Sch¨ atz, Eds. 2011, vol. 6100, ch. 20, pp. 369–376. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-16277-0 20 [153] R. N. Taylor, N. Medvidovic, and E. M. Dashofy, Software Architecture: Foundations, Theory, and Practice, 1st ed. Wiley, Jan. 2009. [Online]. Available: http://www.worldcat.org/isbn/0470167742 [154] I. Thomas and B. A. Nejmeh, “Definitions of tool integration for environments,” Software, IEEE, vol. 9, no. 2, pp. 29–35, Mar. 1992. [Online]. Available: http://dx.doi.org/10.1109/52.120599
BIBLIOGRAPHY
105
[155] M. T¨ orngren, D. Chen, and I. Crnkovic, “Component-based vs. Modelbased Development: A Comparison in the Context of Vehicular Embedded Systems,” in EUROMICRO ’05: Proceedings of the 31st EUROMICRO Conference on Software Engineering and Advanced Applications. Washington, DC, USA: IEEE Computer Society, 2005, pp. 432–441. [Online]. Available: http://dx.doi.org/10.1109/EUROMICRO.2005.18 [156] M. T¨ orngren, D. Chen, D. Malvius, and J. Axelsson, Model-Based Development of Automotive Embedded Systems. CRC Press, 2008. [157] L. Tratt, “Model transformations and tool integration,” Software and Systems Modeling, vol. 4, no. 2, pp. 112–122, May 2005. [Online]. Available: http://dx.doi.org/10.1007/s10270-004-0070-1 [158] C. J. Van Rijsbergen, Information Retrieval, 2nd ed. Butterworth-Heinemann. [Online]. Available: http://www.dcs.gla.ac.uk/Keith/Preface.html [159] M. Vasko and S. Dustdar, “A view based analysis of workflow modeling languages,” in 14th Euromicro International Conference on Parallel, Distributed, and Network-Based Processing, 2006. PDP 2006., 2006, pp. 8 pp.+. [Online]. Available: http://dx.doi.org/10.1109/PDP.2006.17 [160] VDI, “Design methodology for mechatronic systems (VDI 2206),” VDI, Tech. Rep., 2004. [161] H. Wache, T. V¨ ogele, U. Visser, H. Stuckenschmidt, G. Schuster, H. Neumann, and S. H¨ ubner, “Ontology-Based Information Integration: A Survey.” [Online]. Available: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.12.7857 [162] W. Wang, A. Tolk, and W. Wang, “The levels of conceptual interoperability model: applying systems engineering principles to M&S,” in Proceedings of the 2009 Spring Simulation Multiconference, ser. SpringSim ’09. San Diego, CA, USA: Society for Computer Simulation International, 2009. [Online]. Available: http://portal.acm.org/citation.cfm?id=1655398 [163] A. I. Wasserman, “Tool Integration in Software Engineering Environments,” in Software Engineering Environments, International Workshop on Environments Proceedings, ser. Lecture Notes in Computer Science, F. Long, Ed. Springer-Verlag, Sep. 1989, pp. 137–149. [Online]. Available: http://www.springerlink.com/content/ p582q2n825k87nl5/ [164] M. Wicks and R. Dewar, “A new research agenda for tool integration,” Journal of Systems and Software, vol. 80, no. 9, pp. 1569–1585, Sep. 2007. [Online]. Available: http://dx.doi.org/10.1016/j.jss.2007.03.089 [165] M. N. Wicks, “Tool Integration within Software Engineering Environments: An Annotated Bibliography,” Heriot-Watt University, Tech. Rep., 2006. [Online]. Available: http://www.macs.hw.ac.uk:8080/techreps/docs/files/HW-MACS-TR-0041. pdf [166] J. Wiegand, “The Case for Open Services,” IBM Rational Software, Tech. Rep., May 2009.
106
BIBLIOGRAPHY
[167] E. Woods and R. Hilliard, “Architecture Description Languages in Practice Session Report,” in WICSA ’05: Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05). Washington, DC, USA: IEEE Computer Society, 2005, pp. 243–246. [Online]. Available: http: //dx.doi.org/10.1109/WICSA.2005.15 [168] Y. Yang and J. Han, “Classification of and Experimentation on Tool Interfacing in Software Development Environments,” in Proceedings of the Third Asia-Pacific Software Engineering Conference, ser. APSEC ’96. Washington, DC, USA: IEEE Computer Society, 1996. [Online]. Available: http://ieeexplore.ieee.org/xpls/ abs all.jsp?arnumber=566740&tag=1 [169] W. Zhang, B. Møller-Pedersen, and M. Biehl, “A light-weight tool integration approach – from a tool Integration Model to OSLC Integration Services,” in International Conference on Software Paradigm Trends (ICSOFT 2012), Jul. 2012. [170] J. Ziemann, O. Ohren, F.-W. J¨ akel, T. Kahl, and T. Knothe, “Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel Enterprise Interoperability,” in Enterprise Interoperability, G. Doumeingts, J. M¨ uller, G. Morel, and B. Vallespir, Eds. London: Springer London, 2007, ch. 19, pp. 199–208. [Online]. Available: http://dx.doi.org/10.1007/978-1-84628-714-5 19
Part IV
Appended Papers
107
Appendix A
A Modular Tool Integration Approach - Experiences from two Case Studies Matthias Biehl, Carl-Johan Sj¨ ostedt, and Martin T¨ orngren in 3rd Workshop on Model-Driven Tool & Process Integration (MDTPI2010) at the European Conference on Modelling Foundations and Applications (ECMFA 2010) June 2010
A Modular Tool Integration Approach Experiences from two Case Studies Matthias Biehl, Carl-Johan Sj¨ostedt, Martin T¨orngren Embedded Control Systems Royal Institute of Technology Stockholm, Sweden {biehl,carlj,martin}@md.kth.se
Abstract. In the model-driven development process of automotive embedded systems a number of specialized tools are used to support various development tasks. Each tool needs to work seamlessly with artifacts created by other tools to increase the efficiency of development. We identify desirable properties for integrating the data of different tools. We then propose an approach for decomposing the data integration into modular steps that fulfill these properties. We report our experiences from applying this approach to integrate simulation capabilities and functionality for safety analysis into a model-based development environment. Key words: Tool Integration, Model Transformation
1
Introduction
Model-based development is an approach that uses models as primary artifacts for describing a system. During development a series of different models is created, refined, analyzed and transformed. The tools that are used to manipulate and develop the models are highly specialized and have their strength in supporting a particular development task or phase. Different tools are used to work with the modeling data, and often the output created by one tool needs to be the input to another tool. The tools need to be aligned in such a way that they form a tool chain. Not only tools for creating and designing models need to be integrated, but also tools for analysis and simulation. Some of the tools are proprietary and closed, thus they cannot be modified to support a particular integration scenario. The tools and their modeling data need to be integrated to realize the vision of a seamless model-based development approach. While it is possible to achieve an ad-hoc integration between two tools with some manual work, the focus of this paper is on working towards a systematic solution for model-based tool integration. In this work we extract a modular tool integration approach from the commonalities we have identified based on the experiences from several point-to-point integration approaches. This work has been carried out in the context of developing EAST-ADL [3], a modeling language for automotive embedded systems. We report on experiences from two case studies involving tool integration between EAST-ADL and the simulation
tool MATLAB/Simulink [11] as well as between EAST-ADL and a reliability analysis tool HiP-HOPS [13]. The remainder of this document is structured as follows. In section 1.1 we introduce some basic terms and technology. Section 2 describes the requirements for data integration. Section 3 introduces our modular approach for data integration fulfilling the previously identified requirements. In section 4 we describe two case studies using our proposed approach. In section 5 we introduce related work and conclude in section 6.
1.1
Terms and Technology
The technical space of a model concerns the technology used for representation of the model [12]. Typical technical spaces are EMF (Eclipse Modeling Framework) or XML. The technical space comprises all modeling levels M0-M3 by the OMG. Each technical space has its own metametamodel and its own set of tools and technologies to interact with the models. Model transformations describe the relationship between models, more specifically the mapping of information from one model to another one. A model transformation involves two models: a source model and a target model, where source and target models can have the same or different metamodels. A model transformation description is written in a special purpose language, a model transformation language. The transformation description is usually given by a set of model transformation rules, describing how a model in the source language can be transformed into a model in the target language [10]. The model transformation descriptions are interpreted by a model transformation engine which produces the target model-based on the transformation description and information from the source model. Model transformations are based on concepts of the metamodels, thus they can map any model that corresponds to the metamodel. In this work we use two different model transformation engines, a model-to-text and a model-to-model transformation engine. In the following paragraphs we introduce these engines. OpenArchitecureWare (OAW) integrates a number of tools for model transformations into a coherent framework [5]. OAW provides a workflow specification language and the transformation language Xpand. The Xpand transformation language is a template-based, imperative language for model-to-text transformations. The ATLAS Transformation Language (ATL) is a hybrid model transformation language [8]. It includes both declarative and imperative constructs and supports both programming styles. However, the preferred style is declarative, which allows a cleaner and simpler implementation for simple mappings. ATL is integrated in the Eclipse development environment and can handle models based on EMF.
2
Needs for Data Integration
There are several dimensions of tool integration, Wassermann [15] classifies them into the dimensions of data integration, control integration, process integration, platform integration and presentation integration. In this paper we mainly focus on one dimension of tool integration, which is data integration. The data of model-based tools is represented by models. However, these models adhere to different metamodels which determine the structure of the data and the models are represented using different technical spaces. Goals and desired properties for the integration solution are simplicity and understandability, maintainability and evolvability (i.e. if tools change their interface, the tool integration to change the interface as well), exploiting advantages of different model transformation paradigms. When data needs to be integrated between Tool A and Tool B, the data of Tool A has to be expressed in such a way that it can be used by Tool B. In this process, some properties of the data need to be changed, while other properties need to be preserved. In the following sections we identify these properties.
2.1
Adaptation of Tool Data for Realizing Data Integration
For realizing data integration between a source and target tools, the tool data of the source tool needs to be adapted for the target tool. The following properties of the tool data need to be adapted: – Abstract syntax: The structure or syntax of the tool data might need to be adapted to the target tool. The information of the source tool needs to be rearranged to adhere to the structure expected by the target tool. For example one tool might represent data in a nested tree structure, while another represents the same information as a list. Syntactic changes or restructuring of the information is the domain of model transformations. This part deals with the selection of appropriate information from the source model and restructuring it appropriately. The mapping is based on the information in the metamodel of both source and target model. This step is independent of the technical space used by the target tool. – Technical space: Models can be represented using different technical spaces. The information needs to be represented by the technical space expected by the target tool. Even if the information is structured as expected by the target tool, it can be represented using different technical spaces. The same structure can be represented using e.g. XML, an EMF model, a text-based format or a proprietary format. The above mentioned properties are orthogonal to each other and can be changed independently. It is for example possible to change the technical space while preserving the abstract syntax.
2.2
Preservation of Properties for Data Integration
The following properties of the data might need to be preserved for data integration: – Preservation of the concrete syntax and graphical layout: Models are often presented to the user in a graphical form. The user can convey information by the graphical placement of model elements. It can e.g. be expressed that certain elements belong together by placing them close to each other on the drawing canvas. In a textual concrete syntax, similar grouping can be expressed e.g. by the proximity of variable declarations. – Preservation of the semantics: If the integrated tools are similar, a mapping can be found that is semantics preserving, i.e. the meaning of the two models is the same, even though it is represented in a different technical space or using a different abstract syntax. Semantics-preserving transformations change the way computations are performed without changing the values computed. – Approximation of the semantics: If the integrated tools have fundamentally different assumptions, it might be difficult to completely preserve the semantics when bridging the gap between tools. Instead the mapping between the tools can approximate a preservation of the meaning of the model. Approximation can preserve the essential properties of the model. An example is the mapping from a complex state machine to a simplified state machine or the mapping between a nonlinear mathematical function and a linear mathematical function.
3
A Modular Approach for Data Integration
In our solution we use the principle of separation of concerns to structure the data integration in such a way that the two issues identified in section 2.1 remain independent. That way we achieve a modular solution, having advantages for maintenance, evolution, understandability and reuse of the data integration solution. Fig. 1 presents our approach for data integration of three different tools. Each of Tool A and Tool B use different metamodels to represent their data and different technical spaces. Neither tool uses EMF as their technical space. EMF is the adopted technical space for integration. This requires that each tool represents the relevant data in the technical space of EMF. A third tool - Tool C - already represents its data using EMF-models and hence does not require an intermediate model or technical space bridge. Its data can be mapped using a structural bridge. This can for example be the EMF-based modeling environment Papyrus. For both Tool A and Tool B there is an associated intermediate model (see section 3.1), that stores the relevant tool data in EMF, the adopted technical space for integration. A technical space bridge (see section 3.2) crosses the technical space between the tools and EMF to import or export the relevant
Fig. 1. Technical Space Bridges and Structural Bridges
data. A structural bridge (see section 3.3) links the elements of the intermediate models and changes the abstract syntax so that the semantics is preserved (or approximated). 3.1
Intermediate Model
Intermediate models are the tool-specific models that represent tool data in the technical space for integration. These intermediate models are syntactically aligned with the tool data, meaning that the intermediate data is structured in the same way. The difference between the intermediate model and the tool data is the technical space. In a tool chain, the tool data is first represented as an intermediate model using a technical space bridge, then a structural bridge is used to map concepts to the intermediate model of the target tool, finally the technical space bridge of the target tool represents the concept in a tool specific way. The intermediate model usually focuses on a certain subset of the tool data that is considered relevant in the context of integration. Thus the intermediate model is a simplification of the tool data. In Fig. 1 this is illustrated by a smaller circle for the intermediate metamodel. Irrelevant data, such as certain parameters, details or redundant data are left out. The amount of data that needs to be included in the intermediate model depends on the use case. If complete roundtrip integration is required, the intermediate model needs to be complete. However the limitation on a relevant subset of the tool data allows the transformation to stay small and maintainable. 3.2
Technical Space Bridge
Technical space bridges have the purpose of transitioning data between the external representation of the tool and the intermediate model in the technical
space chosen for integration. Technical space bridges can be used in two directions, as extractors and as injectors. Extractors read proprietary tool-specific data and represent this data in the technical space of integration. Injectors deal with representing model data in a tool specific way. Since we propose that the intermediate model is as small as possible, the extractor leaves out irrelevant data, whereas a injector adds missing information in the form of default values. Technical space bridges are trivial when the tool already processes models of the adopted technical space for integration. Otherwise, technical space bridges are specific to each tool that is integrated. They are hard to generalize and hence we survey the different mechanisms for injecting or extracting data from proprietary tools: – Reading and writing files are the usual way to exchange data. Parsers can be used as extractors and model-to-text transformations can be used as injectors. – For injection of data into legacy tools we can use program parameters and stdin when calling the tool, for extraction we can use stdout. – An application programming interface (API) can be used to inject and extract data from the tool. – A component infrastructure (e.g. CORBA, DCOM) or web service can be used for bidirectional data exchange, if the tool provides these facilities. – The scripting language or macro inside the target tool can be used for injection or extraction of tool data. The first few mechanisms are similar, as all of them use external means to get hold of the data, while the last mechanism uses the internal capabilities of the tool to make the information available. 3.3
Structural Bridge
Structural bridges map corresponding data elements of different tools. Model transformations describe the relationship between models and thus they can be used as a mechanism for structural bridges. Structural bridges can assume that relevant tool data is available as an intermediate model in a common technical space for integration, which is EMF in our solution. However, a large number of model transformation languages, engines and tools exist, which have different characteristics that can be relevant for certain integration tasks. An overview and a classification of the transformation tools is provided in [12, 4]. Picking the right model transformation tool for the task at hand is a challenge. The selection of the model transformation tools is dependent on the technical space that is involved and on other properties offered by the transformation tool, such as bidirectionality, traces and programming paradigms. In the case of a common technical space, a declarative language such as ATL can express the mappings in a simple and concise way [7].
4
Case Studies
To validate our integration architecture, we performed two case studies. Both case studies are based on the architecture description language EAST-ADL [3], a language for modeling the architecture of automotive embedded systems. 4.1
Integration of a Reliability Analysis Tool
During the model-based development in EAST-ADL, the reliability of the developed system has to be determined. We chose HiP-HOPS as a tool for reliability analysis, as it supports fault tree analysis and failure modes and effects analysis [13]. We integrated HiP-HOPS with EAST-ADL as described in earlier work [1]. This integration is unidirectional and the data from EAST-ADL is exported to HiP-HOPS for analysis.
Fig. 2. Export from EAST-ADL to HiP-HOPS
The tool for developing EAST-ADL models, the Papyrus UML editor, does not require a specific technical space bridge, as it produces compatible EMF models in the technical space of integration already. In this case, the intermediate model is equal to the tool data. The reliability analysis tool HiP-HOPS expects textual input, which can be synthesized from the EAST-ADL model by a technical space bridge and a structural bridge. We used the integration architecture described in section 3. Intermediate Model As shown in Fig. 2 we introduce an intermediate model which serves as the interface between technical space bridge and a structural bridge. The intermediate model conforms to a HiP-HOPS Ecore metamodel that is aligned with the HiP-HOPS grammar. Structural Bridge The structural bridge transforms an EAST-ADL model that was created in the Papyrus UML modeling environment into an intermediate model. The transformation is called M2M Trafo in Fig. 2. The structure of the intermediate model resembles the HiP-HOPS grammar, so it is close to the
structure of the desired output. This stage performs a semantics-preserving mapping between the domains of EAST-ADL and that of HiP-HOPS. However, this stage is not concerned with the actual representation of the data. The purpose of the structural bridge is to map concepts from EAST-ADL to HiP-HOPS in a way that preserves the semantics of the original model, even though the structure of the model must be changed heavily. EAST-ADL models and HiP-HOPS models are structurally different. This can be demonstrated by the following example. EAST-ADL follows the concepts of declaring types first and referencing to the declaration from each point of use. In HiP-HOPS on the other hand, the declaration and usage of a type is coupled, types are declared at the same point as they are used. Thus the declarations have to be inlined into every point of usage, when transforming from EAST-ADL to HiP-HOPS.
Technical Space Bridge The purpose of the technical space bridge for HiPHOPS is the generation of a textual description based on the intermediate model. The technical space bridge takes the intermediate model as input and creates the tool-specific file for the HiP-HOPS program. This step is mainly concerned with the representation of the information according to the concrete syntax required by HiP-HOPS. No structural changes are required in this transformation. The focus is on serializing the model as text. The technical space bridge is realized as a model-to-text transformation and can be classified as an endogenous, horizontal, model-to-text transformation. We choose the Xpand language of OpenArchitectureWare to implement the technical space bridge. Xpand is a template-based model transformation language, which incorporates the output in the form of templates into the control structure.
4.2
Integration of a Simulation Tool
The tool-suite MATLAB/Simulink is a simulation tool used at various stages of automotive product development for different purposes, e.g. control design, code generation, hardware-in-the-loop testing, etc.. We have developed a bidirectional tool integration between Simulink and EAST-ADL. The first version of the tool was presented in [14]. The current version presented here follows the same approach to separate the technical space bridge from the structural bridge. The integration is bidirectional and supports import from Simulink to EAST-ADL (see Fig. 3) and export from EAST-ADL to Simulink (see Fig. 4).
Intermediate Model Simulink has an extensive set of tool data using a large number of different element types and parameters. Not all of the details contained in the tool data are relevant for the integration with EAST-ADL. A large intermediate model would make the structural bridge more complicated and harder to maintain. That is why we create an intermediate model from only the relevant subset of the tool data (see Fig. 5)
Fig. 3. Import from Simulink to EAST-ADL
Fig. 4. Export from EAST-ADL to Simulink
Structural Bridge The purpose of the structural bridge is to map concepts between EAST-ADL and Simulink in such a way that the semantics of the original model is preserved. For example, Simulink Lines correspond to EASTADL FunctionConnectors; Simulink Inports and Outports both correspond to the same concept FunctionFlowPorts in EAST-ADL, only differentiated by the value of the direction attribute. We use ATL for implementing the structural bridge. Technical Space Bridge We have evaluated two ways of accessing Simulink model data, first by parsing the .mdl files using a metamodel of the Simulink data file (as presented in [14]), and second by using the MATLAB API. Using the MATLAB API more data is available but the downside is that it provides too much information: A regular Simulink block has more than 120 blockparameters, of which many of them are rarely used. The large number of exceptions for certain parameters and block-types resulted in an unmaintainable and inefficient solution. Hence, the current solution is a combination of using the API and .mdl files. We store all modeling elements inside .mdl files, so they can be used in model reference blocks. The Simulink library mechanism works in a similar way and could possibly also be used in a future version of the technical space bridge. By using Simulink’s native .mdl format for storing the system containment, it is ensured that valid models are produced, and most Simulink constructs can be used. The ports and connections between these model refer-
ence blocks are translated so it is possible for model reference blocks to contain other model reference blocks.
Fig. 5. Intermediate Metamodel for Simulink
5
Related Work
Karsai et al. identify two patterns for tool integration [9], one with an integrated data model and a second pattern based on process flows. Our approach is similar to the second pattern, however it does not require the extensive backplane solution. While Karsai describes a pattern, our approach is a concrete solution for the automotive domain. ModelBus is an integration infrastructure [6], providing services such as model storage and version management. Tool adapters are connected using web services. Since the ModelBus infrastructure does not constrain the modularization of the connected services, the approach proposed in this paper is orthogonal to the ModelBus infrastructure, allowing both approaches to be combined. Cuadrado et al. survey different techniques for the modularization of model transformations. The work differentiates between internal and external composition of model transformations and proposes a phasing mechanism for internal composition [2]. Our approach uses external composition as it allows us to use different model transformation languages and engines that are fit for the particular purpose.
6
Conclusion
In this work we have analyzed the needs for exchanging data for tool integration. Whereas some aspects of the data need to be adapted, such as technical space and
the abstract syntax, other aspects need to be preserved, such as semantics and layout. We present a modular tool integration approach that uses separation of concerns to modularize and separate the identified changes in technical space and abstract syntax. Technical space bridges bring tool data into the technical space of models and represent the data as an intermediate model. The tool-specific intermediate metamodel is a simplification of the tool data. The intermediate metamodel is designed to comprise only the subset of the tool data that is relevant for the integration. Structural bridges translate between concepts of different intermediate models. We applied this approach for integrating two external tools within a development environment for EAST-ADL and identified the following properties of our solution: – Our solution separates two different concerns of the tool integration: (1) the structural bridge between the domains of EAST-ADL and that of HiPHOPS/Simulink and the (2) technical space bridge for representation in the technical space of the tool. – Each part is a separate, self-contained module, which can be developed, changed and tested independently. This decomposition into two separate modules allows us to parallelize the work on the two transformations and reduce development time. It also allows the two transformations to evolve independently without affecting each other. – As the HiP-HOPS tool is evolving, it is being updated and with it its external data representation. The tool introduced an XML representation of its input data. When integrating this new version of HiP-HOPS we needed to adapt our transformation. Due to the modular organization of our model transformation the necessary changes could be localized to the technical space bridge only, leaving the structural bridge unaffected, thus ensuring maintainability and evolvability. – The solution allows us to select an appropriate tool for each concern. A declarative model-to-model transformation language was chosen for the structural bridge and a model-to-text transformation languages for the technical space bridge. – Due to the intermediate metamodel, which is a subset of the tool data, the transformation is comparably simple. Since we chose appropriate tools for each steps, the resulting model transformation source code is simple and concise. When we compare these properties to the goals put forward in section 2, our approach is able to fulfill them. 6.1
Future Work
We plan to connect the transformations described in our case study with tool integration infrastructure such as ModelBus. Also, we would like to create a tool chain, in which we can replace a specific tool by another tool. The reduce the dependence on a particular tool and mitigates the risk of vendor lock-in.
Acknowledgements We would like to thank Jad El-khoury for his comments on earlier versions and Alex Schenkman for his programming efforts. This work has been funded by the European Commission under grant agreement no. 224442.
References 1. Matthias Biehl, Chen DeJiu, and Martin T¨ orngren. Integrating Safety Analysis into the Model-based Development Toolchain of Automotive Embedded Systems. In Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), pages 125+, April 2010. 2. Jes´ us Cuadrado and Jes´ us Molina. Modularization of model transformations through a phasing mechanism. Software and Systems Modeling, 2009. 3. 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. 4. K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches. IBM Systems Journal, 45(3):621–645, 2006. 5. Sven Efftinge, Peter Friese, Arno Haase, Clemens Kadura, Bernd Kolb, Dieter Moroff, Karsten Thoms, and Markus Voelter. openArchitectureWare User Guide. Technical report, openArchitectureWare Community, 2007. 6. C. Hein, T. Ritter, and M. Wagner. Model-Driven Tool Integration with ModelBus. In Workshop Future Trends of Model-Driven Development, 2009. 7. Philipp Huber. The Model Transformation Language Jungle - An Evaluation and Extension of Existing Approaches. Master’s thesis, Technische Universit¨ at Wien, May 2008. 8. F. Jouault, F. Allilaire, J. B´ezivin, and I. Kurtev. ATL: a model transformation tool. Science of Computer Programming, 72:31–39, June 2008. 9. Gabor Karsai, Andras Lang, and Sandeep Neema. Design patterns for open tool integration. Software and Systems Modeling, 4(2):157–170, May 2005. 10. Anneke Kleppe, Jos Warmer, and Wim Bast. MDA Explained: The Model Driven Architecture—Practice and Promise. Addison-Wesley, 2003. 11. Mathworks. Introducing Matlab 7 and Simulink 6. Signal Processing Magazine, IEEE, 21(5):122, September 2004. 12. Tom Mens and Pieter Van Gorp. A Taxonomy of Model Transformation. Electr. Notes Theor. Comput. Sci, 152:125–142, 2006. 13. Yiannis Papadopoulos and John A. McDermid. Hierarchically Performed Hazard Origin and Propagation Studies. In F. Massimo, K. Karama, and P. Alberto, editors, SAFECOMP, volume 1698 of LNCS, pages 139–152. Springer, 1999. 14. Carl-Johan Sj¨ ostedt, Jianlin Shi, Martin T¨ orngren, David Servat, DeJiu Chen, Viktor Ahlsten, and Henrik L¨ onn. Mapping Simulink to UML in the Design of Embedded Systems: Investigating Scenarios and Structural and Behavioral Mapping. In OMER 4 Post Workshop Proceedings, April 2008. 15. 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.
Appendix B
A Domain Specific Language for Generating Tool Integration Solutions Matthias Biehl, Jad El-Khoury, Frederic Loiret, and Martin T¨ orngren in 4th Workshop on Model-Driven Tool & Process Integration (MDTPI2011) at the European Conference on Modelling Foundations and Applications (ECMFA 2011) June 2011
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 [23]. 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 [25]. 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 [26]. The scope of tool integration is defined using the following dimensions [23, 24]: 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 [10] or the Jazz Foundations [9]. The OSLC initiative (Open Services for Lifecycle Collaboration) aims to standardize different components of tool integration solutions [21]. 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) [8] 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 [15]. A closely related approach are ontologies, where tools map their data to an ontology, which defines the relationships between the tool-specific ontology elements [14, 13, 17]. 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 [15]. 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 [10]. – 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 [16]. 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, naming similarities between metamodel elements or a combination of different metrics [7]. (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 [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. 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 [11]. Similar to our approach, EAI identifies several common integration patterns that can be used to both reason about integration and to quickly construct integration solutions. The patterns can be put in relation with each
A Domain Specific Language for Generating Tool Integration Solutions
9
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 [12]. Languages such as BPMN [20], BPEL [18] and SPEM [19] 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 [22] 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. 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.
References 1. Eric Armengaud, Markus Zoier, Andreas Baumgart, Matthias Biehl, DeJiu Chen, Gerhard Griessnig, Christian Hein, Tom Ritter, and Ramin T. Kolagari. Model-
10
2.
3.
4.
5.
6.
7.
8. 9. 10. 11.
12. 13.
14.
15. 16.
Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, Martin T¨ orngren based Toolchain for the Efficient Development of Safety-Relevant Automotive Embedded Systems. In SAE 2011 World Congress & Exhibition, April 2011. 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. 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. 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. 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. 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. 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. Springer-Verlag, 2008. Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. Randall Frost. Jazz and the Eclipse way of collaboration. IEEE Software, 24(6):114–117, November 2007. C. Hein, T. Ritter, and M. Wagner. Model-Driven Tool Integration with ModelBus. In Workshop Future Trends of Model-Driven Development, 2009. Gregor Hohpe and Bobby Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, 1 edition, October 2003. Claus Ibsen and Jonathan Anstey. Camel in Action. Manning Publications, January 2011. 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. 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. Gabor Karsai, Andras Lang, and Sandeep Neema. Design patterns for open tool integration. Software and Systems Modeling, 4(2):157–170, May 2005. 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.
A Domain Specific Language for Generating Tool Integration Solutions
11
17. 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. 18. OASIS. OASIS Web Services Business Process Execution Language (WSBPEL) TC. Technical report, ”OASIS”, April 2007. 19. OMG. Software & Systems Process Engineering Metamodel Specification (SPEM). Technical report, ”OMG”, April 2008. 20. OMG. Business Process Model And Notation (BPMN). Technical report, ”OMG”, January 2011. 21. OSLC Core Specification Workgroup. OSLC core specification version 2.0. Technical report, Open Services for Lifecycle Collaboration, August 2010. 22. 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. 23. I. Thomas and B. A. Nejmeh. Definitions of tool integration for environments. Software, IEEE, 9(2):29–35, March 1992. 24. 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. 25. M. Wicks and R. Dewar. A new research agenda for tool integration. Journal of Systems and Software, 80(9):1569–1585, September 2007. 26. M. N. Wicks. Tool Integration within Software Engineering Environments: An Annotated Bibliography. Technical report, Heriot-Watt University, 2006.
Appendix C
On the Modeling and Generation of Service-Oriented Tool Chains Matthias Biehl, Jad El-Khoury, Frederic Loiret, and Martin T¨ orngren, in Journal of Software and Systems Modeling, Vol. 275 Online First September 2012 c
2012 Springer. Reprinted with permission.
Softw Syst Model DOI 10.1007/s10270-012-0275-7
THEME SECTION PAPER
On the modeling and generation of service-oriented tool chains Matthias Biehl · Jad El-Khoury · Frédéric Loiret · Martin Törngren
Received: 7 October 2011 / Revised: 2 June 2012 / Accepted: 13 July 2012 © Springer-Verlag 2012
Abstract Tool chains have grown from ad-hoc solutions to complex software systems, which often have a serviceoriented architecture. With service-oriented tool integration, development tools are made available as services, which can be orchestrated to form tool chains. Due to the increasing sophistication and size of tool chains, there is a need for a systematic development approach for service-oriented tool chains. We propose a domain-specific modeling language (DSML) that allows us to describe the tool chain on an appropriate level of abstraction. We present how this language supports three activities when developing service-oriented tool chains: communication, design and realization. A generative approach supports the realization of the tool chain using the service component architecture. We present experiences from an industrial case study, which applies the DSML to support the creation of a service-oriented tool chain. We evaluate the approach both qualitatively and quantitatively by comparing it with a traditional development approach. Keywords Domain specific modeling language · Generative approach · Service-oriented architecture · Tool integration 1 Introduction The development of software-intensive systems1 requires tool support for the different phases of the system life cycle. 1
A system consisting of heterogeneous parts, such as hardware, software and mechanical parts, where software has an important role.
Communicated by Dr. Juan M. Vara, Mike Papazoglou & Il-Yeol Song. M. Biehl (B) · J. El-Khoury · F. Loiret · M. Törngren Embedded Control Systems, Royal Institute of Technology, Stockholm, Sweden e-mail:
[email protected]
To allow for an efficient development process, the involved tools need to be integrated. 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 an automated tool chain that takes care of the necessary data exchange and the possibility to create trace links between the tools, but this tool chain needs to be built manually for each development process. 1.1 Gaps and challenges It is more and more recognized that tool chains can help to improve the efficiency of software development [49], which leads to the construction of new tool chains. The construction of tool chains deals with the following challenges. Service orientation: Globally distributed software development teams need tool chains that are flexible, distributed and tailored to the development process [23]. To deal with this new requirement, modern tool chains apply the principles of service-oriented computing [20,22]. Service-oriented computing is concerned with the integration of distributed services [21]. Development tools expose their functionality and data as services. A tool chain realizes the integration of tools by orchestrating the exposed services of the tools. To manage the increasing complexity of both the service-oriented technology and the growing size of tool chains, the need for systematic modeling and engineering of service-oriented tool chains arises. Description at an appropriate level of abstraction: Design of service-oriented solutions for the domain of tool integration is a challenge. When working with industrial partners on service-oriented tool integration, we noticed a gap between existing general purpose modeling languages and concepts from the domain of tool integration: General
123
M. Biehl et al.
purpose modeling languages, such as UML with profiles for service-oriented architecture (SOA), have been proposed for modeling and engineering general service-oriented solutions [6,21,27,39]. However, general modeling languages are too abstract and the SOA-related profiles require a technical understanding of the service-oriented technology. Lowlevel concepts from the application domain offered by tool integration frameworks [20,22], are too detailed and depend on a certain technology. We see a challenge in describing modern tool chains on an adequate level of abstraction. Tailoring: In general, a tool chain supports a development process by automating integration-related tasks of the process. Traditional tool chains support simple connections between a small number of tools, such as the connection between editor, compiler and linker. They can thus be realized by a pipe and filter architecture [45]. Modern tool chains need to support development processes that are model-based, iterative and include a larger number of tools, which are used in different phases of the system lifecycle. Tool chains for these new processes have an architecture with more components and more complex relationships. There is a lack of architectural concepts for tool chains that can be used for tailoring the tool chain, so it is aligned to the development processes and the set of development tools. Efficient construction: Despite recent innovations in this field, for example by tool integration frameworks [20,22], the development of tool chains requires a lot of manual implementation work. In addition, service-oriented solutions require a number of configuration files with complex dependencies between them. Techniques to improve the efficiency of building service-oriented tool chains are needed. In summary, we see gaps in both describing tool chains on an adequate level of abstraction and efficiently building service-oriented tool chains. 1.2 Objectives and solution The goal of this work is to provide tools and methods to describe and build service-oriented tool chains. It requires us to overcome the challenges identified in Sect. 1.1. We set the following objectives for our work and will use them to evaluate our approach: 1. Objective 1—support for designing tool chains in a systematic and structured way: The building blocks of tool chains and their composition need to be identified and described on an appropriate level of abstraction. 2. Objective 2—support for communication and documentation of tool chains in a concise and graphical way: Since it is difficult to get a tool chain accepted if the users are not involved [14], the overall architecture of the new tool chain needs to be communicated to potential users.
123
3. Objective 3—support for tailoring tool chains: Each company uses a different development process and development tools. Since the tool chain is intended to support the development process, it needs to be aligned to the process and fit the set of tools. 4. Objective 4—support for realizing service-oriented tool chains: Tool chains need to be efficiently realized as software solutions. To meet these objectives, we propose a domain specific modeling language (DSML) [31] for tool chains. This language uses domain concepts to describe a tool chain on the architectural level. The language provides a basis for designing, tailoring and communicating tool chains with its graphical syntax and defined semantics. The growing complexity of tool chains needs to be managed both at runtime of the tool chain and at design time of the tool chain. Our approach aims at supporting both runtime and design time aspects: While a DSML and generators can provide design time support by complexity management and a structured development approach, the service-oriented architecture (SOA) [17] provides runtime support through flexibility, distribution and platform independence. 1.3 Delimitations In this section we clarify some delimitations of the work: – Tool integration consists of five aspects [47]: Control integration, data integration, process integration, platform integration and presentation integration. We exclude the aspect of presentation integration. – Tool integration as in co-simulation is not relevant for this article. – We have evaluated the approach in the area of embedded software development, but it might be applicable in other areas of software development as well. 1.4 Overview This article is structured as follows: In Sect. 2 we introduce service-oriented tool integration. In Sect. 3 we analyze the domain of tool integration. This allows us to propose a modeling language for tool integration. In Sect. 4 we present how to generate a service-oriented implementation from instances of the modeling language. In Sect. 5 we evaluate the applicability of the modeling language and the effectiveness of the generators in an industrial case study. In the remaining sections we present related work, future work and a reflection on possible implications of our work on industrial practice.
On the modeling and generation of service-oriented tool chains
2 Service-oriented tool integration The goal of tool integration is building tool chains or integrated engineering environments out of isolated development tools [13]. The assumption of the research community is that using an engineering environment with several integrated tools increases productivity and product quality [49]. For a broader overview of the literature on tool integration we refer to the annotated bibliographies of Brown [13] and Wicks [50]. We define the term tool chain as the software that integrates a set of development tools. The scope of tool integration is defined using the following five dimensions [47]: data integration shares the data produced by different tools and manages the relationship between the data objects, 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. In global engineering settings, the development tools are distributed. As a result, tool chains become distributed systems that are potentially realized on heterogeneous platforms. Service-oriented tool integration applies the principles of SOA to solve the challenges of tool integration. This has implications not only for several aspects of integration, first of all platform integration, but also for data and control integration. Service-oriented tool integration provides platform independence, since the underlying web-technology is available on multiple platforms. This technology also provides the possibility for distributed tool chains. At runtime, serviceoriented tool chains provide flexibility, extensibility and composability through loosely coupled services. Service-oriented tool integration is built on two fundamental ideas: – Tool adapters expose services of legacy development tools: a wrapper for each development tool is built that exposes the data and functionality of the tool as services. This wrapper is called a service-oriented tool adapter. – Orchestration of services: service-oriented tool chains are realized by orchestrating the services provided by service-oriented tool adapters. Modern tool integration frameworks provide libraries and APIs for building service-oriented tool chains. Examples are ModelBus [22] or Jazz Foundations [20]. However, it requires a lot of manual engineering effort to develop, configure and deploy service-oriented tool chains with these frameworks. In order to be reusable, the tool chain should adhere to standards and conventions as far as possible. Open Services for Lifecycle Collaboration (OSLC) [41] is an industry association that aims at standardizing different parts of
service-oriented tool integration solutions, such as directory services, data formats and even data structures. OSLC uses a RESTful architecture [19] for the services and provides a specification for accessing the tool data. 3 TIL-a DSML for tool chains The cornerstone of our approach is the Tool Integration Language (TIL), a domain-specific modeling language for tool chains. TIL is intended to serve several purposes and a subset of them will be explored in this article. To put the TIL approach into perspective, we present all purposes of models built with the language: (1) Communication and documentation: TIL models can be used to communicate an envisioned or already existing tool chain to different stakeholders. For fulfilling this purpose, TIL offers a graphical syntax and an interactive modeling workbench. (2) Design and specification: TIL models can be used as a blueprint for constructing service-oriented tool chains. For fulfilling this purpose, TIL offers concise and welldefined semantics for both the tool adapters and their orchestration. (3) Analysis: TIL models can be used to predict nonfunctional properties (such as consistency, complexity, accuracy) of the tool chain. For an envisioned tool chain, these properties can be assessed before the tool chain is implemented. For an existing tool chain, the properties can provide guidance for improvements of the tool chain. (4) Automated generation: TIL models can be used as an executable specification of a tool chain. For this purpose, a generator maps each concept of TIL to a component in the service-oriented implementation of the tool chain. (5) Evolution: TIL models can be used to support the evolution of tool chains. Tool chains need to co-evolve with new versions of the tools they integrate. The focus of this article is on (1) communication (2) design and (4) automated generation, while (3) analysis and (5) evolution are part of future work. In Sect. 3.1 we introduce a simple scenario for exemplifying the type of tool chain we want to describe with TIL. In order to specify TIL, we perform a systematic domain analysis of tool integration. In Sect. 3.2 we use the domain analysis to identify relevant language concepts for TIL. In Sect. 3.3 we introduce the language concepts and their semantics. 3.1 Example In the following we provide a simple scenario that illustrates some requirements for the type of tool chains we would like to describe with TIL:
123
M. Biehl et al.
This example tool chain is intended to support the development process for a safety critical embedded system. The embedded system is designed in MATLAB/-Simulink2 and the model files are stored in a SVN repository. Safety regulations require the company to perform fault tree analysis on the Simulink models. This analysis is supported by a separate tool with its own data format. For this reason the Simulink model needs to be translated to the input format of the analysis tool. Moreover, since the Simulink model is developed iteratively, frequent cycles of translation and analysis are required. An automated tool chain can support this development process: The tool chain listens for commit events on the SVN repository, automatically transforms the committed Simulink model to the input format of the analysis tool, triggers the execution of fault tree analysis and notifies the engineer about the result. Industrial tool chains can become larger and more complex than this example. To be able to describe such tool chains concisely and at the same time not get lost in implementation details, we propose an adequate modeling language for describing the architecture of the tool chain. 3.2 Domain analysis for the identification of TIL concepts In this section we perform a domain analysis [16] of the area of tool integration, in order to identify domain concepts, which are candidates for language concepts of TIL. We highlight the candidates in italic. In our assessment we employ a top-down approach to decompose tool integration into several high-level integration styles and into several integration aspects [4,47], such as data, control, platform and process integration. 3.2.1 Tool integration styles Tool integration solutions follow certain architectural styles, as identified in [30]. We introduce these styles here to analyze them and identify common elements in them. The goal is to design TIL, so it can be applied for realizing solutions with different integration styles. – Integrated datamodel: Tools map their data onto a common integrated repository with a unified datamodel [30]. A closely related approach are ontologies, where tools map their data to an ontology, which defines the relationships between the tool-specific ontology elements [28,29,34]. – Process flows: Tools are connected to an integration bus and a workflow describes the interactions between different tools [30]. 2
http://www.mathworks.com/products/simulink.
123
From this analysis we extract the domain concept of a tool chain. This concept should be flexible enough to support the different integration styles. 3.2.2 Data integration Data integration is concerned with managing the relationship of data from different tools. The degree to which the data are coupled can vary between different integration solutions: on one side there is the need for the data of different tools to be tightly integrated. Data need to be exchanged between different tools. On the other side there is the need for loosely integrated data. Data of different tools need to be made accessible for creating links or traces between them. As detailed in [12], there are several technological solutions for the needs of data integration: tool adapters make tool data available in the technical space for integration; they are thus the endpoints for data flow. The technical space [35] for integration provides the common ground for a unified representation of data, e.g. XML or RDF. Structural differences between the data of different tools needs to be resolved. Transformations accomplish this by mapping corresponding data elements. Transformations are a means to realize tight integration. Trace links allow linking data from different tools. Trace links are a means to realize loose integration. Development artifacts are usually stored in repositories, which can be regarded as tool adapters, since they are the endpoints of data flow. From this analysis we extract the domain concepts tool adapter, repository, transformation and trace. 3.2.3 Control integration Control integration allows tools to notify users, activate tools, invoke a specific functionality in another tool, trigger data exchange or trigger the creation of a trace. Notification of a user can be as simple as sending an email to the user. Activation of a tool means starting the tool. Invoking a functionality in a tool means that some feature or function of a tool is executed. While data integration is concerned with establishing the ability to create relationships between tool data, control integration is concerned with the execution of the data transfer or the creation of trace links. Similar to data integration, there is a need for a common technical space for integration, which allows unified access of control functionality from different tools, e.g. by a common communication protocol. A tool adapter makes the tool functionality available in the common technical space. Moreover, we can distinguish two ways of modeling control flow: sequential and concurrent control flow. Sequential control flow defines an overall order of actions. Concurrent control flow is event-based and defines dependencies between events and actions.
On the modeling and generation of service-oriented tool chains
From this analysis we extract the need for expressing concurrent control flow by control channels and sequential control flow by sequencers. 3.2.4 Platform integration and process integration The aspects of platform and process integration are crosscutting to control and data integration; they affect all previously identified concepts. Platform integration allows tools to be integrated across different hardware and software systems and even across remote machines. Data and functionality need to be uniformly accessible in a common technical space for integration. If the tool adapter is deployed on a remote machine, the services offering data and functionality need to be discovered. From this analysis we extract the additional domain concept of a discovered tool adapter. Process integration allows for the combination of process management with information from the development tools and the alignment between the process and the tool chain. Processes are related to the data-flow and control-flow between tools and the users associated with the activities. Process integration is concerned with the coordination, com-
bination and scripting of integration functionality, such as invocation, activation, notification, transformation and traces across several tools. From this analysis we extract the additional domain concept of a user and the need for composing the concepts from data and control integration. 3.3 Overview of TIL concepts Based on the concepts identified by the domain analysis in the previous section, we propose the Tool Integration Language (TIL). We design TIL in such a way that the identified domain concepts are compatible with each other and can be composed to form tool chains. The language concepts of TIL can be grouped into components and channels, where components can be connected by channels. We distinguish between several types of components: tool adapters, repositories, tool Chains, sequencers and users. We distinguish between several types of channels: control channels, data channels and trace channels. We introduce TIL in terms of abstract syntax, concrete syntax and semantics. The abstract syntax (metamodel) of TIL is presented as a class diagram in Fig. 1. The graphical concrete syntax of each language concept is introduced
Fig. 1 The TIL metamodel represented as a class diagram
123
M. Biehl et al.
Fig. 2 A simple TIL model illustrating the graphical syntax of the language concepts
by a simple example in Fig. 2, where the circled numbers ..➆ identify the language concepts. The semantics of TIL concepts is briefly introduced in the following: – A tool chain provides a container for all other elements. Tool chains can be composed hierarchically. – A tool adapter ➀ exposes both functionality and data of an integrated development tool. Exposing the functionality of a tool enables control integration, exposing the data of a tool enables data integration. A tool adapter makes two kinds of adaptation: (1) It adapts between the technical space of the tool and the technical space of integration for both data and functionality. (2) It adapts the structure of data and the signature of services available in the development tool to the data structure and service signature defined by the tool adapter metamodel. A tool adapter metamodel specifies the structure of the data and the signature of the functionality exposed by the tool adapter. The tool adapter metamodel has the role of an interface description. It can be specified by the architect of the tool chain; it does not necessarily need to be equivalent to the tool data, but it provides a simplified view on the tool data and functionality. The specification of tool adapter metamodels requires manual engineering work. An important design decision taken during the specification of the tool adapter is the scope and granularity of the exposed data. This decision depends on the role of the tool within the tool chain. Our experiments on specifying tool adapter metamodels of different granularity can be used as a guideline [10] for creating an adequate tool adapter metamodel. Further, we distinguish between four types of tool adapters: – A generated tool adapter is a tool adapter, whose service implementation is generated based on the specification provided by the tool adapter metamodel. We use the basic metamodeling technology provided by EMF to describe the tool adapter metamodel. The tool data are described in one EPackage as a directed graph, where the nodes are EClasses with EAttributes, and the links between nodes are EReferences. The services of the tool are described as EOp-
123
erations with EParameters in a separate EPackage and EClass. – A discovered tool adapter is a tool adapter that is already deployed as a service at the time of tool chain design. To bind this tool adapter to a tool chain, the designer specifies the deployment URL. Automated service discovery retrieves the details of the services as described in [11]. – A binary tool adapter is a tool adapter that has been developed previously and is shipped as a binary. It can be used as a library component. – A repository ➆ is a tool adapter that provides storage and version management, e.g. a tool adapter for SVN. Data can be read and written from a repository by a data channel. In addition each repository can expose services, e.g. for accessing logs or older versions. – A control channel ➁ describes concurrent control flow. Control channels specify the source and target component, the source_service in the source component that triggers the control channel and the target_service in the target component that is called by the control channel. This allows for process integration through eventdriven programming, where the events are the execution of the source_service. The control flow starts after the source_service has been executed, the control channel then calls the target_service. A control channel only executes if its guard condition evaluates to true. In the guard expression we can reason over entries in the execution trace of the tool chain, i.e. what happened before in the tool chain. For a more detailed description, the reader is referred to [8]. – A sequencer ➂ allows for sequential control flow. It executes a sequence of services in a defined order. Any of the incoming control channels triggers the execution of the sequencer, which then executes all outgoing control channels in the predefined order with blocking-call semantics. – A user ➃ is a representative for a real tool chain user. It is used to describe the possible interactions of the real users with the tool chain. Outgoing control channels from the user denote tool chain services that are invoked by the user. Incoming control channels to a user denote a notification sent to the user, e.g. by e-mail. – A data channel ➄ transfers data between tool adapters. A model transformation can be attached to a data channel to resolve structural heterogeneities between the data of the tool adapters. It is executed at runtime of the tool chain. Data channels specify the source and target tool adapter, the source_service from the source tool adapter for extracting tool data and the target_service in the target tool adapter for injecting the transferred tool data. To execute a data channel at runtime, it needs to be activated by a control channel. As a byproduct of the data exchange
On the modeling and generation of service-oriented tool chains
over the data channel, a trace may be created if a trace channel between the same source and target tool adapters is present. – A trace channel ➅ describes the possibility to establish trace links between tool data at runtime. At design time one can specify the type of data that can be linked by traces. The trace channel connects a source tool adapter and a target tool adapter. The endpoints of the traces can be restricted to a subset of the tool data by specifying the source_service and target_service. At runtime of the tool chain, these services provide a list of all the source and target elements that are offered as endpoints for specifying a trace. The update strategy of the trace channel specifies how tool data that are linked by a trace is treated when source or target data change. For a list of predefined update strategies, the reader is referred to [8].
introspection of the deployed components and reconfiguration at runtime. We found that both OSLC and SCA are appropriate technologies for realizing service-oriented tool chains. OSLC provides a technological basis that conforms to industry conventions for tool integration. SCA allows us to define RESTful services and bindings, which makes it possible to implement a tool chain according to OSLC. At the same time, the implementation of service-oriented architectures imposes an overhead, as it requires additional source code and a number of configurations, complex configuration dependencies and annotations. To handle this overhead efficiently, we generate the source code and configurations by MDD techniques and generators. We will show that a TIL model contains the necessary information to generate the implementation automatically. 4.2 Overview of the generation process
4 Generating service-oriented tool chains with TIL To support the development of tool chains, we define a generator that converts any correct TIL model into an executable implementation of a service-oriented tool chain. In Sect. 4.1 we introduce the structure of the tool chain implementation, which is the end result of the generation. Section 4.2 provides an overview of the generator for each language concept. In Sect. 4.3 we introduce a process for developing tool chains with TIL. In Sect. 4.4 we clarify which parts of the tool chain are generated automatically and which parts need to be created manually. In Sect. 4.5 we introduce the tool support for TIL. 4.1 The implementation of the tool chain In this section we introduce the structure of the implementation, which is produced by the generator. With TIL it is possible to describe a service-oriented tool chain independently of a specific tool integration framework or technology. It is conceivable that different generators can produce implementations with different integration technology from the same TIL model. Moreover, TIL is not intended to replace any of the existing tool integration frameworks such as ModelBus [22] or Jazz [20]. Instead, the language is a complement to these technologies. We have chosen to generate an implementation that conforms to the principles of the Open Services for Lifecycle Collaboration (OSLC), since it is an industrial initiative for creating conventions in tool integration. We have chosen to use the Service Component Architecture (SCA) [6], a component model for implementing and composing heterogeneous services. We use the SCA implementation FraSCAti [44], which manages the web server infrastructure, produces the necessary glue code and also provides remote deployment,
The generator maps each language concept of TIL to a part of the implementation of the service-oriented tool chain. The executable specification is heterogeneous, since it uses Java, model transformations, SCA and OSLC for representing the different language concepts of TIL. The generator ensures that the produced source code of the tool chain is internally consistent. The generation process is depicted in Fig. 3. In the following we give an overview of the generation for each TIL language concept: 4.2.1 Generator for tool adapters The implementation of a tool adapter consists of an external and an internal part, as illustrated in Fig. 4. The external part has an interface that provides the tool data and functionality in a technical format, which is common to all tool adapters. This interface is service-oriented, conforms to OSLC and exposes the data and functionality of the tool as services. The interface ensures that the other tool adapters in the tool chain can connect to the services of different tools in a uniform manner. The internal part of the tool adapter realizes the services by communicating with the tool, through the API of the tool, tool parameters or the input file. We provide an overview of the generation process; more technical details on the generation of tool adapters are available in [10]. The external part of the tool adapter can be completely generated from the information available in the tool adapter metamodel. In the following we explain how the servicerelated code is generated: – We generate Java code with RESTful annotations (according to JAX-RS [43]) for the external interface of the tool adapter. Code skeletons for realizing data access
123
M. Biehl et al.
Fig. 3 Overview of the TIL generators for different language concepts and the generated artifacts
model. A converter serializes the intermediate data model to different data formats (EMF/XMI3 , OSLC/RDF4 ). In the following, we explain how the OSLC-related code is generated: – OSLC Resource Shapes are generated, which provide the possibility for introspection by describing the structure of each metaclass in the tool adapter metamodel. – OSLC Service Providers are generated, which provide a directory service for all services and all resources that are served by this tool adapter. – An OSLC Service Catalog is generated as an entry point for the directory service of this tool adapter.
Fig. 4 Architecture and context of the tool adapter
are generated for each metaclass of the tool adapter metamodel and for each HTTP method (GET, POST, PUT, DELETE). Code skeletons to access the functionality of the tool are generated according to the tool adapter metamodel. – We generate an intermediate Java data model for handling the tool data. The Java data model is generated from the tool adapter metamodel. The tool adapter extracts the data from the tool and represents it in the intermediate data
123
3
XML Metadata Interchange.
4
Resource Description Framework.
On the modeling and generation of service-oriented tool chains
The internal part of the tool adapter can be partially generated. A template is chosen, which describes the interface technology used by the tool: – Command-line tool: The template provides a library of functions to start a command-line tool, provides the input data as a command line argument and to read the output data from the console or a file. – Eclipse plugin tool: The template realizes the tool adapter as an Eclipse plugin. – RMI based tool: The template provides a library to access functionality and data via RMI. – WSDL based tool: The template provides a library to access functionality and data via a web service described in WSDL.
4.2.3 Generator for trace channels The source code for the trace channel can be generated completely. For each trace channel, we generate the Java code for extracting data from the source and target tool adapter and a graphical interface for the tool chain user to create trace links at runtime of the tool chain. In addition, we generate the Java annotations for the SCA component and SCA service. 4.2.4 Generator for control channels and sequencers All control channels and sequencers together contribute to the generation of an event-driven implementation of the control flow. Based on this information, we can completely generate the Java code for the control-flow of the tool chain. 4.2.5 Generator for tool chains
The remaining internal part needs to be manually implemented, as it is individual to each tool. Protected regions of the model transformation tool are used to protect this manually added code from being overwritten, when the external part is re-generated. 4.2.2 Generator for data channels The source code for the data channel can be generated completely from the information available in a TIL model. – We generate the Java code for extracting the data using the source_service in the source tool adapter, instantiating and calling the model transformation engine with appropriate parameters and injecting the result of the model transformation into the target tool adapter using the target_service. We support a number of model transformation engines, such as ATL,5 Acceleo,6 Henshin7 and QVT-operational.8 The Java code exposes services specified by RESTful annotations (according to JAX-RS). – We generate code for transparently handling different data formats, such as EMF/XMI and OSLC/RDF. The conversion between those technical spaces are defined both for data (OSLC Resources) and for metadata (OSLC Resource Shapes). Conversions between EMF and RDF can be defined by overcoming several semantic differences between the data formats [24]. – We generate the Java annotations for the SCA component and SCA service. 5
http://eclipse.org/atl.
6
http://eclipse.org/acceleo.
7
http://eclipse.org/modeling/emft/henshin.
8
http://eclipse.org/m2m.
For the tool chain we generate an SCA composite, which includes all SCA components that were generated for the TIL concepts above. In summary, the tool chain and its components can be completely generated, except for the internal part of the tool adapters. 4.3 Development of tailored tool chains with TIL In this section we show how we can use the generic language concepts and the generators of TIL to build a tool chain that is tailored to the required set of development tools. In Fig. 5 we illustrate the process9 for developing a tool chain with TIL using the SPEM [38] notation. 1. In the conceptual design phase of the tool chain, an initial TIL model is created. The TIL model conveys which tool adapters exist and how they are connected for realizing data flow and control flow. 2. In the detailed design phase, the initial TIL model is refined by adding tool adapter metamodels and model transformations. A tool adapter metamodel is attached to each tool adapter in the TIL model; it describes the data and functionality exposed by the adapter. A model transformation is attached to each data channels in the TIL model; it describes the translation of data from the source tool to the target tool. This yields a completely specified TIL model. 3. The first step of the implementation phase of the tool chain is the automated code generation from the TIL model. The TIL generator creates code skeletons and configuration files for the tool adapters, as well as complete 9
We explicitly differentiate between the tool chain development process that creates a tool chain and the product development process, which is supported by the tool chain.
123
M. Biehl et al.
Fig. 5 Process for developing a tailored tool chain with TIL, illustrated using the SPEM [38] notation
source code for the other TIL language concepts used in the model. 4. The generated code skeletons for the tool adapters need to be extended manually to create the final tool chain implementation.
ator is built as described in Sect. 4 and consists of different kinds of generator components, for example, Java-based generators and Acceleo11 model-to-text transformations. These model transformations are executed by the TIL generator at design time of the tool chain.12
4.4 Automated generation and manual implementation 5 Case study The code generators for TIL are generic and can thus be reused for realizing tool chains from different TIL models. Input to the generation is a complete TIL model, which contains manually specified tool adapter metamodels for each tool adapter and model transformations for each data channel. The generator produces code based on both the properties of each language concept (such as the metamodel for tool adapters) and the composition of the different language concepts in the TIL model. The generators create a part of the implementation of the tool chain and thus reduce the amount of manual work. While the external part of the tool adapter is generated automatically, the internal part needs to be implemented manually. For all other TIL language concepts, the source code can be completely generated. In Sect. 5.4 we quantify how much code can be generated automatically and how much code needs to be added manually. 4.5 The TIL workbench and generator To support the tool chain designer in building a new tool chain with TIL, we have implemented the TIL Workbench (see Fig. 6). It consists of the TIL language defined as an EMF metamodel, a graphical modeling environment for TIL in Eclipse, and the TIL generator. The TIL Workbench enforces the abstract syntax and ensures that TIL models are internally consistent. The graphical modeling environment for TIL is based on Eclipse and the Graphiti10 framework. The gener10
http://www.eclipse.org/graphiti.
123
In this section we validate the TIL approach through its application in an industrial case-study. We follow the process for developing tool chains with TIL as introduced in Sect. 4.3 and stepwise apply TIL to build an executable, service-oriented implementation of the tool chain for the industrial case. In Sect. 5.1, we build a conceptual model of the tool chain for the purpose of documentation and communication with the stakeholders. In Sect. 5.2, we refine the TIL model with tool metamodels and model transformations for detailed design and specification of the tool chain. We use the refined TIL model for automated generation and implementation of the tool chain. In Sects. 5.3, 5.4 and 5.5 we perform both a qualitative and quantitative evaluation of the effectiveness of the TIL generators.
5.1 TIL for conceptual design In this section we evaluate the use of TIL for conceptual design of a tool chain. The resulting TIL model can be used for communication with stakeholders and for documentation purposes. We describe the industrial case in Sect. 5.1.1 and evaluate the application of TIL in Sect. 5.1.2.
11 12
http://eclipse.org/acceleo.
These model transformations are not to be confused with the model transformations in the data channels that are executed at runtime of the tool chain.
On the modeling and generation of service-oriented tool chains
Fig. 6 The TIL Workbench
5.1.1 Description of the industrial case The case study is provided by our industrial partner, who develops embedded systems characterized by tightly coupled hardware and software components: The application logic is partitioned into software running on a Freescale PowerPC and hardware logic realized by a Xilinx FPGA. The scenario requires a number of tools for modeling, simulation, analysis, code-generation and coding. Today, no tool chain is in place to support the development process and tool data are manually re-entered in the involved tools, for example, a new Simulink model is manually created for each relevant UML model. The following description of the development process is the basis for the envisioned tool chain, which supports the development process: – The requirements of the embedded system are captured in the IRQA13 tool. – A system architect designs a UML component diagram in the Eclipse-based Papyrus UML14 and uses the tracing 13
http://www.visuresolutions.com/irqa-web.
14
http://www.eclipse.org/papyrus.
capability of the tool chain to create trace links across tool boundaries between the components modeled in the UML tool and the requirements managed in the IRQA tool. – An engineer refines the UML model with behavioral and fault propagation models using the GUI of the development tool and commits the model to the repository. Every time a new version of the UML model is committed, the tool chain executes a transformation of the UML model to the input format of the fault tree analysis tool HiP-HOPS [42] and executes HiP-HOPS. Also, a model transformation creates a MATLAB/Simulink model that mirrors the structure of the UML model. When the results of the fault tree analysis are satisfactory, i.e. there are no single points of failure, the control engineer manually extends the Simulink model. – Once the work on Simulink is complete, the engineer triggers a function in the tool chain, which starts the code generation functionality of Simulink to generate C code and transfers this code into the WindRiver15 tool.
15
http://www.windriver.com.
123
M. Biehl et al.
Fig. 7 Industrial tool chain described in TIL
– The application engineer triggers a function in the tool chain to transform the UML model into a skeleton of an IEC-61131-316 conform design. The application engineer manually refines the design in the ControlBuilder tool. – The application engineer triggers a tool chain function to transfer the source code from ControlBuilder and WindRiver into the Freescale development tool. The application engineer manually integrates the code in Freescale and produces binaries for a specific micro controller. – The hardware engineer uses the Simulink model to produce VHDL code, and uses the tool chain to transfer it to the Xilinx ISE17 tool. The engineer refines the VHDL code in the Xilinx tool and synthesizes an FPGA configuration that can be downloaded on the chip. 5.1.2 Applying TIL for conceptual design Modeling the envisioned tool chain in TIL resulted in the model depicted in Fig. 7. All parts of the envisioned tool chain can be expressed with TIL. The tool chain integrates eight development tools for embedded systems and several supportive tools such as a repository and model transformation engines. The tool chain is used by four different engi16
http://www.plcopen.org.
17
http://www.xilinx.com/ise.
123
neers. We do not intend to model all interactions between the engineers and the tools, but only those that are automated for tool integration. The engineers mainly interact with the development tools using their native GUI. Modeling the envisioned tool chain with TIL forced us to be more specific than in a textual description and triggered some improvements and clarifications to the textual description. This helped us to clarify the needs our industrial partner had regarding the tool chain. Examples of such clarifications are: Should the data flow be unidirectional or bidirectional? Which parts of the tool data need to be transferred to another tool? In which order are the tools used? Which user is responsible for transferring data between the tools? The results of this part of the case study are that TIL allows us to model all features of the envisioned industrial tool chain. In addition, modeling with TIL helps clarifying and communicating the needs regarding the tool chain to the different stakeholders. 5.2 TIL for detailed design and implementation In this section we evaluate how TIL can support the detailed design and implementation of a tool chain. This design is intended to contain all information necessary for code generation of the tool chain. In earlier case-studies we have worked on several aspects of this tool chain [3,9,12]. We have
On the modeling and generation of service-oriented tool chains
Fig. 8 Part of the industrial tool chain described in TIL
implemented this tool chain manually, which provides a basis for comparison with the TIL implementation. 5.2.1 Description of the industrial case To be able to present the design and implementation here, we select a subset of the tool chain introduced in the previous section. In the following we describe the TIL model of the tool chain illustrated in Fig. 8: An engineer develops a new embedded system, and after updating the UML component model he checks the model into the repository. This is depicted by a control channel, which activates the data channel uml2repository. Automatically, the model will be analyzed by a safety analysis tool to detect single points of failure in the embedded system. This is depicted by the sequencer Seq0, which is activated by a control channel, whenever new UML models are checked into the repository. The sequencer first triggers the data channel uml2safety to transfer the UML model to the safety analysis tool involving a model transformation. The sequencer then calls the service named SPF in the safety analysis tool to analyze the system for single points of failure. If no single points of failure have been found, a simulation of the behavior of the new model is started in Simulink. This is realized by another set of control channels and a sequencer Seq1. The control channel connecting the two sequencers specifies a guard condition and is only triggered if no single point of failure is found. Via the first control channel, the sequencer Seq1 triggers the data channel uml2simulink, and the second control channel calls the simulate service in Simulink. Finally, the engineer receives an email notification.
metamodels and model transformations. A tool adapter metamodel is linked to each tool adapter in the TIL model. A model transformation is linked to each data channel in the TIL model. We develop the tool adapter metamodels for safety analysis (15 metaclasses) UML (6 metaclasses) and for Simulink (7 metaclasses). As an example we show a part of the tool adapter metamodel for Simulink in Fig. 9; it describes the tool data that will be exposed by the services and the tool functionality that will be exposed as services. The tool chain designer specifies two model transformations: uml2safety for the data channel between UML and the safety analysis tool and uml2simulink for the data channel between UML and Simulink. The metamodels and model transformations are linked to the TIL model. Before code generation, the TIL Workbench checks the TIL model for
5.2.2 Applying TIL for detailed design and implementation To use TIL for the purpose of detailed design, we first create a TIL model as depicted in Fig. 8 and then create tool adapter
Fig. 9 Tool adapter metamodel for Simulink specifying the exposed tool data and tool functionality
123
M. Biehl et al.
internal consistency, e.g. that all services referenced in the control channels are specified in the respective tool adapter metamodels. We use the TIL code generator to produce an initial implementation of the tool chain from the refined TIL model. Generation is completely automated and does not require user intervention. The code generation is not time critical and for the TIL model presented in Fig. 8, it takes less than 30 seconds on a standard desktop machine. After generation, code needs to be added manually to the generated skeletons; in particular, the internal part of each tool adapter needs to be implemented.
5.3.1 Method When developing a tool chain, a number of design decisions have to be made. We identify these design decisions and evaluate how the TIL and the CM approach support the tool chain designer in making these design decisions. We assess the number and type of design decisions that need to be made for building the tool chain with the CM and the TIL approach. We segment the design decisions according to when and by whom these decisions are made.
5.3.2 Analysis 5.3 Qualitative evaluation of the effectiveness of the TIL generator In the following we would like to find out how effective the TIL approach is in supporting the tool chain designer, when implementing the tool chain depicted in Fig. 8. We determine the effectiveness of the TIL generator by comparing the effort necessary for developing a tool chain with and without the TIL generator. We compare two implementations of this tool chain: (1) In previous work we have implemented this tool chain manually [3,9,12]; we refer to this implementation as the CM (completely manual) implementation. (2) We generate the same tool chain with TIL as described in Sect. 5.2; we refer to this realization as the TIL implementation. The tool chain implemented with the CM implementation uses the same tool adapter metamodels and is thus comparable. It differs from the TIL implementation in so far as it is implemented completely manually as a Java program.
Table 1 Design decisions for realizing a service-oriented tool chain
In the CM approach all design decisions need to be made manually when implementing the tool chain. When using the TIL approach, only a subset of these decisions need to be made by the tool chain designer. The design decisions are divided into three groups. For each group the design decisions are made at different times and by different roles in the development process. The groups are
– TIL Model: When the tool chain designer creates a new tool chain, only the decisions in the TIL model need to be made. – TIL Generator: Most decisions are embodied in the generator. The decisions are made by the designer of the generator. The generator hides these decisions from the tool chain designer. Most importantly, the generator can be reused for several tool chains, as described in Sect. 4.4. – TIL Manual: The tool chain designer adds manually written code to the generated code.
Design decision
TIL model
Tool chain architecture
X
Technical space for integration
TIL generator
CM X
X
X
Choice of communication protocols
X
X
Choice of programming languages
X
X
X
X
Abstract syntax of exposed tool data
X
Concrete syntax of exposed tool data Exposed functionality of the tool
X
X
X
Service overhead (e.g. Configurations)
X
X
Service catalog/directory service
X
X
Implementation details of the tool adapter
123
TIL manual
X
Control flow
X
Data flow including model transformations
X
Count
5
X X X
6
1
12
On the modeling and generation of service-oriented tool chains
In Table 1 we provide an overview of the types of design decisions that need to be made for a new tool chain. We assign each decision to one of the three groups. For each group we count the number of decisions.
Table 2 Generated and manually implemented code for the TIL and CM approach measured in LOC, for each part of the tool chain
UML
1,409
59
1,468
5.3.3 Interpretation
Simulink
2,030
1,118
3,148
3,077
Safety
3,833
317
4,150
2,359
Repository
445
0
445
260
Data flow
524
0
524
399
Control flow
373
0
373
170
8,614
1,494
10,108
7,578
The TIL model captures five out of twelve types of design decisions. These are the essential architectural design decisions, which need to be made by the tool chain designer, such as defining which tool data and functionality is exposed and how the data of different tools relates to each other. The generator embodies six out of twelve decisions, since they are general and independent of the needs of a particular tool chain. Reusing these general decisions for each new tool chain helps the tool chain designer to focus the effort on the important decisions that need to be made for each individual tool chain. The manually added code only concerns the implementation of services for exposing tool data and tool functionality in the tool adapter. In the manually added code only detailed implementation decisions need to be made, since the generated code and skeletons provide a structure. All technologyrelated decisions have been made in the generator and in the TIL model. The design decisions that need to be made in the manually added code of the TIL approach are only a small subset of the design decisions necessary in the CM approach. TIL restricts the design decisions that can be made when building a tool chain. This simplifies development of tool chains by reducing the complexity experienced by the tool chain designer. It allows the tool chain designer to focus on the decisions made in the TIL model, which are the essential ones. The reduction of decisions also leads to less manually implemented code. In the following section we quantify the ratio of manually implemented and generated code. 5.4 Quantitative evaluation of the effectiveness of the TIL generator The TIL approach can be evaluated using a number of different metrics for both the development of the tool chain such as the effectiveness of the generator as well as the runtime characteristics of the generated code, such as scalability, reliability and performance. Here we quantify the effectiveness of the generator. 5.4.1 Method To determine the effectiveness of the generator, we compare the code size of the tool chain with the TIL approach and the CM approach. The relevant measurements are the size of the
Part
Total
TIL generated
TIL manual
TIL total
CM total 1,313
generated code with TIL, the size of the manually added code with TIL and the size of the code with the CM approach. Different metrics have been devised to determine code size. Here we do not need to measure the size of complete software, but rather the size of fragments of source code, such as the size of the source code skeletons. This is why we base our size comparison on the lines of code (LOC) metric. To count lines of code we use the cloc18 program and configure it to only count lines with code, no blank or comment lines. Even though the modeling effort could be measured as well [51], we do not take it into account for different reasons: The effort for creating the TIL model is comparably small and is thus not taken into account. The effort for creating the tool adapter metamodels or the model transformations requires the same effort for both the TIL and the CM implementation and is thus not taken into account. 5.4.2 Measurements We present the results of our LOC measurements in Table 2. The table lists the measured LOC in the manually written code for the CM implementation and both the generated and manually written code for the TIL implementation. We report the measurements for each tool adapter, the repository, data flow and control flow separately. 5.4.3 Interpretation In this section we compare the measurements and interpret the findings. We use the measurements of Table 2 to make different kinds of comparisons and draw conclusions. We first compare the total LOC of the TIL approach and completely manual (CM) approach. It shows that the total number of LOC in the TIL implementation is higher than in the CM implementation. This can be explained by the fact that a programmer may optimize the manually written code 18
http://cloc.sourceforge.net.
123
M. Biehl et al.
of the CM approach by leaving out unused code or writing code more compactly, while the generator always produces the code regardless if it is used or not. The fraction of manually implemented versus generated code for the TIL approach shows that most of the source code for the tool chain can be generated automatically with our DSML-based approach. The tool adapter of Simulink requires the largest fraction of manually written code, the tool adapter of PapyrusUML the smallest fraction. Complete generation without manually added code is possible for the repository, data flow and control flow. For the complete tool chain developed with the TIL approach, 85 % of the overall source code can be generated; only 15 % need to be manually implemented. The comparison of the manually implemented LOC in the TIL and CM approach can provide us with clues about the effectiveness of the generator. We compare the LOC of the manually added code in the TIL approach with the LOC in the CM approach. The amount of manually written source code is reduced by the TIL solution for all parts of the tool chain. In this case study, the manually added code in the TIL approach makes up 20 % of the complete source code that had to be written with CM. In other words, the TIL approach could cut 80 % of the manually written source code in this case study. Since it is the manually written source code that costs effort and time, this measurement can hint at the development efficiency gains possible with TIL. 5.5 Summary of the evaluation of the case study In an industrial case study we have validated that TIL is expressive enough to model an industrial tool chain and generate code for a service-oriented implementation. To evaluate the effectiveness of the TIL generator, we have used both qualitative and quantitative evaluations: The qualitative evaluation in Table 1 shows that writing the manually added code of the TIL approach only requires making a subset of the design decisions necessary in the CM approach. The quantitative evaluation in Table 2 shows that the manually added code in TIL only makes up 20 % of the code of a comparable, completely manually written tool chain. The qualitative and quantitative evaluations together provide evidence that the TIL approach can effectively support the work of the tool chain designer.
to the purposes of TIL declared in Sect. 3, especially communication, specification and code generation. 6.1 Languages for service engineering Building service-oriented solutions has recently received a lot of attention, especially modeling such solutions. General purpose modeling languages such as UML are used for engineering general service-oriented solutions. In this article we explore and evaluate the use of a domain-specific language for engineering a service-oriented solution in a particular domain, the domain of tool integration. The work in service-oriented modeling targets the finegranular configuration of services. These modeling languages strive to expose the properties of services to the modeling language. Examples are the Service Oriented Modeling Framework [7] and approaches using UML profiles, such as the UML profile for software services [27], the SOAML UML profile for services [39] or the UML4SOA profile [21]. The service component architecture (SCA) [6] is a component model for building service-oriented solutions. From the perspective of tool integration, these artifacts are far away from the domain and are comparatively of low-level. The user of these service-oriented modeling languages needs to be an expert in service-oriented development. Languages such as BPMN [40] and SPEM [38] provide the possibility to describe processes and potentially describe the interaction between tool adapters. These languages focus on description and cannot be easily enacted. Languages such as BPEL [37] can be enacted, but have a different purpose; they describe business processes and not tool integration scenarios. As more and more systems become service-oriented, it is important to empower domain experts to build serviceoriented systems, without requiring deep expertise in serviceoriented development. Using the domain-specific modeling approach, we can make a clear distinction between domain experts and SOA experts. The SOA experts design the generator and the parameters of the service-oriented architecture this generator produces. This generator hides the SOA design decisions from the domain expert and the generator can be reused for building several solutions. An example of a domain-specific approach to service engineering is the open source project Apache Camel [26] for the Enterprise Application Integration (EAI) domain [25], concerned with the service-oriented integration of business software.
6 Related work 6.2 Languages and frameworks for tool integration We organize the overview of related work into a section on languages for service engineering and a section on languages and frameworks for tool integration. In each of these categories we determine in how far the languages are applicable
123
The work on integration dimensions [47] and integration patterns [30] can be seen as a high-level language for tool integration. However, the purpose of these languages is analysis
On the modeling and generation of service-oriented tool chains
and classification and they are not intended for building tool chains. Service-oriented integration frameworks focus on control integration. An example is the jETI framework [36], which uses workflows to integrate services. Model-based integration frameworks focus on data integration using modeling technology. These approaches use metamodeling for describing the exchanged data and model transformations for data translation. These model-based integration frameworks do not offer a language to design and generate a complete tool chain. Due to the focus on data integration, control integration is either not available, or a secondary issue. Examples are MOFLON [2], OTIF [46] and ModelCVS [34]. The tool integration frameworks ToolNet [1] and TiE [32] are based on MOFLON. MOFLON approaches focus on data integration using metamodels and model transformations and even supports bidirectional transformations. MOFLON provides capabilities for code generation of tool adapters [33,48]. TIL has a different scope, as it addresses data, control, process and platform integration. TIL provides generators for these different dimensions of a tool chain. The Open Tool Integration Framework (OTIF) provides reusable components and libraries to build tool chains. It is targeted towards data integration and process integration. OTIF includes a language for modeling data flow between tools [30], but control integration is out of scope. TIL has a wider scope, as it addresses data, control, process and platform integration. The generation of the data access in the tool adapters is listed as future work [30], but not the generation of other parts of the tool adapter, or other parts of the tool chain. Several recent tool integration frameworks use serviceoriented architectures, such as OSLC [41], Jazz [20] or ModelBus [22]. ModelBus is a tool integration framework that uses modeling technology and web services. It provides a repository for EMF models and a BPEL engine for process integration. However, tool adapters need to be created manually. These service-oriented integration frameworks do not offer a language to design and generate the tool chain. In [5] a language for describing processes is enhanced with language concepts for tool integration. In contrast to TIL, this language is not used to generate the tool chain. Model transformations are used only at runtime of the tool chain to support the data exchange between the tools and not to generate the tool chain. We have found several languages for aspects of tool integration; however, they have different perspectives and scope. Our approach focuses on describing tool chains on the architectural level. While we have found work on generating code for single adapters using MDD approaches, we are not aware of any work on modeling and generating code for complete service-oriented tool chains.
7 Future work In Sect. 3 we have introduced five different activities that can be supported by TIL. In this article we focused on communication, design and implementation. In future work, we will explore how TIL can support analysis and evolution. We plan to use TIL models for the analysis of tool chains. We will apply metrics for analyzing the non-functional properties of a tool chain (such as scalability or performance). The analysis results can be used to make well-informed design choices, e.g. about the granularity of the tool adapter metamodel, when building new tool chains or when improving existing ones. We also plan to assess how TIL models can be used to support the evolution of tool chains. This is of industrial relevance, since tool chains need to co-evolve with new versions of the tools they integrate. We plan to leverage metamodel matching [18] for supporting the specification of data channels. Currently, model transformations need to be manually defined as a part of each data channel. We envision to automate this step. If no transformation is specified for a data channel that connects two tool adapters that have different metamodels, the TIL Workbench can attempt to compute one possible transformation, based on metamodel matching algorithms. These algorithms use structural and naming similarities of metamodel elements for computing a mapping [15]. In Sect. 3.2 we have based our language proposal for TIL on the analysis of the tool integration domain. As a result, TIL describes a tool chain independently of a particular tool integration framework. Thus the TIL approach provides the opportunity to generate different implementations from the same TIL model by replacing the generator. In future work we would like to examine if TIL can be used for modeling and code generation for particular tool integration frameworks such as ModelBus [22] or Jazz [20]. To support code generation for different integration frameworks, we would like to introduce variability modeling to the generator. We have evaluated TIL in a case study from the area of embedded systems development, but we believe the approach is not limited to this area. We plan to perform additional case studies with TIL and its generation capabilities for tool chains from other areas of software and systems engineering.
8 Conclusion In this article we have presented the need for a systematic approach for building service-oriented tool chains with automated generation. A service-oriented architecture for tool chains has a number of advantages, such as flexibility, distribution, loose coupling and platform independence, but it is complex to design and realize. To deal with this
123
M. Biehl et al.
complexity, we propose the domain-specific modeling language TIL. TIL allows us to model tool chains at an appropriate level of abstraction for the purpose of communication, design and code generation. TIL and its generators are independent of a particular tool integration scenario and can be reused for different tool chains. TIL and its generators fulfill the objectives we set for this work in Sect. 1.2: 1. We have analyzed the domain of tool integration and extracted a set of domain concepts to describe tool chains in a systematic and structured way. TIL is built from this selection of domain concepts, which allows us to describe tool chains on an architectural level of abstraction. 2. TIL and its graphical syntax supports communication and documentation of tool chains in a concise and graphical way for different kinds of stakeholders. 3. The language concepts of TIL can be used to describe tool chains that are tailored to specific needs. The language concepts can be configured with properties to describe specific tools and the language concepts can be composed into a tool chain that is tailored to a specific development process. 4. TIL deals with the complexity using language concepts from the domain of tool integration that hide the details of the service-oriented implementation. Automated generators produce the service-oriented implementation for any TIL model. In the case study, only 20 % of the source code of a comparable manual implementation of the tool chain needed to be implemented; the rest of the source code was generated from the TIL model. In an industrial case study we have validated that TIL is expressive enough to model an industrial tool chain and generate code for a service-oriented implementation. The approach requires manually added code, which is comparatively small and not overly complex. Using both quantitative and qualitative evaluations in the case-study, we have shown the effectiveness of the TIL generator. The ability to generate tool chains offers new opportunities for the industrial practice of software development. Tailored service-oriented tool chains can be built efficiently for the individual need
References 1. Altheide, F.: An architecture for a sustainable tool integration. In: Dörr and Schurr (eds.) Workshop on Tool integration in system development (2003) 2. Amelunxen, C., Klar, F., Königs, A., Rötschke, T., Schürr, A.: Metamodel-based tool integration with MOFLON. In: ICSE ’08, pp. 807–810 (2008) 3. Armengaud, E., Zoier, M., Baumgart, A., Biehl, M., De Chen, J., Griessnig, G., Hein, C., Ritter, T., Kolagari, R.T.: Model-based toolchain for the efficient development of safety-relevant automotive
123
4.
5.
6. 7. 8.
9.
10.
11.
12.
13.
14.
15.
16. 17. 18.
19.
20. 21.
22.
embedded systems. In: SAE 2011 World Congress & Exhibition, (2011) Asplund, F., Biehl, M., El-Khoury, J., Törngren, M.: Tool integration beyond Wasserman. In: First Workshop on Integration of Information Systems Engineering Tools (INISET 2011), (2011) Balogh, A., Bergmann, G., Csertán, G., Gönczy, L., Horváth, Majzik, I., Pataricza, A., Polgár, B., Ráth, I., Varró, D., Varró, G.: Workflow-driven tool integration using model transformations. In: Engels, G., Lewerentz, C., Schäfer, W., Schürr, A., Westfechtel, B. (eds.) Graph Transformations and Model-driven Engineering, chapter 10, pp. 224–248. Springer, Heidelberg (2010) Beisiegel, M.: Service Component Architecture. Technical report, Open SOA (2007) Bell, M.: Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture. Wiley, Hoboken (2008) Biehl, M.: Tool Integration Language. Technical Report ISRN/ KTH/MMK/R-11/16-SE, Royal Institute of Technology (KTH), (2011) Biehl, M., DeJiu, C., Törngren, M.: Integrating safety analysis into the model-based development toolchain of automotive embedded systems. In: Proceedings of the ACM SIGPLAN/SIGBED Conference on Languages, Compilers and Tools for Embedded Systems (LCTES 2010), p. 125 (2010) Biehl, M., El-Khoury, J., Törngren, M.: High-Level specification and code generation for service-oriented tool adapters. In: Proceedings of the International Conference on Computational Science (ICCSA2012), (2012) Biehl, M., Gu, W., Loiret, F.: Model-based service discovery and orchestration for OSLC services in tool chains. In: International Conference on Web, Engineering (ICWE2012), (2012) Biehl, M, Sjöstedt, C.-J., Törngren, M.: 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), (2010) Brown, A.W., Penedo, M.H.: An annotated bibliography on integration in software engineering environments. SIGSOFT Softw. Eng. Notes 17(3), 47–55 (1992) Christie, A., Levine, L., Morris, E.J., Riddle, B., Zubrow, D.: Software Process Automation: Interviews, Survey, and Workshop Results. Technical report, SEI (1997) Del Fabro, M., Valduriez, P.: Towards the efficient development of model transformations using model weaving and matching transformations. Softw. Syst. Model. 8(3), 305–324 (2009) Eisenecker, U.W., Czarnecki, K.: Generative Programming: Methods, Tools, and Applications. Addison-Wesley, Boston (2000) Erl, T.: SOA Principles of Service Design. Prentice Hall, Upper Saddle River (2007) Falleri, J.-R., Huchard, M., Lafourcade, M., Nebut, C.: Metamodel matching for automatic model transformation generation. In: Czarnecki, K., Ober, I., Bruel, J.-M., Uhl, A., Völter, M. (eds.) Model Driven Engineering Languages and Systems, vol. 5301 of LNCS, chapter 24, pp. 326–340. Springer-Verlag (2008) Fielding, R.T.: Architectural Styles and the Design of Networkbased Software Architectures. PhD thesis, University of California, Irvine (2000) Frost, R.: Jazz and the Eclipse way of collaboration. IEEE Softw. 24(6), 114–117 (2007) Gilmore, S., Gönczy, L., Koch, N., Mayer, P., Tribastone, M., Varró, D.: Non-functional properties in the model-driven development of service-oriented systems. Softw. Syst. Model. 10(3), 287–311 (2011) Hein, C., Ritter, T., Wagner, M.: Model-driven tool integration with ModelBus. In: Workshop Future Trends of Model-Driven Development (2009)
On the modeling and generation of service-oriented tool chains 23. Herbsleb, J.D.: Global software engineering: the future of sociotechnical coordination. In: 2007 Future of Software Engineering, FOSE ’07, pp. 188–198, IEEE Computer Society, Washington, DC (2007) 24. Hillairet, G., Bertrand, F., Lafaye, J.Y.: Bridging EMF applications and RDF data sources. In: 4th International Workshop on Semantic Web Enabled, Software Engineering (2008) 25. Hohpe, G., Woolf, B.: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, Boston (2003) 26. Ibsen, C., Anstey, J.: Camel in Action. Manning Publications, Greenwich (2011) 27. Johnsto, S.: UML 2.0 Profile for Software Services. Technical report, IBM (2005) 28. Kappel, G., Kapsammer, E., Kargl, H., Kramler, G., Reiter, T., Retschitzegger, W., Schwinger, W., Wimmer, M.: Lifting metamodels to ontologies: a step to the semantic integration of modeling languages. MODELS 4199, 528–542 (2006) 29. Kapsammer, E., Kargl, H., Kramler, G., Reiter, T., Retschitzegger, W., Wimmer, M.: On models and ontologies - a layered approach for model-based tool integration. In: MOD2006, pp. 11–27 (2006) 30. Karsai, G., Lang, A., Neema, S.: Design patterns for open tool integration. Softw. Syst. Model. 4(2), 157–170 (2005) 31. Kelly, S., Tolvanen, J.-P.: Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society Pr, Hoboken (2008) 32. Klar, F., Rose, S., Schürr, A.: TiE - a tool integration environment. In: Proceedings of the 5th ECMDA Traceability Workshop, volume WP09-09 of CTIT Workshop Proceedings, pp. 39–48 (2009) 33. Königs, A., Schürr, A.: MDI: a rule-based multi-document and tool integration approach. Softw. Syst. Model. 5(4), 349–368 (2006) 34. Kramler, G., Kappel, G., Reiter, T., Kapsammer, E., Retschitzegger, W., Schwinger, W.: Towards a semantic infrastructure supporting model-based tool integration. In: GaMMa ’06: Proceedings of the 2006 international workshop on Global integrated model management, pp. 43–46. ACM, New York (2006) 35. Kurtev, I., Bézivin, J., Aksit, M.: Technological spaces: an initial appraisal. In: CoopIS, DOA 2002 Federated Conferences, Industrial track (2002) 36. Margaria, T., Nagel, R., Steffen, B.: jETI: a tool for remote tool Iitegration tools and algorithms for the construction and analysis of systems. In: Halbwachs, N., Zuck, L. (eds.) TACAS, volume 3440 of LNCS, pp. 557–562 (2005) 37. OASIS. OASIS Web Services Business Process Execution Language (WSBPEL) TC. Technical report, “OASIS” (2007) 38. OMG. Software & Systems Process Engineering Metamodel Specification (SPEM). Technical report, “OMG” (2008) 39. OMG. SoaML. Technical report, OMG (2009) 40. OMG. Business Process Model And Notation (BPMN). Technical report, “OMG” (2011) 41. OSLC Core Specification Workgroup. OSLC core specification version 2.0. Technical report, Open Services for Lifecycle Collaboration (2010) 42. Papadopoulos, Y., McDermid, J.A.: Hierarchically performed hazard origin and propagation studies. In: Massimo, F., Karama, K., Alberto, P. (eds.) SAFECOMP of LNCS, vol. 1698, pp. 139–152. Springer, Heidelberg (1999) 43. Potociar, Marek: JSR 311: JAX-RS: The Java API for RESTful Web Services. Technical report, Oracle (2009) 44. Seinturier, L., Merle, P., Rouvoy, P., Romero, D., Schiavoni, V., Stefani, J.-B.: A component-based middleware platform for reconfigurable service-oriented architectures. Softw. Prac. Exp. (2011)
45. Shaw, M., Garlan, D.: Software Architecture. Prentice Hall, Upper Saddle River (1996) 46. Sztipanovits, J., Karsai, G., Neema, S., Bapty, T.: The modelintegrated computing tool suite model-based engineering of embedded real-time systems. In: Giese, H., Karsai, G., Lee, E., Rumpe, B., Schätz, B. (eds.) MBERTS, volume 6100 of LNCS, chapter 20, pp. 369–376 (2011) 47. Wasserman, A.I.: Tool integration in software engineering environments. In: Long, F. (ed.) Software Engineering Environments, International Workshop on Environments Proceedings, Lecture Notes in Computer Science, pp. 137–149. Springer, Heidelberg (1989) 48. Ingo, W., Felix, K., Andy, S.: Development of tool extensions with MOFLON. In: Giese, H., Karsai, G., Lee, E., Rumpe, B., Schätz, B. (eds.) MBERTS, volume 6100 of LNCS, chapter 16, pp. 337–343. Springer, Heidelberg (2011) 49. Wicks, M., Dewar, R.: A new research agenda for tool integration. J. Syst.Softw. 80(9), 1569–1585 (2007) 50. Wicks, M.N.: Tool Integration within Software Engineering Environments: An Annotated Bibliography. Technical report, HeriotWatt University (2006) 51. Wu, Y., Hernandez, F., Ortega, F., Clarke, P.J., France, R.: Measuring the effort for creating and using domain-specific models. In: Proceedings of the 10th Workshop on Domain-Specific Modeling, DSM ’10, ACM, New York (2010)
Author Biographies Matthias Biehl is a doctoral student in the Embedded Control Systems group at the Royal Institute of Technology (KTH). He received his M.Sc. degree in Computer Science from the Karlsruhe Institute of Technology in 2008. His research interests are tool chains, model-driven development, domain-specific modeling languages and software architecture, each with applications in embedded systems engineering.
Jad El-Khoury is a researcher at the Royal Institute of Technology (KTH). He got his BSc degrees in Mechanical Engineering and Computer Science from the University of Sydney in 1999, and the Ph.D. degree in Machine Design from the Royal Institute of Technology in 2006. He researches in the area of embedded system development, in the particular context of mechatronic products. Topics of interest include model-based development, systems engineering, tool and model integration.
123
M. Biehl et al. Frédéric Loiret is a postdoctoral researcher in the Embedded Control Systems group at the Royal Institute of Technology (KTH). He received his Ph.D. degree in 2008 from the Lille University. His research interests are focused on providing tailored tools and design methods, based on the CBSE principles, to increase the efficiency of software development processes for real-time & embedded systems.
123
Martin Törngren is a Professor in Embedded Control Systems at Royal Institute of Technology (KTH) since 2002. He is the initiator and director for the Innovative Center for Embedded Systems, inaugurated in 2008 and cofounder of Fengco Real-time control in 1996. Since his Ph.D. he has been conducting research and education in the areas of embedded systems and Mechatronics with particular interest in the areas of model-based engineering, architectural design and co-design of control applications and embedded systems.
Appendix D
High-Level Specification and Code Generation for Service-Oriented Tool Adapters Matthias Biehl, Jad El-Khoury, and Martin T¨ orngren in Proceedings of the International Conference on Computational Science and Its Applications (ICCSA2012) June 2012 c
2012 ACM. Reprinted with permission.
High-Level Specification and Code Generation for Service-Oriented Tool Adapters Matthias Biehl, Jad El-Khoury, Martin T¨orngren Embedded Control Systems Royal Institute of Technology Stockholm, Sweden {biehl,jad,martin}@md.kth.se Abstract—The 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, e.g. by exchanging tool data or providing traceability between the data. Despite the availability of tool integration platforms and frameworks, it is labor-intensive and costly to build tool integration solutions. Industrial tool integration initiatives such as OSLC (Open Services for Lifecycle Collaboration) demand complex configurations and the adherence to integration standards. This further complicates building an integration solution. We propose an approach that uses formalized specifications to systematize tool integration and specialized code generators to automate the process of building tool adapters. We evaluate our approach with the implementation of a code generator that creates service-oriented tool adapters conforming to the OSLC industry initiative. Keywords-Code Generation; Service-Oriented Architecture; Tool Integration
I. I NTRODUCTION The engineering of complex software systems, such as automotive or aerospace embedded software systems, requires a diverse set of development tools to design, implement, test, analyze and simulate the system. The lack of interoperability between the tools leads to gaps in the development process, high development costs and reduced product quality [11]. 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 between the tools. Tool integration is concerned with the relationships among tools, the properties of the relationship and the degree to which tools agree [12]. The goal of 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 an engineering environment with several integrated tools increases the efficiency of product development and product quality [15]. Tool chains have the potential to improve the efficiency of product development and the time to market for new and improved products by seamlessly exchanging data between tools, tracing between tool data and automating tasks by scripting across tool boundaries. This is especially relevant
for complex software development, where many tools are involved. To reap these benefits, the tool chain first has to be constructed as a software solution that fits the chosen set of development tools and connects them in such a way that they can support the product development process. The tool chain and its parts are built and extended manually for each development tool that is integrated into the tool chain, which requires considerable effort. All involved stakeholders are interested in reducing the effort of tool chain construction, without reducing the benefits of using the tool chain. With the development effort of the tool chain on one side and the benefits of using the tool chain on the other side, the net value of a tool chain can be improved by reducing the development cost and effort of tool chains. This is a challenging topic and for this paper we need to delimit the scope. We focus here on the development of the tool adapters, the software that exposes the data and functionality of the integrated tool. Work on developing complete tool chains from these tool adapters can be found here [2]. In this paper we put forward the research question: How can we reduce the development effort for the tool adapter developer? The contribution of this paper is threefold: (i) We provide a high-level specification for designing parts of such tool integration solutions, which we call tool adapters. The specification uses metamodeling technology, which allows us to describe the essential design decisions in a technologyagnostic way. We demonstrate that this specification can be used as the basis for both (ii) semi-automated and (iii) fullyautomated code generation of tool adapters, resulting in a considerable reduction of implementation effort. This paper is structured as follows. Section II introduces the basic building blocks of tool integration architectures and an industrial initiative for tool integration. Based on this analysis, we introduce the concepts for automating the creation of tool adapters in section III. We explain the specification of tool adapters in section IV and automated adapter generation in section V. We evaluate the approach in section VI. In the remaining sections we compare our approach to related work, provide an overview of future work and conclude.
II. T OOL I NTEGRATION A RCHITECTURES A broad overview of the literature on tool integration is provided in the annotated bibliographies of Brown [4] and Wicks [16]. The scope of tool integration [13], [12] is typically defined by the following dimensions: Data integration shares the data produced by different tools and manages the relationship between the data objects, 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. In this work we focus on data, control and platform integration. A. Common Building Blocks in Tool Integration Tool integration has several dimensions and in this paper we focus on the dimension of process, control and data integration. As detailed in [3], data integration has two purposes: resolving structural differences between the metamodels of integrated tools and dealing with differences in the technical representation. This is why most integration styles have the concept of a tool adapter, which adapts the technical space and transformations, which resolve structural differences between tools by mapping corresponding data. In addition all integration styles have the concept of a common representation of tool data, a common ground for integration, called the technical space for integration. The purpose of tool adapters is to provide 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. In addition, 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 internal interface, is used for the interaction between the tool adapter and the integrated tool. The other interface, called external interface, is used to interact with the tool adapters of other integrated tools, an integration platform or an integration framework. A transformation provides a bi-directional mapping between two metamodels that preserves the semantics. The technical space for integration provides a common ground of representing the tool specific data and can be used for mapping data by transformations. The choice of the technical space for integration also confines the choice of transformation technology. In this section we have analyzed established tool integration styles and identified the building blocks that these styles have in common: tool adapters, transformations and the technical space for integration. In this paper we focus on tool adapters.
B. Industrial Initiative for Tool Integration: OSLC The OSLC initiative (Open Services for Lifecycle Collaboration) [9] is an industrial effort that is supported by several companies. It aims to standardize different choices for tool integration solutions, such as the technical space for integration, the communication protocols and architecture for tool adapters. OSLC provides a specification on how the tool data is to be interfaced externally: An OSLC adapter represents tool data in the form of an OSLC Resource and offers it to other tools. This resource can be requested and provided using a web service. The technical space for integration is the OSLC format, which is based on RDF (Resource Description Framework). Tool data is formatted as OSLC Resources, a protocol on top of RDF. Metadata is described by OSLC Resource Shapes, which describes how data can be interpreted. The Resources and Resource Shapes are made available via web services using a RESTful (Representational State Transfer) [5] architecture. An OSLC Resource describes only a part of the data represented by the internal data storage of the tool. A Resource Shape provides reflection, it describes the data structure of the Resource and can be requested at runtime for service discovery. An OSLC tool adapter provides at least a Service Provider, Service Catalog, Resources and Resource Shapes. Resources represent the data of the tool and correspond to a model. Resource Shapes describe the structure of the Resource and correspond to a metamodel, which is needed for reflection and discovery. The Service Catalog lists all the available services of the tool, such as data access methods. The necessary effort and cost for creating service-oriented tool chains that are conform to OSLC are considerable. The tool chains are complex service-oriented systems, which require web servers, configuration files, an implementation that conforms to the service-oriented standards and various metadata for the data and services. OSLC provides standardized communication protocols and data structures, but it does not solve the root problem of high development effort. Quite to the contrary, the heavy technological constraints contribute to the increasing complexity of tool chain development. III. A PPROACH The analysis of tool integration architectures in section II shows the central role of tool adapters. The tool adapter is responsible for making the data and functionality of each tool available to other tools and is thus a prerequisite for sharing and reusing data. For this purpose, the tool adapter maps tool data to a common, technical space of integration. Once data and functionality are available in the technical space of integration, the data can be reused and shared between tools through transformation, tracing or invocation by other tools. In this work we choose OSLC (see section II-B) as the technological space for implementing
the approach in section VI-E. A. Running Example
Figure 1. Overview of model-based (EMF) specification and service-based (OSLC) realization of tool adapters
tool adapters, due to its relevance for the industry. For the implementation of tool adapters, this entails a choice for RDF as a representation format for data and a serviceoriented architecture. The development of an OSLC-conform tool adapter is cumbersome due to the many technological requirements, identified in the previous section. Our approach, illustrated in figure 1, aims to simplify the development of tool adapters. The central idea of this approach is a high level specification of tool adapters by the tool adapter developer (step 1). The approach hides the technical details of tool adapter implementation, such as OSLC, RDF and SOA. This can be achieved by a model-based approach, where tool adapters are modeled on a high level of abstraction, focusing just on relevant design decisions. We differentiate between code that is specific for the integration technology and the code implementing the logic of the tool adapter. The code for the integration technology can be automatically generated, the logic is created by manual implementation. For this approach we set the following list of objectives: •
•
• •
•
O1: Low effort for implementing tool adapters: The main concern today is the time and effort involved in implementing tool adapters. O2: Specification of the main design decisions of tool adapters as first class entities: When tool adapters are developed, code is usually produced directly, the design and the important design decisions are usually not captured. O3: Specification of the tool adapter is independent of the used integration technology. O4: Implementation follows a service-oriented architecture and is conform to the industrial OSLC initiative for tool integration. O5: Implementation separates the code that relates to the integration technology from the code that describes the interaction with the tool.
We will revisit the objectives after describing and evaluating
We illustrate our approach by building a fully functional tool adapter for the MATLAB/Simulink tool. In tool chains for the development of embedded systems, MATLAB/Simulink is often a required tool. It provides graphical modeling and simulation of control functions. Despite its popularity, it is a proprietary tool; it cannot be readily integrated with other tools and a tool adapter is needed. An example of an integration scenario for MATLAB/Simulink is the reuse of the Simulink data in a UML tool, where it is further refined for implementation. IV. H IGH -L EVEL S PECIFICATION OF T OOL A DAPTERS The high-level specification of the tool adapter is an important part of this approach. We first explain the specification mechanisms, then we introduce different ways of using the mechanisms. A. Specification Mechanisms The purpose of our high-level specification is providing support to the developer of the tool adapter. The specifications condense the information about tool adapters to the essential minimum and can be used both for communication between the various stakeholders of the tool chain and as a blueprint for implementation. The specification provides an overview and represents all important design decisions that need to be made for a tool adapter, while technical details are left out. No technical knowledge of the service-oriented approach, web-services or OSLC is required for creating a tool adapter specification. The specification describes the data and the functionality that is exposed by the external interface of the tool adapter. We use the basic metamodeling technology provided by EMF to describe the external interface. The tool data is described in one EPackage as a directed graph, where the nodes are EClasses with EAttributes, and the links between nodes are EReferences. The services of the tool are described as EOperations with EParameters in a separate EPackage and EClass. The usage of the specification mechanisms is illustrated in figure 3. B. Using the Specification Mechanisms The specification mechanisms described in the previous section, can be used to specify different tool adapters for different tools - but also different adapters for the same tool: the developer has the flexibility to take a number of design decisions. An important design decision taken during the specification of the tool adapter is the scope and granularity of the exposed data. This decision depends on the role of the tool within the tool chain. If the tool is used for structural modeling, the static structure of the tool is in the scope.
If the same tool is used for behavioral modeling, models describing the dynamic structure need to be exposed. If the same tool is used for the analysis of performance, annotations of non-functional properties might be relevant. Another important design decision is the type of connections the tool has to the other tools of the tool chain. A connection for data exchange might require access to the complete tool data, a connection for traceability only access to single data elements. In general a higher quality of data exchange can be achieved with higher granularity. These decisions should determine the implementation of the tool adapter. Our specification mechanism allows expressing these important decisions without distraction by technology-related details. V. AUTOMATED G ENERATION OF T OOL A DAPTERS In this section we describe how we use the technologyindependent specification for implementing a tool adapter. In the implementation we separate the code that deals with the integration technology from the code that interacts with the tool, as shown in figure 2. The external part deals with the integration technology. The internal part interacts with the tool, e.g. via APIs.
Figure 2.
Architecture of the Tool Adapter
While the specification can be used as a blueprint for implementing the tool adapter manually, we can save effort and time by automatically generating the implementation of the tool adapter to different degrees. At a minimum, the external part dealing with the integration technology can be automatically generated from the specification. We call it semi-automated generation and describe it in section V-A. In some cases, the complete tool adapter can be generated, including internal and external parts. We call it fully-automated generation and describe it in section V-B. The benefits of automated generation are time-, effortand cost-saving. They can be achieved, since the developers of the tool adapter do not need to learn the integration technology, nor do they need to implement any code that deals with the integration technology. A. Semi-automated Tool Adapter Generation Our approach for semi-automated tool adapter generation for legacy tools can be roughly divided into four steps:
1) Define an EMF-based tool metamodel for both the data and the functionality of the tool we want to integrate. 2) Generate OSLC Resource Shapes, OSLC Service Provider and OSLC Service Catalog based on the tool metamodel. 3) Generate the implementation skeleton (external part) of the tool adapter in Java that conforms to OSLC and SOA. 4) Manually add the implementation to the skeleton (internal part) by injecting and extracting data from the legacy tool. Building a tool adapter for legacy tools requires some manual work, as they usually have individual APIs or proprietary data formats. Due to the individual differences between the tools, manual work is necessary to pick the right API function or extracting the right data. B. Fully-automated Tool Adapter Generation When we delimit the scope of the tools we want to integrate, higher levels of automation are possible because we have additional knowledge about the tool. Instead of generating source code for only the external part, we can employ the additional knowledge to also generate source code for the internal part. Our approach for fully automated tool adapter generation is limited to EMF-based Eclipse tools. It can be roughly divided into four steps: 1) Identify the existing EMF-based tool metamodel already used by the tool 2) Generate OSLC Resource Shapes, OSLC Service Provider and OSLC Service Catalog based on the tool metamodel. 3) Generate the implementation skeleton of the adapter (external part) in Java that conforms to OSLC and SOA. 4) Generate the implementation of the adapter (internal part). If we focus on EMF-based Eclipse tools, we can use the internal metamodel of the modeling tool as the specification for the tool adapter. Since we reuse the existing metamodel, we do not have to create a new tool metamodel. We can also access the tool data, as it is already available in the form of a model that corresponds to the specification. This approach uses the existing tool metamodel of a tool as the basis for automatically creating an OSLC conform tool adapter. In addition to the previous approach, even the OSLC service implementation for the resource queries can be automatically generated. Thus, the complete tool interface and implementation can be automatically generated. C. Process of Tool Adapter Generation In this section we describe the previously outlined steps 14 in more detail. Steps 1-3 describe the general case of semiautomated tool adapter generation for legacy tools. Step 4
describes the final step of fully automated adapter generation for EMF-based modeling tools. 1) Step 1 - Defining an EMF-based tool metamodel: The developer of the tool adapter defines an EMF-based tool metamodel specifying the interface of the tool adapter as described in section IV. This tool metamodel is central to our approach. It is the input to the automated adapter generation process, so the other steps depend on it. The tool metamodel should capture a subset of the tool data, since not all tool data needs to be exposed to the other tools. Running Example: The tool MATLAB/Simulink used in our running example can be used for modeling the structure, for modeling the behavior or for simulation etc. Depending on the role used, the metamodel will look different. In our running example, MATLAB/Simulink is used for modeling the structure in the context of a data exchange with a UML component diagram. In figure 3 we show a metamodel for the data of MATLAB/Simulink, in addition we show the signatures of the exposed services in figure 3. We illustrate this step on the running example. We create a simplified, EMF-based metamodel for the data and functionality (see figure 3) of MATLAB/Simulink. It is simplified, because it contains only a subset of the tool data of MATLAB/Simulink that is relevant in this context.
Figure 3. A simple tool metamodel for the exposed data and functionality of MATLAB/Simulink
2) Step 2 - Generating the OSLC Resource Shapes, OSLC Service Provider, OSLC Service Catalog: We automatically generate OSLC Resource Shapes and OSLC Service Definitions from the information in the tool metamodel. Since this is only metadata, it is independent of any tool data that is only available at runtime, and can be created at design time of the tool adapter. A model-to-text transformation reads the metamodel and generates OSLC Resource Shapes. There is a direct and straightforward mapping between the elements of an OSLC Resource Shapes and the metaclasses of an EMF metamodel. We generate OSLC Service Providers as a directory service for all services and all resources that are served by this tool adapter. We also generate an OSLC Service Catalog as an entry point for the directory service of this tool adapter. This ensures that the tool adapter and its services can be used by other tools.
3) Step 3 - Generating the Tool Adapter Code Skeleton: A model to text transformation automatically generates the code skeleton of the tool adapter. This skeleton contains a number of services for reading, writing and updating the tool data and also services that expose tool functionality. The purpose of the tool adapter is to offer the tool data in the form of OSLC Resources. Thus, the data is exposed by an OSLC-conform service that can be invoked by other tools to consume or provide the internal tool data. Resources represent tool data, which is only available at runtime. In contrast to step 2 where OSLC Resource Shapes were created at design time, we generate source code that creates OSLC Resources at runtime. There is a direct and straightforward mapping between a Resource (corresponding to a Resource Shape) and a model element (corresponding to a metaclass). We generate Java code with RESTful annotations (according to JAX-RS [10]) for the external interface of the tool adapter. Code skeletons realizing data access are generated for each metaclass in the tool adapter metamodel and for each HTTP method (GET, POST, PUT, DELETE). Code skeletons to access the functionality of the tool are generated according to the tool adapter metamodel. We generate an intermediate Java data model for handling the tool data that is exposed by the external interface of the tool adapter. The tool adapter extracts the data from the tool, and represents it in the intermediate data model. The intermediate data model is then serialized as an OSLC Resource. All tool adapters require similar infrastructure functionality, which can be generated automatically. We generate this infrastructure by serializing tool data as an OSLC Resource, a library for handling service parameters and a library for ID-handling to map external IDs to tool data elements. 4) Step 4 - Tool Adapter Implementation: In this step we provide the internal implementation of the skeletons for the data access methods that were automatically generated in step 3. For arbitrary legacy tools, the internal implementation is provided by the developer of the tool adapter. This means, the developer needs to inject and extract the data from the integrated legacy tool, e.g. via appropriate API functions. We provide templates and libraries that help accessing tool internal data using a specific technology to interface the APIs. • Command-line tool: The template provides a library of functions to start a command-line tool, provide the input data as a command line argument and to read the output data from the console or a file. • RMI based tool: The template provides a library to access functionality and data via RMI. • WSDL based tool: The template provides a library to access functionality and data via a web service described in WSDL. The remaining internal part needs to be manually implemented, as it is individual to each tool and cannot be
generated. We use protected regions of the model transformation tool, to protect this manually added code from being overwritten, when the external part is re-generated. If we assume, however, that the integrated tool is an EMFbased modeling tool, the internal metamodel of the tool data is available and we can access the data of the tool. In fact, it is not necessary to perform a technological mapping between the tool and the tool adapter; we can access the tool’s data using the same technology (EMF) we use inside the tool adapter. Thus we can achieve fully automated creation of the tool adapter. VI. E VALUATION We develop three OSLC-based tool adapters, for Simulink and two for PapyrusUML, which are fully functional and OSLC compliant. In the following we focus on the quantitative evaluation of the tool adapters. The research question put forward in section 1 shows that the main motivation for this work is finding new methods for reducing the development effort of the tool chain developer. This is why the focus of the evaluation is the reduction of development effort. We measure the number of lines of code, which provides a rough estimate of the development effort. All 4 steps of adapter generation have been implemented and can be used for evaluation. We evaluate our approach by measuring the amount of automatically generated source code produced in step 3 and the amount of manually added code produced in step 4. To evaluate the effectiveness of the generation approach, we compare these measurements to measurements of a corresponding, completely manually written tool adapter. We present both results of semiautomated and fully-automated generation and discuss the findings. A. Semi-automated Tool Adapter Generation for Simulink We measure the size of the source code of the Simulink tool adapter introduced in section V-C. The source code can be divided into two parts: A part that is completely generated and a part that is manually added. We measure the size of the source code by LOC (lines of code). In addition we compare the tool adapter, which was created according to this approach, with an independently created, completely manually written approach. • Generated LOC of our approach: gSimulink = 2030 • Manually added LOC of our approach: aSimulink = 1118 • Total LOC of our approach: tSimulink = gSimulink + aSimulink = 3148 • Completely manually written total LOC for comparison: mSimulink = 3077 Note that the total LOC of our approach is slightly larger than the total LOC of completely manually written code, as it is more generic than the manually written code.
Simulink ) is not The fraction of manually added code ( atSimulink significant for comparing semi-automated generation with completely manual implementation, since a lot of unnecessarily generated source code might result in a good ratio. Instead we focus on comparing manually written code only aSimulink ). The amount of source code and use the relation ( m Simulink of the manually added part of our approach makes up 36% of the completely manually written code. The comparison shows that this approach can in fact support the development of tool adapters by reducing the size of code that has to be implemented by 64%.
B. Semi-automated Tool Adapter Generation for Simplified UML We perform an additional measurement for semiautomated adapter generation for the tool PapyrusUML 1 , an Eclipse-based UML modeling tool. Internally, PapyrusUML uses the complete UML metamodel, which is quite large. For a given tool chain not all UML elements are used and do not need to be exposed through the tool adapter. In our example, only UML component diagrams are used and we choose to expose only the core classes of it, as depicted in figure 4. This metamodel has 14 modeling elements: 6 classes, 7 references and 1 attribute. In addition, several functions are exposed, as depicted in figure 4.
Figure 4. A simple tool metamodel for the data of UML component diagrams and the exposed functionality
We measure the size of the code, both the generated and manually added LOC. Just as in the previous measurement, we compare the code produced according to the approach described in this paper with a completely manually written tool adapter. • Generated LOC of our approach: gsimpleU M L = 1409 • Manually added LOC of our approach: asimpleU M L = 59 • Total LOC of our approach: tsimpleU M L = gsimpleU M L + asimpleU M L = 1468 • Completely manually written total LOC for comparison: msimpleU M L = 1313 a ML ) shows a reduction of the size The relation ( msimpleU simpleU M L of code that has to be implemented by 96%. A considerable amount of hand-written code could be saved in this case. 1 http://www.eclipse.org/papyrus
C. Fully-automated Tool Adapter Generation for UML We perform a similar study to demonstrate the capabilities of fully-automated tool adapter generation. For comparison we also use PapyrusUML here. It internally uses the EMF metamodel definition of UML, provided by the Eclipse MDT UML2 project2 . This metamodel has 865 modeling elements: 247 classes, 508 references and 110 attributes and is very large and detailed. We reuse this metamodel unchanged as input for the fully-automated adapter generation. We obtain the following measurements from the generated source code: • Generated LOC of our approach: gU M L = 85091 • Manually added LOC of our approach: aU M L = 0 • Total LOC of our approach: tU M L = gU M L +aU M L = 85091 The tool adapter for PapyrusUML can be completely generated from the UML metamodel, and no manual source code needs to be added. This is possible due to the fact that the internal data of the PapyrusUML tool is an EMF model, and EMF models can be accessed in a standardized way. A prerequisite for this approach is that the tool adapter metamodel is the same as the internally used metamodel, so no data transformation between the exposed data structure and the internal tool data structure needs to be specified. Since the adapter is completely generated and no manual code needs to be added, we do not compare it against a completely manually written source code. Instead, we compare the fully automated adapter generation for the complete UML metamodel with the semi-automated adapter generation of the simplified UML model. The generated source code for the original UML metamodel is quite large compared to the simple UML tool metamodel, roughly 58 times the LOC. The high number is at first quite surprising and is discussed in the following section. D. Discussion Some of the measurements and comparisons of the previous sections were surprising to us, and we thus discuss them further here. The amount of manually implemented code that can be saved by adapter generation varies between tools: It is 64% for Simulink and 96% for PapyrusUML. This can be explained by the accessibility of the data and functionality in the respective tools. The internal tool data in MATLAB/Simulink needs to be accessed by a more complex tool API (Application Programming Interface) and more complex technology of RMI (Remote Method Invocation) than in PapyrusUML. The internal tool data of PapyrusUML can be easily accessed by an Eclipse plugin, so less manual coding is required. As the example for PapyrusUML demonstrates, the fullyautomated tool adapter generation produces source code that 2 http://www.eclipse.org/uml2
is very large (factor 60) compared to the semi-automated generation. However, it can be attributed to the large metamodel of UML, which contains roughly 865 modeling elements, 62 times as many as in the metamodel used for semiautomated generation. The measurement is thus plausible, but brings up a new question: Is semi-automated or fullyautomated creation of tool adapters preferable? On one hand the memory footprint of the tool adapter will be higher with a large code size. On the other hand no code had to be written manually. Full adapter generation saves development time and cost and also reduces human error. E. Objectives Revisited We now revisit the objectives we set for the approach in section III: • O1: Low effort for implementing tool adapters: We reduced the effort for implementation of tool adapters to different degrees, ranging from 64% to 96% for semiautomated generation and 100% for fully-automated generation. • O2: Specification of the main design decisions of tool adapters as first class entities: The main technologyindependent design decisions for tool adapters are the choice of exposed data and services, which are described by the tool adapter metamodel. • O3: Specification of the tool adapter independently of the used integration technology: The tool adapter metamodel does not prescribe any choices regarding the integration technology. • O4: Implementation follows a service-oriented architecture and is conform to the industrial OSLC initiative for tool integration, which is ensured by code generation. This technology mapping has to be performed only once and can be reused for each new tool adapter. In addition, the integration technology is completely transparent to the tool adapter developers, so they do not need to learn the integration technology. • O5: Implementation separates integration technology and interaction with the tool: The tool adapter architecture distinguishes clearly between an internal and external part. The external part is always automatically generated, the internal part is usually manually written. We conclude that the objectives O1 to O5 set for this work have been achieved. VII. R ELATED W ORK Model-based integration frameworks focus on data integration using modeling technology for describing the exchanged data and model transformations for data translation. These model-based integration frameworks in general do not offer the possibility to generate tool adapters. Due to the focus on data integration, control integration is often not considered, or a secondary issue. Examples are ModelCVS [7] and the jETI framework [8]. Our approach is similar
to parts of the MOFLON tool integration framework [1], which also uses modeling technology as a means for tool integration. It is based on MOF as the technical space of integration and uses the common building blocks of tool adapters and model transformations. It provides capabilities for code generation from tool metamodels to build tool adapters [14]. This approach focuses on data integration and semi-automated adapter generation, where interfaces and reflective methods are automatically created, but manual work is needed to implement API calls. Generation of services for exposing functionality and fully-automated adapter generation are not considered in [14]. ModelBus [6] is a tool integration platform that uses modeling technology and web services. It provides a repository for EMF models and a number of interfaces for interacting with the repository. Tool adapters need to be created manually. VIII. F UTURE W ORK We regard the integration of several generated tool adapters into a tool chain as an important track of future work. The formality of the high-level specification of the tool adapters can help to produce a coherent integration. The models can be analyzed and verified before code generation. In addition, the service-oriented technology might provide practical technology for the orchestration of multiple tool adapter services. The results of the evaluation and the discussion in section VI hint at new possibilities for future work. We would like to find out, in how far the accessibility of the API and the technology for accessing the API influence the remaining implementation effort. One factor is the number of modeling elements in the tool metamodel. Can the remaining factors accessibility and technology be classified and quantified, so the remaining manual implementation effort can be predicted? In addition, we would like to further evaluate the approach in a larger industrial case-study with several tool adapters for different tools. IX. C ONCLUSION In this paper we have proposed and evaluated an approach for building standard-conform, service-oriented tool adapters for arbitrary legacy tools. We use code generation from a high-level, technology-agnostic tool metamodel to automatically generate service-oriented OSLC tool adapters. The generated tool adapters can be orchestrated to form a tool chain that is tailored to the needs of the individual development process and increase the productivity of product development. Using this approach, tool adapters can be specified without deep knowledge in integration technologies. As a result, it might even be possible for the end-users of the tool chain to specify the adapters for the tools they use in their development process. Most importantly, this approach reduces the development effort of service-oriented tool adapters.
R EFERENCES [1] C. Amelunxen, F. Klar, A. K¨onigs, T. R¨otschke, and A. Sch¨urr. Metamodel-based tool integration with MOFLON. In ICSE ’08, pages 807–810, 2008. [2] Matthias Biehl. Tool Integration Language (TIL). Technical Report ISRN/KTH/MMK/R-11/14-SE, Royal Institute of Technology, September 2011. [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), June 2010. [4] Alan W. Brown and Maria H. Penedo. An annotated bibliography on integration in software engineering environments. SIGSOFT Notes, 17(3):47–55, 1992. [5] Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. [6] C. Hein, T. Ritter, and M. Wagner. Model-Driven Tool Integration with ModelBus. In Workshop Future Trends of Model-Driven Development, 2009. [7] G. Kramler, G. Kappel, T. Reiter, E. Kapsammer, W. Retschitzegger, and W. Schwinger. Towards a semantic infrastructure supporting model-based tool integration. In Proceedings of the international workshop on Global integrated model management, pages 43–46, 2006. ACM. [8] Tiziana Margaria, Ralf Nagel, and Bernhard Steffen. jETI: A Tool for Remote Tool Integration Tools and Algorithms for the Construction and Analysis of Systems. In TACAS, volume 3440 of LNCS, 2005. [9] OSLC Core Specification Workgroup. OSLC core specification version 2.0. Technical report, Open Services for Lifecycle Collaboration, August 2010. [10] Marek Potociar. JSR 311: JAX-RS: The Java API for RESTful Web Services. Technical report, Oracle, 2009. [11] Andy Sch¨urr and Heiko D¨orr. Introductory paper. Software and Systems Modeling, 4(2):109–111, May 2005. [12] I. Thomas and B. A. Nejmeh. Definitions of tool integration for environments. Software, IEEE, 9(2):29–35, March 1992. [13] 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. [14] Ingo Weisem¨oller, Felix Klar, and Andy Sch¨urr. Development of Tool Extensions with MOFLON. In MBERTS, chapter 16, pages 337–343. 2011. [15] M. Wicks and R. Dewar. A new research agenda for tool integration. Journal of Systems and Software, 80(9):1569– 1585, September 2007. [16] M. N. Wicks. Tool Integration within Software Engineering Environments: An Annotated Bibliography. Technical report, Heriot-Watt University, 2006.
Appendix E
Constructing Tool Chains based on SPEM Process Models Matthias Biehl, and Martin T¨ orngren in Seventh International Conference on Software Engineering Advances (ICSEA2012) November 2012
Constructing Tool Chains Based on SPEM Process Models Matthias Biehl, Martin T¨orngren Embedded Control Systems Royal Institute of Technology Stockholm, Sweden {biehl,martin}@md.kth.se Abstract—The development of embedded systems requires a number of tools and it is widely believed that integrating the tools into an automated tool chain can improve the productivity of development. However, tool chains are not accepted by practitioners if they are not aligned with the established development culture, processes and standards. Process models exist for a variety of reasons, i.e., for documenting, planning or tracking progress in a development project and SPEM is the standardized formalism by the OMG for this purpose. We explore in how far a SPEM process models can be used for creating the skeleton of a tool chain, which is aligned with the process. We identify a number of relationship patterns between the development process and its supporting tool chain and show how the patterns can be used for constructing a tool chain. In two case studies, we examine the practical applicability of the patterns, when tailoring the design of a tool chain to a development process. Keywords-Generative Approach; Model Driven Development; Process Modeling; Tool Integration; Embedded Systems.
I. I NTRODUCTION The engineering of an embedded system requires experts from a number of different engineering disciplines. Each engineering discipline prefers a different set of development tools that excel in that particular discipline [1]. The use of single, specialized tools has the potential to improve the development process, depending on the degree of automation they provide [2]. Since engineers need to exchange data and these tools do not interoperate well, a software external to the tools – a tool chain – is needed to facilitate the integration. Multiple tools have the potential to improve the productivity in the development process, depending on how well they are integrated with each other and their degree of automation [3]. Tool chains can provide different coverage of the development process; therefore, we distinguish between task-oriented tool chains with a small coverage and lifecycleoriented tool chains with a larger coverage. Many existing tool chains cover only one task in the development process, e.g., the tool chain between source code editor, compiler and linker. We call these tool chains task-oriented. The tools are used in a linear chain, so that the output of one tool is the input for the next tool. These tool chains have a relatively small scope and integrate a small number of tools from within one phase in the lifecycle. Characteristic for these traditional tool chains are their linear
connections, using a pipes and filter design pattern [4]. In contrast, lifecycle-oriented tool chains have a larger scope, they focus on supporting the complete lifecycle from requirements engineering over verification and implementation to maintenance. In embedded systems development, these tool chains may span multiple disciplines such as software engineering, hardware engineering and mechanical engineering. These tool chains integrate a large number of different development and lifecycle management tools. In addition, modern development processes put new demands on the tool chain: processes might be agile, iterative or model-driven, which implies that the supporting tool chain cannot be linear. When building a tool chain, it is thus important to study which development tools need to be connected. This information about the relationship of development tools is often already available in a formalized model. The Software & Systems Process Engineering Metamodel (SPEM) [5] can be used to describe the lifecycle. A SPEM model might already be available independently from a tool integration effort, e.g., as it is the case development with the Automotive Open Software Architecture (AUTOSAR) [6]. The information available in process models forms the skeleton of a tool chain, i.e., which tools are involved and how they are connected in the process. To construct an executable tool chain as a software solution, more detailed information is needed than is available in process models, e.g., information about the data of tools, how to access it, how to convert it and how to describe the relation between data of different tools. In this paper we evaluate, to what extent information from existing SPEM models can be used for constructing a tool chain. This paper is organized as follows: In Section II, we explain our approach for creating an initial design of a tool chain from a SPEM process model. We introduce SPEM for describing the processes and TIL to describe the architecture of a tool chain in Section II-A. This allows us to describe the relationship between process and tool chain as patterns in Section II-B and introduce ways of using the patterns in Section II-C. We apply the approach in two case studies in Section III. In the remaining sections, we discuss our approach, relate it to other work in the field, sketch future work and consider the implications of this work.
II. A PPROACH Tool chains are intended to increase the efficiency of development by providing connections between tools [3]. Ideally, connections for all tools used throughout the development process are provided; and in this case the tool chain supports the development process. The process provides constraints and requirements for the construction of the tool chain. While generic process models are available, e.g., the SPEM models for the Rational Unified Process (RUP) [7] or for AUTOSAR [6], companies also create individual process models for various purposes, e.g., to customize these generic models to their individual environments, to document the development process, to plan the development process, to track the progress in the development or to document their selection of tools. If the process and the tool chain are described in a model, information from the process model can be reused for constructing a tool chain model. This approach ensures that the tool chain and the process are aligned. Process models only contain some, but not all information necessary for specifying tool chains. Especially the type of the connection between tools needs to be added later on. A. Description of Processes and Tool Chains In this section, we introduce modeling languages that are used for both the process and the design of the tool chain. We select two specific modeling languages, which on the one hand limits the scope of the work, on the other hand is a necessary preparation for formalizing and using the relationship between process and tool chain (cf. future work in Section VI). 1) Modeling the Product Development Process: There are both formal and informal processes in companies, documented to different degrees and there is an increasing trend to model processes. Several established languages exist for modeling processes or workflows. These languages have various purposes, BPMN [8] and BPEL [9] describe business processes and SPEM describes development processes. We apply SPEM, since it is a standardized and relatively widespread language for modeling development processes with mature and diverse tool support. A SPEM model describes both the product development process and the set of tools used and can thus be applied to describe the process requirements of a tool chain. An example model is provided in Figure 2. A number of concepts are defined in SPEM, we introduce here the core concepts that are relevant in the context of tool chains: a Process is composed of several Activities; an Activity is described by a set of linked Tasks, WorkProducts and Roles. A number of relationships, here represented by . , are defined between the concepts of the metamodel: a Role, typically an engineer, can perform a Task and a WorkProduct can be marked as the input or output of a Task. A WorkProduct can be managed by a Tool and a Task can use a Tool.
2) Modeling the Design of the Tool Chain: We need an early design model that describes all important design decisions of a tool chain and chose to use the Tool Integration Language (TIL) [10], a domain specific modeling language for tool chains. TIL allows us not only to model a tool chain, but also to analyze it and generate code from it. The implementation of a tool chain can be partly synthesized from a TIL model, given that metamodels and model transformations are provided. Here we can only give a short overview of TIL, for an elaborated description of concrete graphical syntax, abstract syntax and semantics we refer to [10]. TIL has two basic types: Components and Channels, where Components are connected by Channels. The most important Components are ToolAdapters. For each tool, a ToolAdapter describes the set of data and functionality that is exposed by that tool in form of a tool adapter metamodel. Events can be triggered by Users. The relation between the tool adapters is realized as any of the following Channels: a ControlChannel describes a service call, a DataChannel describes data exchange by a model transformation and a TraceChannel describes the creation of trace links. B. Relationship Patterns between Process and Tool Chain If the process and tool chain are described as a model, we can also model the relationship between them. A process described in SPEM might provide several opportunities for tool integration. Such an opportunity involves two tools and a direct or indirect connection between them. The tools and the connections found in SPEM are included into the tool chain architecture as ToolAdapters and Channels. The direction of the data flow can be determined by the involved work products, which have either the role of input or output of the task. Tasks connected to only one tool or tasks dealing with work products connected to the same tool do not require support from a tool chain; in these tasks engineers work directly with this tool, e.g., by using the GUI of the tool. The challenge is to identify those parts in SPEM model that are relevant for tool integration. The relationship cannot be described by mapping single metaclasses, as in Table I, instead the relationship needs to be described by combinations of several connected metaclasses, which we call patterns. To describe this relationship in more detail, we list patterns of both SPEM and TIL models and their correspondences. The relationship patterns consist of a SPEM part, which matches a subgraph of a process model in SPEM, and a TIL part, which will become a new subgraph in the tool chain model in TIL. In the following, we show four SPEM patterns that describe tool integration related activities, they are illustrated in the top part of Figure 1, and the corresponding TIL pattern is illustrated in the bottom. The mapping is established by pairs of model elements from both SPEM and TIL, whose name attribute is equivalent and whose types
Figure 1.
SPEM and TIL Patterns
are mapped according to the correspondences of metaclasses presented in Table I. Table I C ORRESPONDENCES BETWEEN SPEM AND TIL M ETACLASSES
SPEM Metaclass Role Tool Task •
•
•
•
TIL Metaclass User ToolAdapter Channel
Task-centered Integration Pattern: For each Task in SPEM that has associated WorkProducts as input and output, where the input WorkProduct has a different associated Tool than the output WorkProduct, this pattern produces ToolAdapters and a Channel between them in the TIL model. The pattern is shown in (1) and can be observed in case study 1 in Figure 2 for the Task TraceReq2UML connecting the WorkProduct RequirementsDatabase and the WorkProduct UMLFile. Multi-tool Task-centered Integration Pattern: For each SPEM Task with two SPEM Tools associated with it, this pattern produces ToolAdapters and two Channels between them in the TIL model, since no directionality is modeled in SPEM. This pattern is theoretically possible according to the SPEM metamodel, but we have not observed it in practice. The pattern is illustrated in (2). WorkProduct-centered Integration Pattern: For each SPEM WorkProduct that is both input and output of its associated Tasks, which have a different associated Tool, this pattern produces ToolAdapters and a Channel between them in the TIL model. The pattern is illustrated in (3) and can be observed in case study 2 in Figure 4 for the WorkProduct ECUConfigurationDescription, which is output of the Task GenerateBaseECUConfiguration and input to the Task GenerateRTE. Multi-tool WorkProduct-centered Integration Pattern: For each SPEM WorkProduct in SPEM that is associated to two different Tools, this pattern produces
ToolAdapters and two Channels between them in the TIL model, since no directionality is modeled in SPEM. This pattern is theoretically possible according to the SPEM metamodel, but we have not observed it in practice. The pattern is illustrated in (4). For all relationship patterns, the following constraints need to be fulfilled: For each Role in SPEM that is connected to the Task, we create a User model element in the TIL model, which means that the Role in SPEM and the User in TIL are optional parts in the patterns of Figure I. If a ToolAdapter corresponding to the Tool already exists in the TIL model, the existing ToolAdapter is connected, otherwise a new ToolAdapter is produced. 1) Implementation as Model Transformations: The implementation of the patterns offers possibilities for automation of the pattern usage. We implement the relationship patterns as model transformations, with SPEM as the source metamodel and TIL as the target metamodel. We chose the model-to-model transformation language in QVT-R, with the mediniQVT engine, and the Eclipse Modeling Framework (EMF) for realizing the metamodels. We use a simplified SPEM metamodel in EMF, and for the visualization of SPEM models we use Enterprise Architect. For modeling and visualization of TIL, we use the TIL Workbench described in [10]. Patterns (1) to (4) are graphical representations of the relational QVT model transformation rules. Since QVT relational is a declarative language, the implementation describes the source patterns and the corresponding target patterns in the form of rules. Additionally, the attributes between source and target pattern are mapped, as described in Table I. C. Usage of Relationship Patterns The relationship patterns can be used in different ways. Here, we apply the relationship patterns for constructing the initial design of a new tool chain starting from a process model. Other forms of using the relationship patterns are possible, but are not considered in depth here. We can use the
patterns, e.g., for verification: based on a process model and a tool chain model we check if the requirements provided by the process are realized by the tool chain model. The focus of this paper is the application of the relationship patterns to create an initial tool chain design in TIL from the process requirements expressed in the SPEM model. The patterns can be applied to a SPEM model that is complete and contains all necessary references to Tools. The patterns ensure that the design of the tool chain is aligned with the process, a necessity for acceptance of the tool chain with practitioners. This design of the tool chain can be created in an automated way and might need to be iteratively refined by adding details. The process model only provides the skeleton for the specification of a tool chain, such as the tools, which tools are connected and which user role is working with the tools. The process model does not provide the nature of the connections and the exact execution semantics of the automated tool chain. The nature of the connection can be data exchange, for creating trace links between tool data or for accessing specific functionality of the tool. This information needs to be added manually by configuring and choosing the right type of channel in TIL, a DataChannel, TraceChannel or ControlChannnel. Also, events need to be specified that trigger the data transfer or activate the tracing tool. For each ToolAdapter, a metamodel describing the data and functionality of the tool need to be added to the TIL model. For each DataChannel, a model transformation needs to be added. To handle these cases, we add a refinement step, which complements the automated construction. Once this information is added, the TIL model can be used as input to a code generator for tool chains, as detailed in [11]. III. C ASE S TUDIES In this section, we apply the identified relationship patterns between a process model and a tool chain in two industrial case studies. This gives us the opportunity to study different ways of using the patterns and to explore the impact of different modeling styles. A. Case Study 1: Construction of a Tool Chain Model for a Hardware-Software Co-Design Process This case-study deals with an industrial development process of an embedded system that is characterized by tightly coupled hardware and software components. The development process for hardware-software co-design is textually described in the following: • The requirements of the embedded system are captured in the IRQA1 tool. The system architect designs a UML component diagram and creates trace links between UML components and the requirements. 1 http://www.visuresolutions.com/irqa-web
The UML model is refined and a fault tree analysis is performed by the safety engineer. When the results are satisfactory, the control engineer creates a Simulink2 model for simulation and partitions the functionality for realization in software and hardware. • The application engineer uses Simulink to generate C code, which is refined in the WindRiver3 tool. The data from UML and Simulink is input to the IEC61131-3 conform ControlBuilder tool. The data from ControlBuilder, Simulink and WindRiver is integrated in the Freescale development tool for compiling and linking to a binary for the target hardware. • A hardware engineer generates code in the hardware description language VHDL from Simulink and refines it in the Xilinx ISE4 . Based on the description of the process, we have created the corresponding SPEM model visualized in Figure 2. We apply the model-to-model transformation that realizes the relationship patterns on the SPEM model in Figure 2. This yields a tool chain model that is aligned with the process, as shown in Figure 3. By applying the task-centered integration pattern shown in (1), we identify integration tasks that are linked to two work products that in turn are linked to different development tools (e.g. the task Trafo UML2Safety). Some other tasks are not concerned with integration, they are related to one tool only (e.g. the task Use UML). The TIL model resulting from application of the relationship patterns is internally consistent; this means that there are no conflicts, missing elements or duplications in the model. All tools mentioned in the SPEM model are also present in the TIL model as ToolAdapters and all ToolAdapters are connected. In addition, the approach ensures that the design of the tool chain matches the process. Since the tool chain is modeled, we can easily change, extend and refine the initial model before any source code for the tool chain is developed. The TIL model is relatively small compared to the SPEM model, thus hinting at its effect to reduce complexity. When using the simple complexity metric of merely counting model elements and connections, we see that in the TIL model their number is reduced by 2/3 compared to the SPEM model (cf. table II). •
Table II S IZE OF THE SPEM AND TIL M ODEL OF C ASE S TUDY 1
Count SPEM Model TIL Model
Model Elements 43 13
Connections 71 26
The important architectural design decisions of the tool chain (such as the adapters and their connections) can be 2 http://www.mathworks.com/products/simulink 3 http://www.windriver.com 4 http://www.xilinx.com/ise
Figure 2.
Case Study 1: Product Development Process of the Case Study as a SPEM Model
Figure 3.
Case Study 1: Tool Chain of the Case Study as a TIL Model
expressed in TIL, while the complexity has been decreased compared to a SPEM model (cf. table II). The tool chain model can be analyzed and - after additional refinement with tool adapter metamodels and transformations - can be used for code generation, as detailed in [11], [10]. Moreover, the presented model-driven construction of the tool chain ensures that the tool chain is aligned with the process. B. Case Study 2: Verification of a Tool Chain Model for AUTOSAR ECU Design In this case study, we model a tool chain for AUTOSAR. AUTOSAR is developed by the automotive industry and defines an architectural concept, a middleware and in addition a methodology for creating products with AUTOSAR. The AUTOSAR methodology describes process fragments, so called capability patterns in SPEM. Generic AUTOSAR tool chains are implemented in both commercial tools and open frameworks, however, it is a challenge to set up tool chains consisting of tools from different vendors [12] and tool chains customized to the needs of a particular organization. The SPEM process model is provided by the AUTOSAR consortium and is publicly available, which contributes to the transparency of this case study. An excerpt of this model that is relevant for the design of a ECU, is depicted in Figure 4. We use this excerpt of the SPEM model to initialize a tool chain. Applying the patterns creates the tool chain model in TIL, illustrated in Figure 5. Out of the four different SPEM parts of the relationship patterns (1) - (4), only the workproduct-centered integration pattern (3) matched several times in the SPEM model. This is due to the modeling style used in the AUTOSAR methodology, where WorkProducts are used as an interface for integrating tools. The generated skeleton of the tool chain lays the foundation for ensuring that the AUTOSAR methodology can be realized by this tool chain. The skeleton can now be refined with metamodels, model transformations and the behavior. IV. D ISCUSSION This approach assumes that an appropriate process model for tool chains is available. We assume that the process model does not contain any integration related overhead, i.e., explicit representation of a model transformation tool and intermediate data model. We assume that tools have been assigned to process activities. The choice for certain tools is usually independent of automating the tool chain, the choice merely needs to be documented in the process model. The use of the presented patterns is limited to processes represented in SPEM and tool chains modeled in TIL. However, the patterns could be adapted to similar process metamodels. While it is possible to describe a part of the requirements for a tool chain with SPEM, SPEM models are not executable. We thus extract the relevant information from
SPEM models to ensure that all tools and connections are represented in the tool chain. Based on this information, we generate a TIL models, which can be made executable by following the tool chain development process described in [10]. We have evaluated the approach in two case studies from the area of embedded systems. We do not see any reason why the patterns could not be applied for creating tool chain from process models in other application areas in the future. V. R ELATED W ORK Related work can be found in the areas tool integration and process modeling. There are a number of approaches for tool integration, as documented in the annotated bibliographies [13], [14]. Most of the approaches do not take the process into account; in this section we focus on those approaches that do. We also take approaches from process modeling into account and classify them according to two dimensions: The first dimension comprises different execution mechanisms, which can be interpretation vs. compilation. The second dimension comprises different process modeling languages, which can be proprietary vs. standardized. Interpretation-based approaches [15], [16], [17] use the process definition for tool integration. This technique is also known as enactment of process models. Since the description of the process is identical to the specification of the tool chain, no misalignment between process and tool chain is possible. There are two preconditions for this approach: the process model needs to be executable and the access to data and functionality of the development tools needs to be possible. The use of a proprietary process model for interpretation in tool chains is introduced in [18], as the process-flow pattern. Approaches that extend SPEM make the process model executable [15], [16]. The orchestration of tools by a process model is shown in [17]. However, the interpretation of integration related tasks is often not possible, since the interfaces to the development tools are not standardized. Thus, the use of process enactment to build tool chains is limited. Compilation-based approaches transform the process model into another format, where the process model serves as a set of requirements. Proprietary process models provide great flexibility to adapt them to the specific needs of tool integration. An integration process model is developed in [19], where each process step can be linked to a dedicated activity in a tool. For execution, it is compiled into a lowlevel process model. The proprietary process model needs to be created specifically for constructing a tool chain. In this work, we use the standardized process metamodel SPEM [5], which allows us to reuse existing process models as a starting point for building tool chains and as a reference for verification for tool chains.
Figure 4.
Figure 5.
Case Study 2: Excerpt of the AUTOSAR Methodology for Designing an ECU [6].
Case Study 2: AUTOSAR Tool Chain for Designing an ECU as a TIL Model
VI. C ONCLUSION AND F UTURE W ORK Process models exist for a variety of reasons, i.e., for documenting, planning or tracking progress in a development project and SPEM is the standardized language by the OMG for this purpose. In this paper, we recognize the development process modeled in SPEM as a set of requirements for the architecture of tool chains. We devise a number of patterns for creating the skeleton of a tool chain model in TIL, which is aligned with the process. SPEM offers several ways for describing tool integration. Future work can identify additional SPEM patterns for describing tool integration. Future work can also identify possible uses of additional SPEM constructs for describing tool integration, such as the the SPEM work breakdown structure. In this work, we have selected SPEM to express the patterns; in the future, we would like to experiment with additional languages for describing the process model, such as BPMN. This might help us to further generalize the patterns.
Acknowledgement The research leading to these results has received funding from the ARTEMIS Joint Undertaking under grant agreement 100203. R EFERENCES [1] J. El-khoury, O. Redell, and M. T¨orngren, “A Tool Integration Platform for Multi-Disciplinary Development,” in 31st EUROMICRO Conference on Software Engineering and Advanced Applications, pp. 442–450, 2005. [2] T. Bruckhaus, N. H. Madhavii, I. Janssen, and J. Henshaw, “The impact of tools on software productivity,” Software, IEEE, vol. 13, no. 5, pp. 29–38, Sep. 1996. [3] M. Wicks and R. Dewar, “A new research agenda for tool integration,” J. of Sys. and Sw., vol. 80, no. 9, pp. 1569–1585, Sep. 2007. [4] M. Shaw and D. Garlan, Software architecture. Hall, 1996.
Prentice
[5] OMG, “Software & Systems Process Engineering Metamodel Specification (SPEM),” ”OMG”, Tech. Rep., Apr. 2008. [6] AUTOSAR Consortium. (2011, Apr.) Automotive open software architecture (AUTOSAR) 3.2. [Online]. Available: http://autosar.org/ [7] P. Kruchten, The Rational Unified Process. Addison-Wesley Pub (Sd), 1998. [8] OMG, “Business Process Model And Notation (BPMN),” ”OMG”, Tech. Rep., Jan. 2011. [9] OASIS, “OASIS Web Services Business Process Execution Language (WSBPEL) TC,” ”OASIS”, Tech. Rep., Apr. 2007. [10] M. Biehl, J. El-Khoury, F. Loiret, and M. T¨orngren, “On the Modeling and Generation of Service-Oriented Tool Chains,” Journal of Software and Systems Modeling, vol. 275, 2012 [Online]. Available: http://dx.doi.org/10.1007/ s10270-012-0275-7 [11] M. Biehl, J. El-Khoury, and M. T¨orngren, “High-Level Specification and Code Generation for Service-Oriented Tool Adapters,” in ICCSA2012, pp. 35–42, Jun. 2012. [12] S. Voget, “AUTOSAR and the automotive tool chain,” in Proceedings of the Conference on Design, Automation and Test in Europe, ser. DATE ’10, pp. 259–262, 2010. [13] M. N. Wicks, “Tool Integration within Software Engineering Environments: An Annotated Bibliography,” Heriot-Watt University, Tech. Rep., 2006. [14] A. W. Brown and M. H. Penedo, “An annotated bibliography on integration in software engineering environments,” SIGSOFT Softw. Eng. Notes, vol. 17, no. 3, pp. 47–55, 1992. [15] A. Koudri and J. Champeau, “MODAL: A SPEM Extension to Improve Co-design Process Models New Modeling Concepts for Today’s Software Processes, LNCS vol. 6195, ch. 22, pp. 248–259, 2010. [16] R. Bendraou, B. Combemale, X. Cregut, and M. P. Gervais, “Definition of an Executable SPEM 2.0,” in APSEC, pp. 390–397, 2007. [17] B. Polgar, I. Rath, Z. Szatmari, A. Horvath, and I. Majzik, “Model-based Integration, Execution and Certification of Development Tool-chains,” in Workshop on model driven tool and process integration, pp. 36–48, Jun. 2009. [18] G. Karsai, A. Lang, and S. Neema, “Design patterns for open tool integration,” Software and Systems Modeling, vol. 4, no. 2, pp. 157–170, May 2005. [19] A. Balogh, G. Bergmann, G. Csert´an, L. G¨onczy, Horv´ath, I. Majzik, A. Pataricza, B. Polg´ar, I. R´ath, D. Varr´o, and G. Varr´o, “Workflow-driven tool integration using model transformations,” in Graph transformations and model-driven engineering, pp. 224–248, 2010.
Appendix F
Model-based Service Discovery and Orchestration for OSLC Services in Tool Chains Matthias Biehl, Wenqing Gu, and Frederic Loiret in International Conference on Web Engineering (ICWE2012) July 2012 c
2012 Springer. Reprinted with permission.
Model-based Service Discovery and Orchestration for OSLC Services in Tool Chains Matthias Biehl1 , Wenqing Gu1,2 , and Fr´ed´eric Loiret1 1
Royal Institute of Technology, Stockholm, Sweden, {biehl,floiret}@md.kth.se 2 Ericsson AB, Kista, Sweden,
[email protected]
Abstract. Globally distributed development of complex systems relies on the use of sophisticated development tools but today the tools provide only limited possibilities for integration into seamless tool chains. If development tools could be integrated, development data could be exchanged and tracing across remotely located tools would be possible and would increase the efficiency of globally distributed development. We use a domain specific modeling language to describe tool chains as models on a high level of abstraction. We use model-driven technology to synthesize the implementation of a service-oriented wrapper for each development tool based on OSLC (Open Services for Lifecyle Collaboration) and the orchestration of the services exposed by development tools. The wrapper exposes both tool data and functionality as web services, enabling platform independent tool integration. The orchestration allows us to discover remote tools via their service wrapper, integrate them and check the correctness of the orchestration. Key words: Service Discovery; Service Orchestration; Model-driven Development; Tool Integration
1
Introduction
Globally distributed software development teams need tool chains that are flexible, distributed and tailored to their development processes [12]. To deal with these new requirements, modern tool chains apply the principles of serviceoriented computing [8, 11], which deals with the generic integration of distributed services [9]. When applying the service-oriented principles to tool integration, tools expose both their data and functionality as services; these services are orchestrated to form a tool chain. The industry initiative Open Services for Lifecycle Integration (OSLC) [15], advocates a service-oriented, RESTful [7] architecture for managing tool data. The challenge in adopting the OSLC approach for tool integration lies in finding appropriate mechanisms for discovering the RESTful services of remotely deployed development tools and to orchestrate the RESTful services of remote development tools. However, there is currently no standard and no practical support for discovering and orchestrating RESTful web services [17]. Due to the
lack of a high-level design language for orchestration of RESTful web services, solutions are typically directly implemented in code; an overview of the details of this challenge is provided in [16]. As a result, the orchestration of tools requires a lot of manual work. In addition, inconsistencies can only be found on code-level, which is difficult, time-consuming and expensive. In this paper, we propose a model-based approach to address both discovery and orchestration for RESTful services in the domain of tool integration. We introduce a domain-specific modeling language for tool integration that allows us to describe both the tool chain as an orchestration of tools and the specification of the services of each tool. This specification is the basis for both the discovery of tool services and the generation of an implementation. The domain specific model allows us to perform early correctness checks between the service usage and the service definition in the service specification.
2
Approach
To close the gap between discovery and orchestration of RESTful services for OSLC tool integration, our approach interleaves service discovery and service orchestration for tool integration, as illustrated in Figure 1. We propose a modelbased approach, which seamlessly integrates the results of service discovery with orchestration facilities. The pivot point of this approach is the discovered ToolAdapter metamodel; it is the central connection point between the service discovery and the service orchestration.
Fig. 1. Approach for model-based discovery and orchestration
The automated process of service discovery is displayed on the vertical axis in Figure 1 and explained in Section 4. Discovery automatically deduces details of an already deployed tool adapter service, from which only a URL is known as an entry point. Discovery starts with the service URL, extracts the ToolAdapter
metamodel using the OSLC ServiceCatalogs and ServiceProviders and finally generates code for the service proxies. The process of service orchestration is displayed on the horizontal axis in Figure 1 and explained in Section 3. It starts with several ToolAdapter metamodels, which might be discovered or newly created and integrates the ToolAdapters into an orchestration model. The formalized ToolAdapter metamodel can even be used for verifying the discovered service definition against its usage in the orchestration model by a number of correctness checks, as described in Section 5. Finally we generate code for the orchestration, as detailed in Section 6.
3
Service Orchestration for Tool Integration with TIL
Tool chains are often put together in an ad-hoc manner. We promote a systematic development process, where a high-level design of the tool chain is created first. We would like to describe the design of a tool chain in such a way that all important design decisions of a tool chain can be reflected in it. This is why we apply the Tool Integration Language (TIL) [3], a domain specific modeling language for describing tool chains. TIL allows us not only to model a tool chain, but also to analyze it and generate code from it. Here we can only give a short overview of this language and for a detailed explanation of the semantics of TIL, we refer to [3]. In TIL, a tool chain is described in terms of ToolAdapters and the relation between them. For each tool, a ToolAdapter defines the set of data and functionality that is exposed by that tool in form of a ToolAdapter metamodel. The ToolAdapter metamodel is realized using EMF (Eclipse Modeling Framework)3 . The relation between the ToolAdapters is realized by any of the following Channels: a ControlChannel describes a service call, a DataChannel describes data exchange or a TraceChannel describes the possibility to create traces. A trace is a link between two elements of tool data, which may reside in different tools. TIL offers three kinds of ToolAdapters. A GeneratedToolAdapter is newly created, locally deployed and the ToolAdapter metamodel is used as specification. A BinaryToolAdapter is included into the tool chain by locally deploying existing binaries and then binding to them. A DiscoveredToolAdapter is included into the tool chain by binding to an already deployed ToolAdapter on a remote server, it is merely specified by a URL. Realizing the binding in TIL requires a discovery process, which is described in Section 4.
4
Service Discovery for Tool Integration
OSLC provides a catalog of linked metadata descriptions. The general idea is to use the catalog for remote discovery of tool adapters by following the links and parsing the metadata. We can discover the details of remotely deployed ToolAdapters that follow the OSLC specification. The key task of the discovery 3
http://www.eclipse.org/modeling/emf
process is to interact with the OSLC directory services to extract a ToolAdapter metamodel. This ToolAdapter metamodel describes the data and functionality provided by the tool adapter and acts as an intermediate model in the discovery algorithm. When parsing the OSLC metadata, we need to make some assumptions, because the OSLC catalog is not originally intended for the purpose of service discovery, but it contains useful information. The starting point for discovering services is the URI of the ServiceProviderCatalog. From the content of the ServiceProviderCatalog the algorithm follows to ServiceProvider s and ResourceShapes. All these resources are described in RDF [13] and we parse them with the Jena framework4 . – Step 1 - Parse ServiceProviderCatalog: By parsing the response of an HTTP-GET on the URI of the ServiceProviderCatalog, we can identify a set of ServiceProvider resources. OSLC related information concerning the ServiceProviderCatalog is extracted and saved. For each ServiceProvider resource we continue with step 2. – Step 2 - Data or Control Service: We perform a GET on the URIs of all ServiceProviders. We make the following assumptions for OSLC directory services: data and control services are encapsulated in separate ServiceProvider resources. For a control ServiceProvider only inlined CreationFactory resources exist, for a data ServiceProvider both CreationFactory and QueryCapability resources exist. With these assumptions we can identify the correct type of ServiceProvider by checking if the current ServiceProvider contains any QueryCapability resources. For a data ServiceProvider we proceed with step 3, for a control ServiceProvider we proceed with step 6. – Step 3 - Find Data Resources: Each inlined CreationFactory or QueryCapability property represents one data resource, however, for the name of this data resource we have to assume it is contained in the URI of the inner property resourceShape, resourceType, creation or queryBase. With the listed sequence, we anticipate the resource name by extracting the last word of the URI. We use the simplest way to anticipate the correct name, which is to select the first URI in the listed sequence. For each data resource, we check if the URI of ResourceShape resource is given in the response. If it is provided, details of this data resource can be constructed by parsing the ResourceShape given, otherwise we query one or more specific objects of this data type to anticipate the structure of the resource. We follow step 4 if the URI of ResourceShape is given and step 5 otherwise. – Step 4 - Construct Data Resource Structures by Parsing the ResourceShape: Properties of the current data resource are analyzed and added to the corresponding class in the ToolAdapter metamodel as attributes or references. More specifically, for properties of primitive data types like string, int, etc. an attribute is added to the class. For other types we determine the referenced data type by analyzing the URI of the given valueShape 4
http://incubator.apache.org/jena/
or valueType property as described in step 3 and add a corresponding reference to the current class. In OSLC, the multiplicity is described by the occurs property. Possible values are Zero-or-one, Exactly-one, One-or-many and Zero-or-many. After the structure of the data has been discovered, the ToolAdapter metamodel is updated. – Step 5 - Construct Data Resource Structures by Querying Object Details: If there is no annotated ResourceShape given for a specific resource, we have to discover the structure of this resource by querying a specific instance of this data type. We obtain the list of objects by following the URI of QueryCapability. By analyzing the content of the response, we can obtain the attributes or references of the current data type. Since attributes are optional in RDF, we may need to query several objects, to increase the probability of acquiring a complete set of all the properties. We assume that the name of the attributes or references can be deduced from the local name in the properties of the response, and the referenced data type is directly from the local name of the resource type following the resource URI. – Step 6 - Find Control Resources: By analyzing the URIs of the creationFactory, we can obtain a list of provided control resources. The resource name is obtained from the URI of creation. – Step 7 - Persist Discovered Tool Adapter Metamodel: The discovery is finished and we save the discovered ToolAdapter metamodel.
5
Correctness Check
A correct and consistent TIL model is a prerequisite for the generation of correct source code that realizes the tool chain. We check the TIL model for correctness by analyzing if all service usages comply with their definitions. The definitions of the ToolAdapter services are located in the ToolAdapter metamodels. The usage of ToolAdapter services is specified in the TIL model, more specifically in the different types of Channels. The correctness check ensures that the usages of the services are conform to their definitions. The checks are performed early in the development process of a tool chain, on a model-level, before code is involved. Thus errors are relatively easy to detect and correct.
6
Code Generation
We describe the code generation in this section by describing (1) the chosen implementation framework, (2) the mapping of high-level concepts of TIL to the implementation and (3) the creation of proxies for DiscoveredToolAdapters. Our approach is implemented using the Service Component Architecture (SCA) [2], a set of specifications for developing distributed Service-Oriented Architectures (SOA). SCA combines SOA principles [6] with principles of ComponentBased Software Engineering (CBSE). While SOA provides the notion of looselycoupled services, CBSE provides composability of software components. SCA is a component model for implementing and composing heterogeneous services.
We use the SCA implementation FraSCAti [19], which manages the web server infrastructure, produces the necessary glue code and also provides remote deployment, introspection and reconfiguration at runtime. SCA allows us to define RESTful services and bindings, which makes it possible to implement a tool chain according to OSLC. We found that SCA is an appropriate technology for realizing service-oriented tool chains based on OSLC. The tool chain is an orchestration of services provided by both locally deployed GeneratedToolAdapters and remotely deployed DiscoveredToolAdapters. The latter are represented by local proxies bound to the remotely deployed tool adapter implementation. For implementing the interface we use the Service Component Architecture (SCA). By specifying the binding address of the remotely deployed ToolAdapter, SCA tool support can generate the proxy implementation that forwards calls to it. For each DiscoveredToolAdapter an SCA component is generated, acting as a local proxy of the discovered adapter. As a proxy, it provides the services of the ToolAdapter metamodel that were retrieved by the discovery process. The services of the local proxy are bound to the remote services provided by the remotely deployed ToolAdapters. SCA allows the specification of remote bindings that are managed transparently by the SCA runtime platform. The orchestration components are SCA components generated from the ControlChannels and the DataChannels, and bound to the proxy components according to the control and data flows they specify in the orchestration model.
Fig. 2. Architecture of the Discovered ToolAdapter
We use the discovered ToolAdapter metamodel for generating code proxies for the ToolAdapter, which can be used to bind to the remotely deployed ToolAdapter instance. The complete ToolAdapter architecture is represented in Figure 2. We distinguish between the remotely deployed ToolAdapter and the DiscoveredToolAdapter. The remotely deployed ToolAdapter already exists and is usually deployed on the same machine as the tool. In the implementation of the remotely deployed ToolAdapter, we separate the code that deals with the integration technology from the code that interacts with the tool. The external part of the remotely deployed ToolAdapter deals with the integration technology, the internal part interacts with the tool, e.g. via local APIs. The DiscoveredToolAdapter is a proxy to the remotely deployed ToolAdapter. It has the same interface as the external part of the remotely deployed ToolAdapter and its implementation merely forwards the service calls. Note that our approach is built for the case in which we do not have access to the source code of the remotely deployed ToolAdapter. The benefits of automated generation are time, effort and
cost saving. They can be achieved since the developers of the ToolAdapter do not need to learn the integration technology, nor do they need to implement any code that deals with the integration technology. A model-to-text transformation automatically generates the source code of the DiscoveredToolAdapter.
7
Case Study
We evaluate the proposed approach in a case study, where a tool chain for hardware-software co-design of an embedded system is created. Using TIL, a tool chain designer models the orchestration of this tool chain as described in Section 3, resulting in Figure 3.
Fig. 3. A tool chain for hardware-software co-design of an embedded system modeled in TIL [3]
This tool chain includes a requirements engineering tool, UML tool for system design, Simulink for simulation, WindRiver and Freescale for software implementation and Xilinx for hardware realization. The tool chain is an orchestration of local GeneratedToolAdapters and one remote ToolAdapter for Simulink. The Simulink ToolAdapter is already deployed on a server (DiscoveredToolAdapter ) with the URI http://kth.se/sl and will be discovered for integration and orchestration. This tool chain is realized following the principles of the OSLC initiative. Thus the existing Simulink ToolAdapter is discovered following the steps 1 to 7 described in Section 4. – Step 1: We can obtain the response of the ServiceProviderCatalog by GET http://kth.se/sl/oslc/service_provider_catalog. By parsing the content we can identify the URIs of two oslc:ServiceProvider resources, which
–
–
–
–
–
–
will be further processed in step 2. We also obtain the dcterms:title and dcterms:description properties of the current ServiceProviderCatalog resource. Step 2: The oslc:ServiceProvider with the URI http://kth.se/sl/oslc/ service_provider/data is a data ServiceProvider, because each service has both oslc:CreationFactory and oslc:QueryCapability resources. Step 3: We can identify three data resources in the data resource provider with the URI http://kth.se/sl/oslc/service_provider/data. The resources are Block, Connection and Port. For the oslc:CreationFactory with label Block, we can anticipate the name of the data resource as Block by extracting the last word of the URI http://kth.se/sl/shapes/Block of the property oslc:resourceShape. Step 4: We analyze the response of the oslc:ResourceShape of the Block resource with URI http://kth.se/sl/shapes/Block. We can identify the attributes uuid, name, type and the references parent, children, ports and lines. For the references, we determine the data type as described in step 3. Step 5: If we did not have a oslc:ResourceShape for the Block resource, we would have to follow the URI http://kth.se/sl/block to get a list of the URIs of all Block instances. We follow any one of the URIs, we can get the details of one instance. By analyzing the detailed response of the Block object with URI http://kth.se/sl/block/1, we can learn that the object has attributes type, name, uuid and references ports with URI http: //kth.se/sl/port/2 and children with URI http://kth.se/sl/block/3. Step 6: We can identify the control resources like loadModel, startSimulation, etc. from the response of oslc:ServiceProvider with the URI http://kth. se/sl/oslc/service_provider/control. Step 7: The discovered service model of MATLAB/Simulink is presented in Figure 4.
Fig. 4. Discovered ToolAdapter metamodel for MATLAB/Simulink
After discovery, we perform a correctness check between the orchestration model in Figure 3 and the discovered ToolAdapter metamodel from Figure 4, as described in Section 5. The algorithm detects that the service simulate used in
the orchestration is not defined in the ToolAdapter metamodel of Simulink; it needs to be changed to startSimulation. After these changes the model is correct and we generate code for the implementation of the tool chain. For verification of the discovered metamodel, we compare it to the original metamodel that was used for generating the Simulink ToolAdapter: the discovered metamodel contains all information from the original metamodel and in addition it contains annotations concerning the deployment, such as the deployment URI of each service.
8
Related Work
Related work can be found in the areas of tool integration, service discovery and orchestration. We list the approaches by fields and point out approaches that are in the intersection of both fields. Tool Integration: Model-based integration frameworks [1] use metamodeling for describing the tool data. However, these approaches provide neither concepts to model a complete tool chain nor concepts to describe the orchestration architecture of the tool chain. Model-based tool chains are usually realized locally. Tool chains based on the integration framework ModelBus [11] may be distributed. ModelBus uses the SOAP protocol, so discovery, orchestration and correctness checks can be performed. Service Discovery and Orchestration: Web services based on SOAP [20] are usually described using WSDL (Web Service Description Language) [5]. WSDL is a W3C standard and is widely supported. In order to orchestrate WSDLbased web services, typically BPEL (Business Process Execution Language) [14] is used. The discovery and orchestration of RESTful web services is not equally well supported. The current BPEL 2.0 only supports WSDL 1.1, which is incompatible with RESTful services. RESTful web services can be described in WADL [10] and WSDL 2.0 [4], which is currently not supported by BPEL. Even if the next version of BPEL will support WSDL 2.0, a lot of manual work is required to consume the RESTful services provided, since the burden of creating the WSDL file has shifted from the service supplier to the BPEL designer. The reason is that no WSDL descriptions are provided by the RESTful service supplier. The main alternative is manual coding of the orchestration. A number of approaches for the orchestration of RESTful services have recently been proposed. The extension BPEL for REST [17] and the language Bite [18] have been developed for integration of RESTful services. In SCA, the binding of RESTful web services is possible, however a common Java interface must be used to invoke the web services. The added value of our approach is the domain specific support for OSLC, the correctness check of the orchestration and the code generation facilities.
9
Future Work and Conclusion
In the future we would like to improve the precision of the discovery algorithm and perform additional case studies of tool chains for different development pro-
cesses. The cornerstone of this approach is the language TIL that describes both the orchestration of ToolAdapters and the ToolAdapter as models. The discovery algorithm finds the details of an initially unknown ToolAdapter and represents them as a model. Both the orchestration and the results of the discovery are models, which allows us to verify their compatibility and correctness. As a consequence of this automated support for discovery, orchestration and correctness checks, distributed tool chains can be built faster and with less errors.
References 1. C. Amelunxen, F. Klar, A. K¨ onigs, T. R¨ otschke, and A. Sch¨ urr. Metamodel-based tool integration with MOFLON. In ICSE ’08, pages 807–810, 2008. 2. M. Beisiegel. Service Component Architecture, Tech. Rep., November 2007. 3. M. Biehl, J. El-Khoury, F. Loiret, and M. T¨ orngren. A domain specific language for generating tool integration solutions. In MDTPI2011, June 2011. 4. R. Chinnici, J. J. Moreau, A. Ryman, and S. Weerawarana. Web services description language (WSDL) version 2.0 W3C, 26, 2007. 5. Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web service definition language (WSDL). Technical report, W3C, March 2001. 6. Thomas Erl. SOA Principles of Service Design. Prentice Hall, July 2007. 7. Roy T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, University of California, Irvine, 2000. 8. R. Frost. Jazz and the Eclipse way of collaboration IEEE Software, 2007. 9. S. Gilmore, L. G¨ onczy, N. Koch, P. Mayer, M. Tribastone, and D. Varr´ o. Nonfunctional properties in the MDD of SOS. SoSyM, 2011. 10. Marc J. Hadley. Web application description language (WADL). W3C, 2006. 11. C. Hein, T. Ritter, and M. Wagner. Model-Driven tool integration with ModelBus. In Workshop Future Trends of Model-Driven Development, 2009. 12. J. D. Herbsleb. Global software engineering: The future of socio-technical coordination. In FOSE07, 2007. 13. G. Klyne and J. Carroll. RDF: Concepts and abstract syntax. 2004. 14. OASIS. Web Services Business Process Execution Language (WSBPEL). 2007. 15. OSLC Workgroup. OSLC Core Specification, version 2.0. 2010. 16. C. Pautasso. On Composing RESTful Services. In Software Service Engineering, 2009. 17. C. Pautasso. RESTful web service composition with BPEL for REST. Data Knowledge Engineering, 2009. 18. F. Rosenberg, F. Curbera, M. J. Duftler, and R. Khalaf. Composing RESTful Services and Collaborative Workflows: A Lightweight Approach. Internet Computing, IEEE, 2008. 19. L. Seinturier, P. Merle, R. Rouvoy, D. Romero, V. Schiavoni, and J. Stefani. A Component-Based Middleware Platform for Reconfigurable Service-Oriented Architectures. Software: Practice and Experience, 2011. 20. W3C. Simple Object Access Protocol (SOAP) 1.2. W3C, 2007.
Appendix G
Automated Construction of Data Integration Solutions for Tool Chains Matthias Biehl, Jiarui Hong, and Frederic Loiret in Seventh International Conference on Software Engineering Advances (ICSEA2012) November 2012
Automated Construction of Data Integration Solutions for Tool Chains Matthias Biehl, Jiarui Hong, Frederic Loiret Embedded Control Systems Royal Institute of Technology Stockholm, Sweden {biehl,hong,floiret}@md.kth.se Abstract—Modern software development relies increasingly on the orchestrated use of development tools in the form of seamless, automated tool chains. Tool chains are becoming complex software systems themselves, however, the efficient development of tool chains is a largely unsupported, manual engineering task. We propose both a domain specific modeling language for systematically specifying tool chains and generators for efficiently realizing the tool chain as software. Tool chain software consists of diverse components, such as service-oriented applications, models and model transformations, which we produce by different generative techniques. We study both the separate generative techniques and the dependencies between the generated artifacts to ensure that they can be integrated. We evaluate the approach both quantitatively and qualitatively, and show in a case study that the approach is practically applicable when building a tool chain for industrially relevant tools. Keywords-Domain Specific Modeling; Tool Integration; Prototyping; Higher-Order Model Transformation; Code Generation.
I. I NTRODUCTION Since modern development relies more and more on sophisticated development tools, the integration of these tools becomes an important issue. The development tools may be modeling tools, simulation tools, verification tools etc., which are typically not designed with ease of integration in mind [7]. The integration of development tools thus requires a sizable engineering effort, including the extraction of data from the integrated tools, adherence to integration standards and mapping of the data between the formats of different tools. Manually implementing the tool chain is time-consuming and error-prone. Realizing a model-based tool chain as software involves writing source code for two distinct parts. The first part deals with setting up the infrastructure for model-based tool integration, such as transformation engines or tracing tools. The second part realizes the actual exchange of tool data, such as the extraction of data from the tool and its transformation into a different format or representation. Several approaches for tool integration are mentioned in the literature, for example model-based tool integration [1], weaving-based tool integration [6] or ontology-based tool integration [12]. Model-based tool integration assumes that data of different tools is available in the form of models,
which adhere to metamodels, and model transformations, which describe the data conversion [1]. The focus of modelbased tool integration is thus on describing tool data and its relations (expressed as models, metamodels and transformations). The entire tool chain, however, is only an implicit concept. As a result of this lack of an overall picture of the tool chain, existing approaches do not uncover the potential for supporting the development of complete tool chains. Existing approaches typically assume that the source code for providing tool data and functionality is implemented manually. If the implementation needs to follow integration standards, such as OSLC (Open Services for Lifecycle Collaboration) [24], it can be tedious to implement this code. Existing approaches also assume that the data conversion rules, which are necessary for data exchange between tools, are implemented manually, e.g., in the form of weaving models or model transformations. Support to synthesize the conversion rules is missing. The goal of this paper is to systematize and partly automate the development of tool chains. The central question we address is thus: To what extent can the development of tool chains be automated through generative techniques? Our approach is model-based, but differs from previous model based approaches, as not only the tool data is modeled, but also the architecture of the complete tool chain. For this purpose we use a domain specific modeling language for tool chains, which structures the tool chain into components and connectors. A generative approach uses the structured information to synthesize implementations for the components, the connectors and the infrastructure of the tool chain. In previous work, we have described the modeling language [4], code generation of the components [5] and infrastructure [4]. The contribution of this paper is the automated synthesis of the data conversion rules in the connectors and the integration of the various generated parts into a complete, cohesive tool chain. II. A PPROACH From our experience of developing tool chains in an industrial context, tool chains are often developed with an iterative prototyping approach. While the general goal for the tool chain might be clear to all stakeholders, the exact
details of the execution and conversion in the tool chain might not be clear and different design options are explored with prototype implementations. The challenge lies in the large effort of creating one or potentially many prototype implementations of the tool chain. It involves creating a software adaptation layer – we call it a ToolAdapter – for each integrated tool and data conversion rules for the tool data that allow for data-transfer between the tools – we call it a DataChannel. The method and automated techniques of the proposed approach aim to reduce the necessary development effort for tool chains. In our approach, the user models the tool chain using abstractions from the domain of tool integration. A prototype implementation of a tool chain is produced by generating both source code and conversion rules from the tool chain model. In the following sections, we describe how we achieve the specification and the automated synthesis of the executable prototype. We divide the approach into several steps, as illustrated in Figure 1: • Step 1 - Specification of a Tailored Tool Chain: The essential design decisions are described by modeling the tool chain in the Tool Integration Language (TIL) [4]. More details on modeling with TIL are presented in Section III. • Step 2 - Synthesis of ToolAdapters: The synthesis automatically generates code based on the specification of the ToolAdapters. It is presented in Section IV. • Step 3 - Synthesis of Channels: The synthesis automatically generates code and transformation rules, based on the specification of the Channels. It is presented in Section V. • Step 4 - Integration of Synthesis Results: The generated parts need to be integrated into a tool chain implementation, as presented in Section VI. • Step 5 - From Prototype to Production Software: The prototype tool chain can be refined into a production tool chain, as presented in Section VII. Steps 1 - 4 are typically iterated multiple times, until a satisfactory prototype is identified. Since only step 1 is manual and steps 2, 3 and 4 are automated, this is a viable iterative development approach for tool chains. We evaluate the approach qualitatively by a running example, which is embedded in Sections III-VII. We evaluate the approach quantitatively in Section VIII. In Section IX, we show the relation of this approach to other work in the field; in Section X, we mention future work and conclude. A. Introduction to the Running Example We illustrate all steps of the approach by stepwise constructing a tool chain, which serves as a running example. The intended use of the tool chain presented as running example is in the early design phase of automotive embedded system development [2]. An engineer creates a UML-conform model with behavioral and fault propagation
Figure 1.
Overview of steps 1-4 of this approach
models using the GUI of the development tool and commits the model to the repository. Every time a new version of the UML model is committed, the tool chain executes a transformation of the UML model to the input format of the fault tree analysis tool HiP-HOPS (Hierarchically Performed Hazard Origin and Propagation Studies) [25] and executes HiP-HOPS. Another model transformation creates a MATLAB/Simulink model that mirrors the structure of the UML model. When the results of the fault tree analysis are satisfactory, i.e., there are no single points of failure, the engineer manually extends this Simulink model to perform simulations. III. S TEP 1 - S PECIFICATION OF A TAILORED T OOL C HAIN The prototyping process starts by specifying the big picture of the tool chain. We use TIL, a domain specific modeling language for tool chains. TIL models are concise, and expresses domain concepts, so users can relate to it. TIL allows us not only to describe a tool chain graphically, but also to analyze it and generate code from it. Here, we can only give a short overview of the language, for more detailed description, we refer to [4]. In the following, we introduce the language concepts and their concrete graphical syntax (compare 1 .. 7 in Figure 2). TIL is a component-based language and consists of Components (ToolAdapter, Repository, Sequencer, User) and Connectors (ControlChannel, TraceChannel, DataChannel). • A ToolAdapter 1 exposes the data and functionality of a tool in a common technical format, making the data and functionality accessible for other ToolAdapters within the tool chain. A ToolAdapter is specified by means of a ToolAdapter metamodel. It describes the selection of data and functionality of the tool, which is exposed to the tool chain (see Figure 4, for an example). Creating the metamodel requires some engineering effort, since each tool has its own metamodel, there is no common metamodel.
Figure 2. A simple TIL model illustrating the graphical syntax of the language concepts
•
•
•
•
•
•
A ControlChannel 2 describes the control-flow between two Components by specifying a triggering event in the source, a called service in the target and a guard for conditional execution. A TraceChannels 6 connects two ToolAdapters and describes the possibility of creating traces between elements of certain data types of the ToolAdapter metamodels. A DataChannels 5 connects two ToolAdapters and describes the data-flow between them. The DataChannel preserves the semantics of the data. Since the ToolAdapter delivers all exposed data in a common technical format, only the data structure needs to be adapted. The data of the source ToolAdapter needs to be transformed into the structure expected by the target ToolAdapter. A model transformation can either be manually specified or it can be automatically synthesized, as described in Section V. A Sequencer 3 describes sequential control-flow; it executes a sequence of services in a specified order. The sequencer is used in combination with ControlChannels: it is activated by a ControlChannel and each of the sequentially called services is connected via a ControlChannel. A User 4 is a representative for a real tool chain user. This concept is used to describe the possible interactions of the real users with the tool chain. Outgoing ControlChannels from the User denote services invoked by the user, incoming ControlChannels to a User denote a notification sent to the user. A Repository 7 is a specific type of ToolAdapter that provides storage and version management of tool data.
A. Running Example: Step 1 We specify the previously introduced tool chain in TIL, resulting in the model displayed in Figure 3. An engineer, depicted by the user symbol, develops a new function of an embedded system as a UML component model. The engineer checks the model into the Subversion Repository,
depicted by a ControlChannel, which activates the DataChannel uml2repository. Automatically, the model will be analyzed by a safety analysis tool to detect single points of failure in the embedded system. This is depicted by the triangular shape for the Sequencer Seq0, which is activated by a ControlChannel, whenever new UML models are checked into the repository. The Sequencer Seq0 first triggers the DataChannel uml2safety to transfer the UML model to the safety analysis tool involving a model transformation. The Sequencer Seq0 then calls the function to analyze single points of failure in the safety analysis tool. If no single points of failure have been found, which is expressed as a guard condition on the ControlChannel, a simulation of the behavior of the new model is started in Simulink. This is realized by another set of ControlChannels and the Sequencer Seq1. Finally, the engineer receives an email notification about the simulation results. The TIL model presented in Figure 3 is linked to several ToolAdapter metamodels, which are illustrated in Figure 4. In addition, model instances of these metamodels are linked to each ToolAdapter. They serve as test data for the prototype implementation. Each of the metamodels describes the subset of the data of the tool that is exposed by the ToolAdapter towards the tool chain. The metamodel for the MATLAB/Simulink tool (A) describes a basic block diagram. The metamodel for the UML tool (B) comprises the elements of a basic UML component diagram. The metamodel for the safety analysis tool HiP-HOPS (C) is organized into systems and subsystems. IV. S TEP 2 - S YNTHESIS OF T OOL A DAPTERS ToolAdapters are realized as software components that have a web-based, service-oriented architecture. This provides platform independence and allows for a distributed tool chain, where tools may reside on different network nodes. The input of the generator is the ToolAdapter metamodel and a model with test data, which conforms to the metamodel. The output is a Java source code and configuration files for the service infrastructure, such as a web server listening for requests. The generated Java source code provides a skeleton of the tool adapter implementation, including an implementation that operates on static test data and serves it conform to the format and protocols of the industrial initiative OSLC. The generated ToolAdapter is thus functional, but does not yet connect to the tool instance via APIs. The connection to the tools has to be added manually in step 5. Since the details of generating service-oriented tool adapters are not the focus of this work, we refer to paper [5] for more details and examples. V. S TEP 3 - S YNTHESIS OF C HANNELS The Channels between ToolAdapters can describe controlflow or data-flow. Control-flow is expressed by ControlChannels, which are straightforward to synthesize as remote
Figure 3.
Figure 4.
Specification of the tool chain as a TIL model
ToolAdapter metamodels for the Simulink tool (A), UML tool (B) and safety analysis tool (C)
service calls to other ToolAdapters. Data-flow can be expressed by TraceChannels or DataChannels. TraceChannels provide the infrastructure for creating traces at runtime of the tool chain and this infrastructure is quite straightforward to generate. DataChannels denote the transfer of data from a source ToolAdapter to a target ToolAdapter. The tool data is served by the ToolAdapter in the form of a model that conforms to the ToolAdapter metamodel. If the metamodels of source and target ToolAdapters are the same, the data can be simply copied between the ToolAdapters. In the more common case that the metamodels are different, the data needs to be transformed before it can be accepted by the target ToolAdapter. For this purpose, TIL offers the possibility to link a model transformation to each DataChannel. This transformation is a part of the implementation of the DataChannel and can be either manually specified or synthesized. If a transformation is required (due to different source and target ToolAdapter metamodels), but none is specified, a prototype transformation can be automatically synthesized. Another part of the implementation of DataChannels is the infrastructure for executing the transformation and transferring the data to another ToolAdapter. The synthesis algorithm generates source code for the ControlChannels as well as source code for the infrastructure of DataChannels. This infrastructure accomplishes the following tasks at runtime of the tool chain: it gets the source model from the source ToolAdapter and provides it together with the transformation to the transformation engine. The target model, which is produced by the transformation engine, is sent to the target ToolAdapter. In the following, we take a closer look at the automated generation of an appropriate prototype transformation. A transformation is appropriate if its source and target metamodel is identical to the metamodels of source and target ToolAdapters of the DataChannel and if it is semantics preserving. The TIL model contains some information for synthesizing the transformation, such as its execution direction and both its source and target metamodels. This information is not sufficient for an algorithmic approach for generating model transformations, but a heuristic approach for prototyping model transformations can be realized. In the following sections we explain each step of the generator for prototype transformations in more detail. A. Step 3.1 - Finding Correspondences We assume a certain level of similarity between the source and target metamodels; so we can find correspondences between them based on structural and naming similarities. To find correspondences, we use a matching algorithm that is based on the similarity flooding algorithm [20] and the Levensthein distance [16]. The similarity flooding algorithm is used to detect structural similarities, the Levensthein distance is used to identify naming similarities. The matching
algorithm produces a matching table, consisting of a number of correspondences between metaclasses, metaattributes and metareferences of source and target metamodels. In more formal terms, the matching algorithm σ(ms , mt ) = µ produces a matching table µ for a given tuple of source metamodel ms and target metamodel mt . B. Step 3.2 - Refining the Matching Table into a Matching Model To ensure that a valid target model can be produced by the synthesized transformation, we automatically refine the matching table µ into a matching model ν by adding information about the containment hierarchy of the target metamodel with the refinement function ρ, which is defined as ρ(µ, mt ) = ν. This refinement is necessary, so the synthesized transformation can produce target models with an adequate containment structure, which is specified in the target metamodel mt . The containment hierarchy of a metamodel is a partial order over all metaclasses in the metamodel that have a direct parent-child relationship. The metamodel of the matching model is depicted in Figure 5. It consists of a number of ordered matchings. A matching describes a correspondence and consists of a description of the source and target elements, a number of related matchings and a type. The type of the matching is based on the role that the target element of the matching takes in the target metamodel. We differentiate five types of matchings: •
•
•
•
•
Top: A top matching has a target element that is the root element of the containment hierarchy of the target metamodel, i.e., the element that is not contained anywhere else. A top matching specifies the names of classes and usually has a number of containment matchings. Containment: A containment matching represents a reference between two metaclasses in the target metamodel, where one class is the parent and the contained class is the child. A containment matching specifies the names of the reference and metaclasses. Reference: A reference matching represents a link between two arbitrary metaclasses in the target metamodel. A reference matching specifies the names of the reference and metaclasses. Class: In a class matching, the target element is a metaclass. A class matching specifies the names of the metaclasses and usually has a number of related matchings, which are of type containment, reference or attribute. Attribute: In an attribute matching, the target element is a metaattribute of a metaclass. An attribute matching specifies the names of the metaattribute and metaclass.
The automated refinement ρ adds a containment matching for a target metaclass if necessary and ensures that all target
Figure 5.
Metamodel of the matching model
metaclasses are properly contained. It also checks that no target element is produced by more than one rule. C. Step 3.3 - Synthesis of Transformation Rules from the Matching Model The model transformation τ1 is automatically synthesized based on the matching model ν, which is produced in the previous step and is executed at runtime of the tool chain for the exchange of tool data. The synthesis of τ1 is performed by a second model transformation τ2 , which is a higherorder model transformation, defined as τ2 (ν) = τ1 . The transformation τ2 produces τ1 and is executed at design time of the tool chain. The transformation τ1 (ns ) = nt is executed at run-time of the tool chain and maps the model ns to the model nt , where ns corresponds to the source metamodel ms , and nt corresponds to the target metamodel mt . The synthesized model transformation τ1 is a modelto-model transformation, implemented with OMG QVT-R [23]. The synthesizing model transformation τ2 is a modelto-text transformation, implemented with the OMG MTL transformation language [22] implemented in Acceleo. For each matching in the matching model ν, the transformation τ2 produces one or several QVT relations. For each type of matching a different template for the relations is used. The template is instantiated with the values from the current matching. All customized QVT relations for all matchings together form the synthesized transformation τ1 . See listing 1 for an example excerpt. D. Running Example: Step 3 For the DataChannels simulink2uml and simulink2hiphops, this transformation is synthesized by the generator. The metamodels for UML, Simulink and HiP-HOPS show a certain degree of structural and naming similarity, as they represent a hierarchical composition of components and the components are linked by connectors via ports. As a first step in the automated synthesis of the transformation, a matching table is created. The automated metamodel matching algorithm is applied on the UML and the Simulink metamodels, yielding the matching table I. Applying the algorithm on the UML and the HiP-HOPS metamodels yields matching table II. The higher-order model transformation τ2 of step 3.3 converts the matching model into a QVT-R transformation.
Table I M ATCHING TABLE FOR UML AND S IMULINK
UML Metaclass Port EString Class Property Connector Class.properties Property.type Class.ports Connector.source Connector.target
Simulink Metaclass InOutPort EString Block Attribute Line Block.attributes Attribute.type Block.ports Line.line source Line.line target
Table II M ATCHING TABLE FOR UML AND H I P-HOPS
UML Metaclass Port Connector EString Class UMLModel Property.type UMLModel.connectors Connector.target Connector.source
HiP-HOPS Metaclass Port Line EString Component System Port.name System.lines Line.target Line.source
A part of this synthesized transformation for the mapping between UML and Simulink is depicted in Listing 1. It shows the transformation code for different types of matchings, namely top, containment and class matchings. As the root element, the UML model is mapped to a Simulink model, contained UML Classes to Simulink Blocks, and the attributes of Classes to attributes of Blocks. In a similar manner – but not shown here due to space constraints – the value of each attribute is mapped, as well as Connectors and their attributes. The computed mapping is correct, but not complete, as not all elements are mapped. The missing mappings describe attributes, e.g., mapping the name attribute of the UML Class to the name attribute of Component or Block. Such missing attribute mappings concern only values and are relatively easy to add, since no other mappings depend on them. We evaluate the generated transformations with precision/recall metrics in Section VIII-B.
Listing 1. 0
Synthesized QVT-R transformation from UML to Simulink
t r a n s f o r m a t i o n u m l 2 2 s i m u l i n k 2 ( s o u r c e : uml2 , t a r g e t : s i m u l i n k 2 ) { −−Top M a t c h i n g t o p r e l a t i o n r Model { c h e c k o n l y domain s o u r c e p : uml2 : : Model { }; e n f o r c e domain t a r g e t s : s i m u l i n k 2 : : S i m u l i n k M o d e l { }; where{ r Model classes (p , s ) ; r Model connectors (p , s ) ; } }
5
10
−−C o n t a i n m e n t M a t c h i n g r e l a t i o n r Model classes { c h e c k o n l y domain s o u r c e p : uml2 : : Model { c l a s s e s = co : uml2 : : C l a s s{ } }; e n f o r c e domain t a r g e t s : s i m u l i n k 2 : : S i m u l i n k M o d e l { e l e m e n t s = s b : s i m u l i n k 2 : : B l o c k{ } }; where{ r C l a s s ( co , s b ) ; } }
15
20
25
30
35
40
[..]
−−C l a s s M a t c h i n g relation r Class { c h e c k o n l y domain s o u r c e co : uml2 : : C l a s s{ }; e n f o r c e domain t a r g e t s b : s i m u l i n k 2 : : B l o c k{ }; where{ r C l a s s n a m e ( co , s b ) ; r C l a s s p o r t s ( co , s b ) ; r C l a s s p r o p e r t i e s ( co , s b ) ; } }
}
VI. S TEP 4 - I NTEGRATION OF G ENERATOR R ESULTS The generators in steps 2 and 3 produce ToolAdapters and DataChannels using different generative techniques. The generator for ToolAdapters uses code generation; the generator for DataChannels applies a matching algorithm to produce model transformations, which realize the conversion of tool data. Both generators use the ToolAdapter metamodels that are linked to the TIL model, but they use the metamodels in a different way. The generator for ToolAdapters uses the tool metamodel as specification of the data managed by the ToolAdapter. The tool data is accessible as a model through the generated ToolAdapter and conforms to the tool metamodel. The generator for transformations uses the metamodels of both ToolAdapters it connects to. Data-flow connections between ToolAdapters need to translate the tool data. The rules for the translation can be determined at designtime, since it is independent of the actual data, and only depends on the tool metamodels. As we have generated the ToolAdapters we know that they provide tool data that conforms to the tool metamodels. The ToolAdapter metamodels are used as an interface between the different generators to ensure compatibility between the generated artifacts. VII. S TEP 5 - F ROM P ROTOTYPE TO P RODUCTION S OFTWARE The proposed approach promotes the iterative development of tool chains, where steps 1 - 4 can be repeated frequently to explore different what-if scenarios. This is
supported by the generative approach, which produces executable source code and transformations automatically with only a small effort from the tool chain designer. The completely automatically generated source code works on test data and the automatically generated transformation might not be complete. While this level of accuracy might be sufficient for prototyping different what-if scenarios for tool chains, it needs to be improved for production software. To create production software, the generated source code and transformation rules need to be manually adapted. The generated source code of the ToolAdapter needs to be extended to interact with the API of the integrated development tool, to extract and inject the data from the tool and to forward service calls to it. The generated model transformation needs to be refined, mainly by adding new transformation rules and less frequently by changing the generated transformation rules. VIII. E VALUATION In this section, we intend to quantify to what extent the tool chain used as a running example, can be generated with the proposed approach. We separately evaluate the generator for tool adapters and for transformations. A. Generator for ToolAdapters The generator for ToolAdapters produces code skeletons and a complete prototype implementation, which serves test data. This prototype implementation needs to be manually replaced with code that serves the actual tool data using the API of the tool. The size of the code that needs to be manually added depends on the tool. To show the effectiveness of the generator, it is not sufficient to compare the LOC of generated code with the manually added code. Instead, we create a baseline implementation completely manually. We now have two code bases realizing the same functionality. To quantify the generated and manually added code, we measure lines of code. This measurement has been criticized as a general measurement of software size for complete software, but here we apply it to fragments of code. We measure the lines of generated vs. manually implemented code for all ToolAdapters in the case study and present the measurements in Table III. Table III
LOC OF THE T OOL A DAPTERS : GENERATED AND MANUALLY IMPLEMENTED CODE WITH THE TIL APPROACH VS . COMPLETELY MANUALLY IMPLEMENTED BASELINE
ToolAdapter UML Simulink Safety Sum Percentage
TIL generated 1409 2030 3833 7272
TIL manually added 59 1118 317 1494 22%
manual baseline 1313 3077 2359 6749 100%
The size of the generated code is not a significant indicator for the quality of the generated code. This is why we study the comparison of the manually added LOC (in step 5) with the LOC of the manual baseline. Both codes are manually created, realize the same functionality and their sizes can thus indirectly give clues about the quality of the generated code. On average, only 22% of the source code from the manual baseline needed to be implemented manually with the TIL approach. B. Generator for Transformations The generator for transformations introduced in Section V is a heuristics. It is the nature of heuristics to approximate the optimal solution and it cannot be guaranteed that the calculated result is the optimal solution. It is thus important to measure the quality of the results. In the following, we measure the quality of the results of applying our matching algorithm on a number of tool metamodels. The matching
presented in Figure 4. The resulting precision/recall measurements are displayed in Table V. On average, the synthesis method returns mappings that have a high precision (93%), but only an average recall (56%). Table V P RECISION /R ECALL M ETRIC FOR THE COMPUTED MAPPING OF UML, S IMULINK AND H I P-HOPS
Source UML UML Simulink Simulink HiP-HOPS HiP-HOPS Average
Target Simulink HiP-HOPS UML HiP-HOPS UML Simulink
Precision 1 0.89 1 0.9 0.89 0.9 0.93
Recall 0.56 0.53 0.67 0.6 0.53 0.5 0.56
(2)
In situation 2, no mapping should be found since there is no semantic equivalent, but the algorithm finds a mapping due to structural similarity; this would result in a low precision. The measurements in Table V show a high precision metric. This means that the generated mappings are correct and only need to be changed seldomly. The mappings that need to be changed have a stable skeleton for manually added mappings. In situation 3, there are semantically equivalent metamodels, for which no structural or naming similarity can be detected. If it is not possible to deduce clues about the semantic equivalence from the structural features of the metamodels, the automated algorithm does not have sufficient data to make mapping decisions. In this situation, either additional user data would need to be provided as input, e.g., via annotations, or the missing mappings need to be manually added after the algorithm is finished. Situation 3 is captured by the recall metric. The average recall metric in Table V is largely due to missing attribute mappings. Such attribute mappings concern only one value and are relatively easy to add manually, since no other mappings depend on them. An example for the transformation between UML and Simulink is the mapping (Class.name,Block.name). Due to its high precision (93%) and average recall (56%) characteristic, the matching algorithm can be classified as a conservative method. The algorithm rather does not include a mapping into the result than produce a wrong mapping. The mappings that are included in the result are almost all correct, maximally one of the mappings is incorrect. The mappings that are not found automatically by the matching algorithm can be manually added to the result.
where correctmatches is defined as the correct, semanticspreserving mapping, and f oundmatches is the mapping that was identified by the matching algorithm. We use the precision/recall measurement to present the number of false positives and false negatives in the mappings. We measure the quality of the calculated mappings of all six possible combinations between the three metamodels
IX. R ELATED W ORK The contribution of this paper is in the intersection of several fields, namely model-based tool integration, metamodel matching and rapid prototyping. Related work can be found in each of these fields. We list the approaches by fields and point out approaches that are in the intersection of two or more fields.
Table IV R ELATIONSHIP BETWEEN SEMANTICS PRESERVATION AND STRUCTURAL / NAMING SIMILARITY
structural/naming yes similarity no
semantics preservation yes no 1 2 3 4
algorithm is based on two simplifying assumptions: (i) The transformation, which is part of the DataChannel between two ToolAdapters is intended to be semantics preserving. (ii) A semantics preserving transformation maps elements, which are similar regarding structure or naming. Assumption (i) is part of the semantics of the DataChannel in TIL (see Section III). In the following, we will evaluate assumption (ii). We analyze the relationship between semantics preservation and structural/naming similarity in Table IV and distinguish four situations. Since assumption (ii) correlates semantics preservation with structural/naming similarity, the algorithm only distinguishes between situations 1 and 4 in Table IV. Situations 2 and 3 are in the “blind spot” of the algorithm, as semantics preservation may not be correlated with structural/naming similarity. The impact of situation 2 is measured by the precision metric, the impact of situation 3 is measured by the recall metric, which are defined as follows. |{correctmatches} ∩ {f oundmatches}| |{f oundmatches}| |{correctmatches} ∩ {f oundmatches}| Recall = |{correctmatches}|
P recision =
(1)
A. Tool Integration Early work on tool integration focuses on identifying the scope of tool integration in form of aspects [29] and patterns [14]. A number of integration frameworks have been defined to support building tool chains, such as the one from Vanderbilt [13] and jETI [19]. Model-based integration frameworks focus on data integration, the other integration aspects (such as control, process, platform and presentation) defined by Wasserman [29] are excluded or a secondary issue. Examples are MOFLON [1] or ModelCVS [12]. These related approaches use metamodeling for describing the tool data. However, these approaches provide neither concepts to model a complete tool chain nor concepts to describe the architecture of the tool chain. The related approaches assume that tool data is available in the form of models and that the tool adapters are implemented manually. Only the MOFLON approach mentions code generation for tool adapters. The related approaches also use model transformations to translate between the metamodels of different tools, but the transformation usually has to be specified manually. Tool integration platforms, such as ModelBus [11] or Jazz [9], mainly provide support for executing the tool chain, or generic building blocks, so constructing tailored, userdefined tool chains requires a lot of work. We automate the construction of such tailored tool chains. B. Metamodel Matching Matching metadata on data structures has been studied in the field of databases as schema matching [20], [26], [27]. These matching algorithms have been adopted in the modeling community, where metamodels are matched instead of schema definitions. Algorithms based on similarity flooding and naming similarity are described [6], [8]. Different metamodel matching algorithms are compared in [15] and formalized into a DSL for metamodel matching [10]. Model weaving approaches [6] can leverage metamodel matching to create weaving models that express the correspondence. Del Fabro shows how metamodel matching can be applied for data migration between two bugtracking tools [6]. The approach assumes that the tool data is already available in a model format and focuses on the use of metamodel matching for weaving models. We use metamodel matching in an integration scenario and focus on a comprehensive approach for the creation of a complete tool chain. C. Prototyping Prototyping approaches focus on the early synthesis of an executable system from a high-level specification. Bernstein stresses the importance of prototyping [3] and lists advantages of the approach, among them he sees prototyping as a vehicle to better understanding the environment and the requirements, to validate requirements with the user and to study the dynamics of a system. We distinguish between throwaway and evolutionary prototyping [17]. In throwaway
prototyping, the prototype is built to learn a specific thing and is discarded before a completely new prototype is built. In evolutionary prototyping, one prototype is refined over several iterations. The technology proposed in this paper can be used for either prototyping approach. Many prototyping systems employ a prototyping language in combination with code generation techniques. These approaches are usually specialized to certain domains, such as CAPS and DCAPS [18] for embedded systems, information systems and user interfaces [30], component based systems [28] or data mining systems [21]. X. F UTURE W ORK AND C ONCLUSION The creation of tool chains is usually regarded as a completely manual implementation task. The presented approach shows that the tool chain implementation for a prototype can be automatically created with generative techniques. Different generative techniques need to be combined to produce the heterogeneous parts of the tool chain: code generation for ToolAdapters and a heuristic matching algorithm for transformations. The generated code for the ToolAdapters ensures compliance with standards and serves test data for prototyping. This code is also the basis for production software as it provides a skeleton that needs to be refined with manually written code that interacts with the API of the integrated tool. In our case study the generated code for ToolAdapters makes up 78% of the total production software. The generated transformation code for the DataChannels provides a precise mapping for the data elements (93% precision), but does not cover all data elements (56% recall). Due to the conservative characteristic of the approach (high precision, average recall), the generated mapping can be be extended into a comprehensive mapping. The generated artifacts can serve as a starting point for manual extensions and refinements of the generated tool chain implementation. The proposed approach for automated synthesis of both source code and transformations makes it possible to systematically and rapidly create an executable prototype of a tool chain. This allows the user to test and iteratively modify the tool chain prototype, before investing time to extend the prototype into the final production software. An important next step is a further assessment of the practical applicability of this approach. We will apply our approach in additional case studies, which cover a broader set of development tools. This will allow us to further narrow down the conditions, in which the approach can achieve the best mapping, measured with the precision/recall metric. In addition, we will examine if the algorithm can also be applied to support the evolution of a tool chain, when tool A in the tool chain is exchanged against a similar tool B. Acknowledgement The research leading to these results has received funding from the ARTEMIS JU under grant 100203.
R EFERENCES [1] C. Amelunxen, F. Klar, A. K¨onigs, T. R¨otschke, and A. Sch¨urr. Metamodel-based tool integration with MOFLON. In ICSE ’08, pp. 807–810, 2008. [2] E. Armengaud, M. Biehl, Q. Bourrouilh, M. Breunig, S. Farfeleder, C. Hein, M. Oertel, A. Wallner, and M. Zoier. Integrated tool chain for improving traceability during the development of automotive systems. In ERTS2 2012 — Embedded Real Time Software and Systems, pp. 30–46, 2012. [3] L. Bernstein. Importance of software prototyping. Journal of Systems Integration, 6(1), pp. 9–14, 1996. [4] M. Biehl, J. El-Khoury, F. Loiret, and M. T¨orngren, “On the Modeling and Generation of Service-Oriented Tool Chains,” Journal of Software and Systems Modeling, vol. 0275, 2012. [5] M. Biehl, J. El-Khoury, and M. T¨orngren. High-Level Specification and Code Generation for Service-Oriented Tool Adapters. In Proceedings of the International Conference on Computational Science (ICCSA2012), pp. 35– 42, Jun. 2012 [Online]. Available: http://dx.doi.org/10.1007/ s10270-012-0275-7
[15] L. Lafi, S. Issam, S. Hammoudi, and J. Feki. Comparison of two metamodel matching techniques. In 4th Workshop on Model-Driven Tool & Process Integration (MDTPI2011), pp. 54–65, 2011. [16] V. Levenshtein. Binary Codes Capable of Correcting Deletions, Insertions and Reversals. Doklady Akademii Nauk SSSR, 163(4), pp. 845–848, 1965. [17] V. Luqi, V. Berzins, M. Shing, R. Riehle, and J. Nogueira. Evolutionary Computer Aided Prototyping System (CAPS). In Technology of Object-Oriented Languages and Systems, pp. 363, 2000. [18] V. Luqi, J. Berzins, J. Ge, M. Shing, M. Auguston, B. Bryant, and B. Kin. DCAPS-architecture for distributed computer aided prototyping system. In Rapid System Prototyping, 12th International Workshop on, pp. 103–108, 2001. [19] T. Margaria, R. Nagel, and B. Steffen. jETI: A Tool for Remote Tool Integration Tools and Algorithms for the Construction and Analysis of Systems. In TACAS, LNCS, vol. 3440, pp. 557–562, 2005. [20] S. Melnik, H. Garcia-molina, and E. Rahm. Similarity flooding: A versatile graph matching algorithm, 2002.
[6] M. Del Fabro, J. B´ezivin, and P. Valduriez. Model-Driven Tool Interoperability: An Application in Bug Tracking. InOn the Move to Meaningful Internet Systems 2006, LNCS, vol. 4275, pp. 863–881, 2006.
[21] I. Mierswa, M. Scholz, R. Klinkenberg, M. Wurst, and T. Euler. YALE: Rapid Prototyping for Complex Data Mining Tasks. In In Proceedings of the 12th ACM SIGKDD, pp. 935–940, 2006.
[7] J. El-khoury, O. Redell, and M. T¨orngren. A Tool Integration Platform for Multi-Disciplinary Development. In 31st EUROMICRO Conference on Software Engineering and Advanced Applications, pp. 442–450, 2005.
[22] OMG. MOF Model to Text Language (MTL). Technical report, OMG, 2008.
[8] J.-R. Falleri, M. Huchard, M. Lafourcade, and C. Nebut. Metamodel Matching for Automatic Model Transformation Generation. In Model Driven Engineering Languages and Systems, LNCS, vol. 5301, pp. 326–340, 2008.
[24] OSLC Core Specification Workgroup. OSLC core specification version 2.0. Technical report, Open Services for Lifecycle Collaboration, 2010.
[9] R. Frost. Jazz and the Eclipse way of collaboration. IEEE Software, vol. 24, no. 6, pp. 114–117, 2007. [10] K. Garc´es, F. Jouault, Pi. Cointe, and J. 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), pp. 30–45, 2009. [11] C. Hein, T. Ritter, and M. Wagner. Model-Driven Tool Integration with ModelBus. In Workshop Future Trends of Model-Driven Development, pp. 1–12, 2009. [12] 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, pp. 11–27, 2006.
[23] OMG. MOF 2.0 Query / View / Transformation. Technical report, OMG, 2009.
[25] Y. Papadopoulos and J. McDermid. Hierarchically Performed Hazard Origin and Propagation Studies. In SAFECOMP, LNCS, vol. 1698, pages 139–152, 1999. [26] E. Rahm and P. Bernstein. A survey of approaches to automatic schema matching. The VLDB Journal, vol. 10, no. 4, pp. 334–350, 2001. [27] P. Shvaiko, J. Euzenat. A Survey of Schema-Based Matching Approaches Journal on Data Semantics IV. In Journal on Data Semantics IV, LNCS vol. 3730, pp. 146–171, 2005. [28] M. Tkachuk, A. Zemlyanoy, and R. Gamzayev. Towards Prototyping-Based Technology for Adaptive Software Development Information Systems and e-Business Technologies. In LNBIP, vol. 5 , pp. 508–518, 2008.
[13] G. Karsai and J. Gray. Component generation technology for semantic tool integration. vol. 4, pp. 491–499, 2000.
[29] Anthony I. Wasserman. Tool Integration in Software Engineering Environments. In Software Engineering Environments, International Workshop on Environments Proceedings, LNCS, pp. 137–149, 1989.
[14] G. Karsai, A. Lang, and S. Neema. Design patterns for open tool integration. Software and Systems Modeling, vol. 4, no. 2, pp. 157–170, 2005.
[30] W. Zhou. A Rapid Prototyping System for Distributed Information System Applications. Journal of Systems and Software, vol. 24, no. 1, pp. 3–29, 1994.
Appendix H
Early Automated Verification of Tool Chain Design Matthias Biehl in Proceedings of the International Conference on Computational Science and Its Applications (ICCSA2012) June 2012 c
2012 Springer. Reprinted with permission.
Early Automated Verification of Tool Chain Design Matthias Biehl Embedded Control Systems Royal Institute of Technology Stockholm, Sweden
[email protected]
Abstract. Tool chains are expected to increase the productivity of product development by providing automation and integration. If, however, the tool chain does not have the features required to support the product development process, it falls short of this expectation. Tool chains could reach their full potential if it could be ensured that the features of a tool chain are aligned with the product development process. As part of a systematic development approach for tool chains, we propose a verification method that measures the extent to which a tool chain design conforms to the product development process and identifies misalignments. The verification method can be used early in tool chain development, when it is relatively easy and cheap to perform the necessary corrections. Our verification method is automated, which allows for quick feedback and enables iterative design. We apply the proposed method on an industrial tool chain, where it is able to identify improvements to the design of the tool chain. Key words: Tool Integration; Process Modeling; Verification; Modeldriven Development
1
Introduction
Tool chains are becoming increasingly important in the development of complex systems, since tool chains have the potential to increase development productivity. In order to reach the goal of higher productivity, tool chains need to support the product development process. The development process of each product is different, specific to the company, its traditions, the preferences of the engineers and the set of development tools used. To provide support in development, a tool chain cannot be one-size-fits-all solution, but it needs to be customized to the development context it is used in [7]. It is especially important that the tool chain is customized and aligned with the product development process, otherwise practitioners do not accept a new tool chain in their work [5]. It is thus important to verify that a tool chain is suitable and fits in a specific development context. We verify by checking the degree to which a tool chain is aligned with a given product development process.
This work is part of a vision to support the development of a tool chain using a systematic methodology and tools that manage the complexity of tool chain development [3]. As part of the systematic development methodology, the design of a customized tool chain needs to be analyzed and verified early in the tool chain development process1 . When verifying the design of a tool chain, we are interested in checking how well the design realizes the requirements. A verification of the design is a complement - not a replacement - to a verification of the implementation. Early verification of tool chain design can detect possible misalignments between the product development process and the tool chain, when corrections are still relatively simple and cheap. In addition, when we automate the early verification of tool chain design, it can be performed repeatedly with little effort, allowing for iterative development of tool chains. This leads to the central research question addressed in this paper: How can early verification of the alignment between tool chain design and product development process be performed and automated? The remainder of this paper is structured as follows. In section 2 we describe the approach for automated verification. In section 3 we investigate modeling the product development process, the tool chain and the relation between these models. In section 4 we devise a method to identify misalignments between the development process and the design of the tool chain and we measure the degree of alignment in section 5. In section 6 we apply the verification method on an industrial tool chain and discover possible improvements. In sections 7 and 8, we relate our approach to other work in the field, list future work and consider the implications of this work.
2
Approach
Our goal is to support the development of tool chains by verifying that the tool chain design is aligned to the product development process. The verification produces a list of misalignments and a measurement indicating the degree of alignment between the tool chain and the product development process. In figure 1 we give an overview of the verification approach. As input we need a description of the tool chain design (section 3.2) and a description of the process including the set of tools and their capabilities (section 3.1). These descriptions need to be in an appropriate language for describing the tool chain and its needs. An initial verification graph is created based on the two input models. We automatically add mapping links to the verification graph, which are constructed according to mapping rules (section 3.3). We then apply alignment rules (section 4) on the verification graph to find out in how far the tool chain supports the development process. We also apply metrics (section 5) to determine the degree of alignment between the tool chain and the process. The metrics and 1
Note: In this paper we deal with two different development processes: the development process of the tool chain, called tool chain development process, and the development process of some product, where the development process will be supported by the tool chain (see figure 4), called product development process.
the list of misalignments provide feedback for an iterative design and guide the tool chain designer towards building an improved, more useful tool chain that is aligned with the process.
Fig. 1. Approach for early automated verification of tool chains
3
Building up the Verification Graph
In this section, we describe how we build up the data structure used for verification. The data structure combines the description of the development process (section 3.1) and the tool chain design (section 3.2) by adding mapping links between both descriptions (section 3.3). 3.1
Description of the Product Development Process
We apply the Software & Systems Process Engineering Metamodel (SPEM) [10] to describe both the product development process and the set of tools used. A SPEM model can thus be used to describe the process requirements of a tool chain. A number of concepts are defined in SPEM, we focus here on the core concepts relevant in this context. A Process is composed of several Activities. An
Activity is described by a set of linked Tasks, WorkProducts and Roles. A Role can perform a Task and a WorkProduct can be marked as the input or output of a Task. A WorkProduct can be managed by a Tool and a Task can use a Tool. An example model is provided in figure 4. SPEM can be used at several levels of abstraction: A high-level description may consist only of a process and activities and a low level description may break down each task into steps and detailed guidance. In the following we assume a process description on an appropriate level of abstraction that contains at least instances of all of the above metaclasses. 3.2
Description of the Design of the Tool Chain
We would like to create an early design model that describes all important design decisions of a tool chain. We chose to apply the Tool Integration Language (TIL) [3], a domain specific modeling language for tool chains. TIL allows us not only to model a tool chain, but also to analyze it and generate code from it. Here we can only give a short overview: In TIL we describe the tool chain in terms of a number of ToolAdapters and the relation between then. A ToolAdapter exposes data and functionality of a tool. The relation between the ToolAdapters is realized as any of the following Channels: a ControlChannel describes a service call, a DataChannel describes data exchange and a TraceChannel describes the creation of trace links. An example for using the graphical language of TIL is provided in figure 5. 3.3
Mapping Rules and the Verification Graph
For the purpose of analysis we create an initial verification graph, which contains all the elements and internal links from both the SPEM model and the TIL model. We assume that the descriptions of the process and of the tool chain are internally verified and consistent, i.e., that all used variables have been defined. This graph is the basis for the construction of mapping links that connect model elements from the SPEM and TIL model. The mappings are constructed according to the mapping rules defined in table 1. Table 1. Mapping rules for SPEM and TIL metaclasses SPEM Metaclass TIL Metaclass Role User Tool ToolAdapter Task Channel
The mapping rules introduce mapping links between the model elements of the given types that also have similar instance names. We measure the similarity of names by using the Levensthein distance [9]. This ensures that corresponding
elements will be mapped, even if they do not have the exact same name: e.g. a Tool in SPEM with name ’UML Tool’ will be mapped to a ToolAdapter in TIL with name ’Papyrus UML TOOL’. We add the mapping links to the initial verification graph, which results in a complete verification graph exemplified in figure 2.
Fig. 2. Example of a complete verification graph
4
Verification by Alignment Checking
In order to verify a given tool chain design, we check for alignment of the requirements provided by a SPEM model with the design provided by a TIL model. We base the alignment check on the verification graph described in the previous section and a number of alignment rules. 4.1
Alignment Rules
The basic assumption of our alignment rules is that each SPEM Task that has two different SPEM Tools associated with it, is a candidate task for support by the tool chain; we call it integration-related task. Arbitrary SPEM Tasks connected to only one tool, are of no interest for tool integration; for these tasks, users will work directly with the GUI of a single tool. We distinguish two alignment rules in figure 3: (A) for Tasks and (B) for WorkProducts. Apart from rules (A) and (B), additional rules may be added if additional correspondences between TIL and SPEM are identified. (A) For each SPEM Task with two SPEM Tool associated with it, this rule expects corresponding TIL ToolAdapters and a TIL Channel between them. A pair of TIL ToolAdapter and SPEM Tool are corresponding if they have mapping links between them (see section 3.3). This rule requires two such pairs, one pair with name X and one pair with name Y, where X 6= Y. Optionally, for each
SPEM Role that is connected to the SPEM Task, we expect a corresponding TIL User that is connected via a TIL ControlChannel with the TIL Channel. (B) For each SPEM Task that has associated SPEM WorkProducts as input and output, where the input SPEM WorkProduct has a different associated SPEM Tool than the output SPEM WorkProduct, the rule expects to find TIL ToolAdapters corresponding to the SPEM Tool and a TIL Channel between them.
Fig. 3. Alignment rules and examples: (A) for tasks and (B) for workproducts, using the notation of figure 2
The rules contain optional parts, visualized by dashed elements. For both rules A and B we need to check the (1) realized and (2) necessary alignments, thus the alignment rules can be interpreted in two directions: – (1) If the lower part of the rule can be found in the SPEM model, the upper part needs to be found in the TIL model as well. Each integration-related task in the process model should also be represented in the tool chain, we call it a realized alignment, because the requirements provided by the process model are realized by the tool chain. This direction of rule interpretation checks if the requirements given by the product development process are actually realized by the tool chain. – (2) If the upper part of the rule can be found in the TIL model, the lower part needs to be found in the SPEM model. Each Channel in the tool chain
design should have a corresponding requirement in the process model, we call it a necessary alignment, because this part of the tool chain is necessary for fulfilling the requirements of the process This direction of rule interpretation checks if the tool chain contains superfluous features that are not used by the process. 4.2
Alignment Checking
We perform pattern matching of the alignment rules on the verification graph. As a result of the pattern matching we get a list of alignments and a list of misalignments. An alignment is a match of an alignment rule, a misalignment is a mismatches of the alignment rules, where only the upper part (TIL part) or lower part (SPEM part) of the rule can be found in the verification graph. Assuming that the product development process is described correctly, we can add a recommendation for resolving the misalignment by adapting the tool chain design in TIL. If a Channel is missing, we can suggest to add it to the TIL model because it would improve the functionality of the tool chain. If the Task is missing in the SPEM model, we can suggest to remove the Channel from the TIL model, because it is not required.
5
Quantification by Alignment Metrics
Tool chains provide increased automation of integration-related tasks. Moreover, the automation needs to be appropriate to the needs of the tool chain. Appropriate automation depends on the alignment of tool chain and product development process, the set of product development tools and their capabilities. We measure usefulness based on two degrees of alignment. The degree of alignment can be determined based on the results of the alignment checks explained in the previous section. We make the following definitions: – #matchesSP EM are the number of matches of the SPEM part (lower part) of rules A and B. – #matchesT IL are the number of matches of the TIL part (upper part) of rules A and B. – #matches are the number of matches of the combined SPEM and TIL part of rules A and B. The recall alignment in formula 1 measures the ratio of integration related tasks in the process model that are realized by a channel in the tool chain. The precision alignment in formula 2 measures the ratio of channels in the tool chain that are required by a corresponding integration-related task in the process model. alignmentrecall = alignmentprecision =
#matches #matchesSP EM #matches #matchesT IL
(1) (2)
A well-aligned tool chain has both a high degree of precision alignment and a high degree of recall alignment, typically expressed by F-measure. A high degree of precision alignment shows that the tool chain has little or no superfluous features. A high degree of recall alignment shows that the tool chain has all or almost all the features needed. A low degree of precision alignment can be fixed by reducing unused features from the tool chain. These features will not be used according to the process description and only increase the development cost of the tool chain. A low degree of recall alignment might be even more critical. It needs to be fixed by introducing new features into the tool chain design, so the integration-related tasks are supported by the tool chain.
6
Case Study
This case-study shows the development process of an embedded system that is characterized by tightly coupled hardware and software components: – The requirements of the system are captured in a requirements management tool. The system architect designs a UML component diagram and creates trace links between UML components and the requirements. – The UML model is refined and a fault tree analysis is performed in the safety analysis tool. When the results are satisfactory, the control engineer creates a Simulink model for simulation and partitions the functionality for realization in software and hardware. – The application engineer uses Simulink to generate C code, which is refined in the WindRiver tool. The data from UML and Simulink is input to the IEC-61131-3 conform ControlBuilder tool. The data from ControlBuilder, Simulink and WindRiver is integrated in the Freescale development tool for compiling and linking to a binary for the target hardware. – A hardware engineer generates VHDL code from Simulink and refines it in the Xilinx ISE tool. A SPEM model of this development process for hardware-software co-design used by the company is modeled as shown in figure 4. The tool chain designer creates the initial tool chain design shown in figure 5. Both models are input to our algorithm, which identifies the misalignments shown in table 2. As it turns out, the tool chain designer built the tool chain according to the verbatim description of the process given above. This description, however, does not cover the intricate details of the relationships between tools that are present in the SPEM model. The tool chain design only contains forward links between tools, as they would be used in a waterfall process model, but neglects the cross links and dependencies typical for modern engineering processes. In this case study we have a cross link between Simulink and ControlBuilder and one between WindRiver and ControlBuilder. In addition, the process model specifies a pair of links between ControlBuilder and FreeScale and another pair between Simulink and FreeScale, but the tool chain design only realizes one link out of each pair.
Fig. 4. Product development process of the case study as a SPEM model
Fig. 5. Tool chain of the case study as a TIL model
For the case study the degree of recall is 69%, the degree of precision is 100%. This tells us that the tool chain has no superfluous features, but does not realize all necessary ones. The tool chain could be improved by adding the four missing Channels to the TIL model, as listed in table 2 Table 2. The misalignments and suggested improvements for the tool chain design TaskDefinition Transfer HWD Transfer CIT2 Transfer 1131 Transfer CIT
7
Input ToolDefinition Simulink WindRiver WorkBench ControlBuilder Tool Simulink Tool
Output ToolDefinition ControlBuilder Tool ControlBuilder Tool FreeScale FreeScale
Suggested Improvement Add TIL Channel Add TIL Channel Add TIL Channel Add TIL Channel
Related Work
There are a number of approaches for tool integration, as documented in the annotated bibliographies [4, 12], however, most tool integration approaches do not explicitly take the development process into account. In this section we focus on the few approaches that acknowledge a relationship between process and tool chain. We classify this related work on tool integration according to two dimensions: Executing the process using (1a) interpretation vs. (1b) compilation and applying a process modeling formalisms that is (2a) proprietary vs. (2b) standardized. (1a) Interpretation-based approaches use the process definition directly to integrate tools; this techniques is also known as enactment of process models. Since the description of the process is the same as that of the tool chain, the two have the advantage to always be aligned. There are two preconditions for the interpretation approach: the process model needs to be executable and the access to data and functionality of the development tools needs to be possible. (2a) The use of a proprietary process model in tool chains is introduced in [6] as the process-flow pattern. In this approach a workflow realizes control integration and is executed by interpretation. (2b) A well known standardized process model is SPEM. SPEM itself [10] is not executable but there are extensions to SPEM that make the process model executable [8, 2]. The orchestration of tools by a process model is shown in [11]. However, the interpretation of integration related tasks is often not possible, since the interfaces to the development tools are too different. Thus the use of process enactment for building tool chains is limited. (1b) Compilation based approaches transform the process model into another format, where the process model serves as a set of requirements. (2a) Proprietary process models provide great flexibility to adapt them to the specific needs of tool integration. An integration process model is developed in [1], where each process step can be linked to a dedicated activity in a tool. For execution it is compiled into a low-level process model. The proprietary process model needs
to be created specifically for constructing a tool chain. (2b) In this work we assume a compilation-based approach, where a process model is compiled or manually transformed into a tool chain design. We use the standardized process metamodel SPEM [10], which allows us to reuse existing process models as a starting point for creating a tool chain design. The described approach verifies that a tool chain design fulfills the requirements described in SPEM.
8
Future Work and Conclusion
In this work we propose a verification method for early design that checks the alignment of a tool chain with a product development process. We formalize this relationship, which allows us to reason about the relationship in an automated way and verify the tool chain against the needs of the product development process using consistency checks and metrics. There are various ways in which tool integration can be modeled in SPEM. In this work we have identified two patterns, in future work, we would like to identify additional patterns for modeling tool integration in SPEM. The verification rules presented in section 4 may not only be used analytically for verification, but also constructively for automatically building a design model for a tool chain from a given process description. In the future we would like to explore this idea and integrate it into a comprehensive methodology for developing tool chains. We would also like to apply this approach on several bigger case studies. The case study should contain a thorough investigation of the false positives and false negatives found with the approach. The approach contributes to the vision of a systematic development methodology for tool chains with a potential for cost savings and an increased time to market. An important prerequisite for reaching this potential is a clear description of the product development process that the tool chain is intended to support. The approach guides the tool chain designer by analyzing different integration options and eventually building a tailored tool chain that is suitable and useful to the tool chain user in the context of a given product development process.
References 1. A. Balogh, G. Bergmann, G. Csert´ an, L. G¨ onczy, Horv´ ath, I. Majzik, A. Pataricza, B. Polg´ ar, I. R´ ath, D. Varr´ o, and G. Varr´ o. Workflow-driven tool integration using model transformations. In G. Engels, C. Lewerentz, W. Sch¨ afer, A. Sch¨ urr, and B. Westfechtel, editors, Graph transformations and model-driven engineering, chapter pages 224–248. 2010. 2. R. Bendraou, B. Combemale, X. Cregut, and M. P. Gervais. Definition of an Executable SPEM 2.0. In Software Engineering Conference, 2007. APSEC 2007. 14th Asia-Pacific, pages 390–397. IEEE, December 2007. 3. Matthias Biehl, Jad El-Khoury, Fr´ed´eric Loiret, and Martin T¨ orngren. A Domain Specific Language for Generating Tool Integration Solutions. In 4th Workshop on Model-Driven Tool & Process Integration (MDTPI2011), June 2011.
4. Alan W. Brown and Maria H. Penedo. An annotated bibliography on integration in software engineering environments. SIGSOFT Notes, 17(3):47–55, 1992. 5. Alan Christie and et al. Software Process Automation: Interviews, Survey, and Workshop Results. Technical report, SEI, 1997. 6. Gabor Karsai, Andras Lang, and Sandeep Neema. Design patterns for open tool integration. Software and Systems Modeling, 4(2):157–170, May 2005. 7. James D. Kiper. A framework for characterization of the degree of integration of software tools. Journal of Systems Integration, 4(1):5–32, February 1994. 8. Ali Koudri and Joel Champeau. MODAL: A SPEM Extension to Improve Codesign Process Models New Modeling Concepts for Today’s Software Processes. volume 6195 of Lecture Notes in Computer Science, chapter 22, pages 248–259. Springer Berlin / Heidelberg, Berlin, Heidelberg, 2010. 9. Vladimir I. Levenshtein. Binary Codes Capable of Correcting Deletions, Insertions and Reversals. Doklady Akademii Nauk SSSR, 163(4):845–848, 1965. 10. OMG. Software & Systems Process Engineering Metamodel Specification (SPEM). Technical report, ”OMG”, April 2008. 11. B. Polgar, I. Rath, Z. Szatmari, A. Horvath, and I. Majzik. Model-based Integration, Execution and Certification of Development Tool-chains. In Workshop on model driven tool and process integration, June 2009. 12. M. N. Wicks. Tool Integration within Software Engineering Environments: An Annotated Bibliography. Technical report, Heriot-Watt University, 2006.
Appendix I
A Cost-Efficiency Model for Tool Chains Matthias Biehl, and Martin T¨ orngren in Proceedings of the at the International Conference on Global Software Engineering Workshops (ICGSEW2012) August 2012 c
2012 ACM. Reprinted with permission. (Extended version)
A Cost-Efficiency Model for Tool Chains Matthias Biehl and Martin T¨orngren Embedded Control Systems Royal Institute of Technology Stockholm, Sweden {biehl,martin}@md.kth.se
Abstract. The seamless integration of development tools can help to improve the productivity of software development and reduce development costs. When tool chains are used in the context of global software engineering, they are deployed as globally distributed systems. Tool chains have the potential to bring productivity gains but they are also expensive to realize. The decision to introduce a tool chain is often made based only on a qualitative analysis of the situation. More precise analysis of the trade-offs would be possible if a quantitative model describing the cost-efficiency of tool chains would be available. We apply the COCOMO model for cost analysis in combination with the TIL model for tool chain design to create a quantitative estimation model for comparing the cost-efficiency of different tool chains. Key words: Cost Estimation; Tool Integration; Software Process Improvement
1
Introduction
Software engineering relies more and more on the orchestrated use of sophisticated development tools, however, the tools only cover specific parts of the development process in isolation. In global software engineering, specific phases of the development process might be handled at specific locations. To enable a smooth development process, the tools from different process phases and locations need to be integrated into a tool chain, both locally and across different locations [15]. Most commercial off-the-shelf tools are not designed for ease of integration; especially challenging is the integration of tools from different tool vendors, across different locations and across different disciplines. The latter becomes relevant in multi-disciplinary development [12], such as in embedded software development. The assumption of the scientific community is that tool chains can help to accomplish cost reductions and productivity improvements through increased automation and improved integration between development tools [22, 10, 23]. To be able to reap the benefits, tool chains need to be constructed in such a way that they support the current practices of the development team, such as the development process and the tested-and-proven set of development tools. In the
context of global engineering, software development teams need tool chains that are flexible, distributed and tailored to the development process [15]. To deal with this new requirement, modern tool chains apply the principles of serviceoriented computing [14]. As a consequence, the tool chain becomes more complex and more costly to realize. The cost of construction consumes a part of the cost savings. In this context we can put our research question more precisely: Which factors determine if a tool chain is economical? To answer this question we contribute with a detailed cost-efficiency model for tool chains that quantifies and relates the economic effects of the benefits of tool chains to the development costs of tool chains. The cost efficiency model is intended to be used as a relative measure for choosing between alternative tool chains and it can thus support well-informed design making. The cost efficiency model is not intended to provide an absolute measure of the cost. This paper is structured as follows. In section 2 we introduce related work in software cost estimation, since it provides the basis for the tool chain costefficiency model. In section 3 we outline a cost-efficiency model for tool chains. The first part of this model is an estimation of the cost savings by tool chains, described in section 4. The second part of the model is an estimation of the software development cost for tool chains, described in section 5. We perform an industrial case study and apply the cost-efficiency model in section 6. We mention intended future work in section 8 and conclude in section 9.
2
Related Work
Tool chains are mostly introduced for economical reasons, however, there is not much work on the economic implications of introducing tool chains. According to the extensive literature review and classification of over 300 papers on tool integration, there are only two papers on the economic impact of tool integration. Most of the other papers deal with the mechanisms of realizing tool integration [22, 23]. Research on the economic implications of tool chains is suggested in [22] and several economic implications of tool chains are mentioned as possible future work. The authors suggest studying the relationship between the net value of tool integration and its sophistication: The hypothesis is that there is an optimum level of tool integration sophistication, where the net value of the tool chain reaches its maximum. The relationship between the sophistication of tool integration and sustainability has been qualitatively described in [3]. The authors argue that a trade-off between the two exists, i.e. higher sophistication leads to a shorter lifespan of the tool chain. The COCOMO II model [8, 9], which we use in this paper, represents tool integration efforts and lifecycle issues one-dimensionally; they are reflected in a single parameter, the TOOL parameter. An extension to the COCOMO model [4] proposes to disaggregate this parameter into three separate ones, namely tool integration, tool maturity and tool coverage. This yields more precise cost estimates. The paper is concerned with the impact of tool integration on the cost
of product development, but neither on cost savings by tool chains, tool chain development costs nor on the cost-efficiency of tool chains. Development with COTS (commercial off-the-shelf) components is similar to building tool chains in so far as they are both compositions of pre-built software. Thus one might suspect that COTS cost estimation models are applicable for tool chains. However, COTS cost estimation models such as COCOTS [1] and others [5] focus on the use of COTS software as part of the delivered product, whereas development tools as COTS software in tool chains are parts of the development environment. This distinction is relevant for the calculation of benefits: the benefits of COTS arise from not having to develop the software, the benefits of tool chains arise from integration and automation. The resulting cost models are thus fundamentally different. COTS models include the cost of the COTS components, however, for tool chains the cost of the integrated development tools should not be included, as they are needed with or without the tool chain. Tool chains are equivalent to what is referred to as ’glue code’ in the COTS community. Some COTS models determine the cost of glue code by an algorithmic method similar to COCOMO II and are thus similar to our approach [1], others rely on ’expert judgments’ [5]. The relationship between cost and benefits is widely discussed for COTS models. However, the benefits are usually measured in their own units, rendering trade-off analysis difficult. In this paper we measure the accumulated economic effects of the benefits as cost savings and can thus directly compare them to the development costs. Development with COTS (commercial off-the-shelf) components is similar to building tool chains in so far as they are both compositions of pre-built software. Thus one might suspect that COTS cost estimation models are applicable for tool chains. However, COTS cost estimation models such as COCOTS [1] and others [5] focus on the use of COTS software as part of the delivered product, whereas development tools as COTS software in tool chains are parts of the development environment. This distinction is relevant for the calculation of benefits: the benefits of COTS arise from not having to develop the software, the benefits of tool chains arise from integration and automation. The resulting cost models are thus fundamentally different. COTS models include the cost of the COTS components, however, for tool chains the cost of the integrated development tools should not be included, as they are needed with or without the tool chain. Tool chains are equivalent to what is referred to as ’glue code’ in the COTS community. Some COTS models determine the cost of glue code by an algorithmic method similar to COCOMO II and are thus similar to our approach [1], others rely on ’expert judgments’ [5]. The relationship between cost and benefits is widely discussed for COTS models. However, the benefits are usually measured in their own units, rendering trade-off analysis difficult. In this paper we measure the accumulated economic effects of the benefits as cost savings and can thus directly compare them to the development costs. While we have found interest in the net value of tool integration and simple qualitative models, we could, to the best of our knowledge, neither find any work
explaining the cost-efficiency for tool chains using a quantitative model, nor on the cost estimation of tool chain development. However, it is good software engineering practice to estimate the cost of software development before beginning with the implementation. Several techniques exist to determine the cost of software development, see [21] for a literature review. We can distinguish between algorithmic and non-algorithmic methods. Non-algorithmic methods are analogy costing and expert judgment. In analogy costing one compares the project to a similar one with known cost. In expert judgment cost is determined as the average of the opinion of several experts. Algorithmic methods can be empirical or analytical methods. Empirical methods are based on measurements from historical project data. Most algorithmic methods do not calculate cost directly, instead they calculate the development effort as a function of the estimated software size; the relationship between effort and cost is assumed to be linear. Algorithmic methods have a number of parameters that directly or indirectly influence the cost of the software, relating to the product, the project organization, the computer platform, tooling and the skills of programmers. The most important parameter is the size of the artifacts created. The size can be measured in different ways, common units of measurements are lines of code (LOC), function points or object points. Using statistical averages for different programming languages, the size measurements can be converted to LOC. Function points [2] are calculated from the number of user-input types, user-output types, inquiry types, internal file types and external file types. Object points are used for database applications and are calculated from the amount of screens and reports. 2.1
COCOMO II
The Constructive Cost Model (COCOMO) [7, 9] is a widely used, algorithmic, empirical cost estimation model. Development cost is determined by multiplying the effort estimation by a costfactor. The basic COCOMO II model in equation (2) calculates the effort (in person months) as a function over the size estimation. Size is measured in LOC and can be converted from function points according to the tables in the reference manual [7]. The formula has a constant factor A, a proportional effort multiplier M and an exponential scale factor B. Both M and B are composed of several parameters listed in table 1, whose values can be determined by the tables provided in the reference manual [7]. cost =effort ∗ costfactor
effort =A ∗ sizeB ∗ M
(1) (2)
A =2.94
(3)
B =0.91 + 0.01 ∗ (PREC + FLEX + RESL + TEAM + PMAT)
(4)
M =RELY ∗ CPLEX ∗ DOCU ∗ DATA ∗ RUSE ∗ TIME ∗ PVOL∗ STOR ∗ ACAP ∗ PCON ∗ PCAP ∗ PEXP ∗ AEXP ∗ LTEX∗
TOOL ∗ SCED ∗ SITE
(5)
Table 1. Parameters of COCOMO II PREC FLEX RESL TEAM PMAT RELY CPLEX DOCU DATA RUSE TIME PVOL STOR ACAP PCON PCAP PEXP AEXP LTEX TOOL SCED SITE
Previous experience with similar projects Flexibility Extent of risk analysis carried out Cohesion in the team Maturity of the process according to CMMI level Required system reliability Complexity Documentation required Size of database Percentage of reusable components Execution time Volatility of development platform Memory constraint Capability of project analysts Personnel continuity Programmer capability Programmer experience in this domain Analyst experience in this domain Language and tool experience Use of tools Development schedule compression Extent of multi-site working
COCOMO II accounts for the fact that more precise cost estimation is possible later in the project, when more information is available. COCOMO II actually provides several models that can be used in different development stages: The COCOMO II application composition model provides a rough estimate for prototypes, the COCOMO II early design model is based on requirements and design options and the COCOMO II post architecture model allows for precise parametrization once an architecture has been established.
3
Cost-Efficiency of Tool Chains
When project management determines whether a tool chain should be introduced, cost- efficiency analysis should be performed to determine if the construction of the tool chain is worthwhile from an economic perspective. Tool chains provide potential cost savings, but their development has a cost as well. The cost savings of the tool chain usage are offset by the development cost of the tool chain. netvalueTC = costsavings ∗ #uses − costTC
(6)
Equation 6 describes the cost-efficiency model and its main parameters. These parameters are three separate estimates: – costsavings are the estimated cost savings for each use of the tool chain (see section 4). The achievable savings are dependent on the current tool integration situation and the feature set of the new tool chain. – #uses is an estimate of the number of projects that are developed by using this tool chain. – costTC is the estimated cost of tool chain development (see section 5). The development cost depends on the feature set of the tool chain. Equation 6 can be used in a number of ways:
– We can determine for which parameter values the tool chain provides a positive net value, using a break even calculation. The break even point can be calculated by setting the net value to 0, describing the point at which the development cost is completely covered by the cost savings from using the tool chain. If for example the development cost and cost savings are known, we can calculate the minimum necessary number of uses of the tool chain to achieve a positive net value. – Based on the cost savings and an estimated number of uses of the tool chain, we can calculate the maximum allowed development cost of the tool chain. This cost can be used to determine the maximum size of the feature set of a new tool chain. When making such trade-off calculations, one needs to consider that it is more costly to develop a larger feature set, however, a more extensive feature set not always coincides with higher cost savings. Instead of creating the details of this cost-efficiency model from scratch, we base it on the COCOMO II cost model, which has been calibrated by empirical measurements, proven in industrial practice and refined over decades. We use the COCOMO II model two times to determine the parameters of formula 6: for estimating the costsavings of the product development through tool chains (section 4), and for estimating the development costTC of the tool chain (section 5).
4
Cost Savings by Tool Chain Usage
To determine the cost savings of tool chains in the product development process, we compare the predicted amount of work necessary for developing the product with and without the tool chain. For both predictions we use the COCOMO II model. Out of all the parameters of the COCOMO II model introduced in section 2.1, two parameters are influenced by introducing tool chains. The factor M changes due to increased tool support, measured by the effort multiplier TOOL. Improved tool support is usually not provided by the introduction of the tool chain alone, but the introduction of several tools for lifecycle management, such as a software configuration management system. The factor B changes due to increased process maturity, expressed by the scale factor PMAT: configuring and customizing a tool chain may lead to increased awareness and improvement of the development process. The estimated cost savings introduced by the tool chain are a fraction, called savingfactor, of the original product development cost without the tool chain, as shown in equation 7. costsavings =savingfactor ∗ costproduct original
(7)
The savingfactor, can be calculated by relating the product development cost without a tool chain, costproduct original , to the product development cost with the tool chain, costproduct with TC , as shown in formula 8. Both costs are estimated by the COCOMO II model (see equation 2) and since they only differ in the parameters TOOL and PMAT, the formula can be simplified as follows.
savingfactor =
costproduct original − costproduct with TC costproduct original
(8)
B
=1 − =1 −
product with TC Aproduct with TC ∗ sizeproduct ∗ Mproduct with TC
B
product original Aproduct original ∗ sizeproduct ∗ Mproduct original
(9)
TOOLproduct with TC ∗ TOOLproduct original
0.01∗(PMATproduct with TC −PMATproduct original )
sizeproduct
(10)
In formula 10, we can distinguish a size-independent and size-dependent part of savingfactor. In the following sections we isolate the size-independent and sizedependent savingfactor to study them separately by setting the other factor to 1. In a practical setting, both size-independent and size-dependent savingfactor contribute to the total cost savings. 4.1
Size-independent Cost Savings
The TOOL parameter in the COCOMO II model reflects the level of tool integration and lifecycle support. It is one of the proportional effort multipliers for M . The values of the T OOL parameter have been obtained empirically in the context of COCOMO II [7] and are listed in table 2 for convenience. Table 2. Values of the TOOL parameter in COCOMO II [7] TOOL Level Very Low Low Nominal High Very High
Description Edit, code, debug Simple frontend, backend CASE, little integration Basic lifecycle tools, moderately integrated Strong, mature lifecycle tools, moderately integrated Strong, mature, proactive lifecycle tools, well integrated with processes, methods, reuse
Value 1.17 1.09 1.00 0.9 0.78
The achievable savingf actor for a tool chain depends on the level of tool support that was present before and that exists after the introduction of the tool chain, as described in formula 11. Table 3 shows the size-independent improvements achievable through tool integration and lifecycle support. The rows indicate the level of tool support without a tool chain (TOOLproduct original ), the columns indicate the level of tool support with a tool chain (TOOLproduct with TC ) and the values are the size-independent savingfactors in percent. The maximum cost savings of 33% can be achieved when introducing a tool chain with a very high level of integration into an original situation with a very low level of integration. savingfactorsize-indep = 1 −
TOOLproduct with TC TOOLproduct original
(11)
Table 3. Size-independent cost savings factor
from Very Low from Low from Nominal From High
4.2
to Low to Nominal to High to Very High 7% 15% 23% 33% 8% 17% 28% 10% 22% 13%
Size-dependent Cost Savings
The introduction of tool chains often coincides with a higher awareness of the development process and the introduction of a more rigorous development process. As a result, the level of CMMI (Capability Maturity Model) [11] might be increased, which in turn has an effect on the process maturity scale factor PMAT in the COCOMO II model. The effects of an increased PMAT-level on the cost of product development are shown in formula 12. According to the COCOMO II model, a higher PMATlevel leads to a decreased product development cost. The savingfactor is dependent on the size of the developed software product. Larger projects have a higher potential for exploiting the CMM process improvements. In addition, there is a higher potential for saving when the gap between the original and the new process maturity is large. Note, that changes in process maturity, especially large ones, are not achievable with tool integration alone; tool integration can merely contribute to and accelerate such an improvement. 0.01∗(PMATproduct with TC −PMATproduct original )
savingfactorsize-dep = 1 − sizeproduct
5
(12)
Cost Estimation of Tool Chain Development
In this section we use the software cost model COCOMO II to estimate the cost of tool chain development. For the efficiency calculations in project management and planning, a precise estimate of the development cost of the tailored tool chain is important. This estimate should reflect changes in the set of features of the tool chain; a more extensive feature set should result in a higher cost of development. We use the COCOMO II post architecture model, which has a large number of parameters, such as parameters describing the development process, methodology and tool support. The most important parameter is the size estimate of the tool chain, which could be determined with relatively high accuracy if an architectural description of the tool chain were available. We have identified an architectural language, which is suitable for precise cost estimation with the COCOMO II post architecture model. This language is dedicated to describing the architecture of tool chains and also has code generation facilities, which leads to a predictable and precise estimate of the code size of the tool chain.
5.1
Modeling and Analyzing Tool Chains with TIL
The Tool Integration Language TIL [6] is a domain specific modeling language [17] for specifying tool chains as a model. Code generators synthesize implementation skeletons for the tool chain from the TIL model. The generated implementation skeletons need to be completed with manual implementations later. This approach allows tool chain designers to make the essential design decisions early and analyze their effects, including non-functional properties such as the development cost of the tool chain. The TIL model describes the essential parts of a tool chain by a set of tool adapters and channels. The tool adapters represent the integrated tool and are specified in more detail by a tool adapter metamodel. This metamodel describes the data and services that are exposed by the tool and can be used for integration. The channels represent control flow and data flow between the tool adapters. Control channels model the control flow, they represent service calls between tool adapters. Data channels model the data flow, which might mean copying data, transforming data or linking data. The endpoints of data flow are tool adapters, which specify their data structure by tool metamodels. Data flow may involve specifying a model transformation if the endpoints of the data flow require data in a different structure. More information on TIL can be found in [6]. The generative approach and the architectural description of the tool chain provide a basis for cost and effort estimation. The total effort for creating a tool chain with TIL consists of three parts: (1) modeling, which is relatively simple, (2) code generation, which does not cost any effort due to complete automation and (3) manual implementation. The effort of modeling with domain specific languages has been studied in general [16, 24] and could be applied to TIL models as well. The modeling effort is, however, relatively small compared to the effort of manual implementation; we thus focus on the effort of manual implementation. For each TIL model, the manual implementation cost of the tool chain can be calculated based on COCOMO II as follows. costTC = costfactorTC ∗ effortTC
TC effortTC = ATC ∗ sizeB TC ∗ MTC
(13) (14)
In section 5.2 we focus on a precise size estimate for tool chains described by TIL models. In section 5.3 we provide values for the parameters MT C and BT C . 5.2
Size Estimate for Tool Chains described in TIL
Any TIL model provides the information necessary for performing size estimation. For size estimation of generic software systems, function points are converted into lines of source code using a generic conversion factor. In our domainspecific approach we can here use additional knowledge about the system: the tool adapter metamodel provides the function points, measurements of the size of generated code and average values of the size for manual code additions can provide a more precise estimate than a generic conversion factor.
The tool chain described in TIL consists of a number of different parts, such as the tool adapters T Ai , i = 0..m, the control channels CCj , j = 0..n and the data channels DCk , k = 0..p. The size of the tool chain is the sum of the size of all tool adapters and all channels. The size of a tool adapter, sizeT A , depends on the number of metaclasses and the number of services specified in the metamodel of the tool adapter. The size of the control channels, sizeCC , is constant due to the complete code generation. The size of the data channel, sizeDC depends on the size of the metamodels of the source and target tool adapters. The constant factors in formulas 15 to 21 have been determined from the algorithms in the code generators and from the size of average manual additions. Note that the size below is calculated in LOC, whereas KLOC (= 1000 LOC) is expected in equation 14. We present two code size estimates: The size of the complete code, including generated and manually added code, sizeT C , and the size of the manually added code alone, sizeT C manual . If no code generator is used, the size of the complete code is relevant for cost estimation, sizeT C , as calculated in formulas 15 to 18. sizeTC =
m X
sizeTA (TAi ) +
i=0
n X
sizeCC (CCj ) +
j=0
p X
sizeDC (DCk ) + 320
(15)
k=0
sizeTA =250 ∗ (#metaclasses + #services) + 200 sizeCC =46 sizeDC =4 ∗ (#metaclassessource + #metaclassestarget ) + 524
(16) (17) (18)
If the TIL code generator is used, only manually added code requires an effort and is relevant for cost estimation. This is shown in formulas 19 to 21. sizeTC manual =
m X
i=0
sizeTA manual (TAi ) +
p X
sizeDC manual (DCk )
sizeTA manual =45 ∗ (#metaclasses + #services) sizeDC manual =4 ∗ (#metaclassessource + #metaclassestarget )
5.3
(19)
k=0 (20) (21)
COCOMO Parameters for TIL Models
Some effort multipliers can already be determined in advance for tool chain development with TIL, as displayed in table 4. They pertain to product, project and computer effort multipliers. The remaining effort multipliers and the scale factors depend on the team and organization carrying out software development of the tool chain and thus need to be determined individually. With the values of the 9 effort multipliers described in table 4 and the values of the remaining effort multipliers set to their nominal values, we can calculate MTC = 0.78 and BTC = 1.1.
6
Case Study
In this section we show how the cost-efficiency model for tool chains can be applied in a case study. This case study is inspired by our industrial partner, who develops an embedded systems product characterized by tightly coupled
Table 4. COCOMO II Parameters for TIL Models Parameter RELY CPLEX DOCU DATA RUSE TIME PVOL STOR TOOL
Value Low Nominal Low Low Very High Nominal Nominal Nominal High
Comment Tool chain is not safety critical Nominal complexity No special need for documentation No database needed Tool adapters will be reused in other projects No real time requirements New versions of development tools every 6 months Nominal storage TIL modeling environment and generators provide tool support
hardware and software components: The application logic is partitioned into software running on a micro controller and hardware logic realized by an FPGA. The product development process requires a number of tools for modeling, simulation, analysis, code-generation and coding. In the following we describe the tool chain (find .. 0 5 in figure 1 ) of the case: – 0 The system architect designs a UML component diagram in the Eclipsebased Papyrus UML. – 1 The UML model is refined and committed to the repository. Every time a new version is committed, 2 an automated safety analysis with a fault tree analysis tool is executed. Also, a simulation of the model in MATLAB/Simulink is 3 created and 4 started. – When the results of the safety analysis and simulation are satisfactory, the control engineer is 5 notified and he continues by using the code generation of Simulink to generate C code for the software and VHDL for the hardware. We first model the overall architecture of the tool chain in TIL, as presented in figure 1. In addition, we define the tool metamodels for each tool adapter. In figure 2 we show an example of such a tool metamodel for the data and services of Simulink. Similar tool metamodels exists for the other tool adapters as well.
Fig. 1. Design of the Tool Chain in TIL
In equations 22 to 25 we apply the cost-efficiency model to the described tool chain for break-even analysis. We assume a conservative size-independent
Fig. 2. A Simple Tool Metamodel for the Exposed Data and Services of Simulink
improvement based on the TOOL parameter from very low (1.17) to nominal (1.0) and no size-dependent improvements. This yields a savingfactor of 15%, and at a total product development cost of $1M, the cost savings are $150K according to equation 7. Let us first assume that no code generator is used and the tool chain is manually implemented. The size of the tool chain sizeTC = 11K LOC is calculated according to formula 15 with the intermediate results shown in table 5. The cost of tool chain development is based on a costfactorTC of $5K, the nominal value of BTC = 1.1 and MTC = 0.78 according to table 4. With these values, formula 14 yields a development cost of $160K. The proposed tool chain can only be cost-efficient if it will be used for at least two projects, according to formula 25.
#usesbe =
&
costTC costsavings
'
B costfactorTC ∗ ATC ∗ size TC ∗ MTC TC #usesbe = TOOLproduct with TC (1 − TOOLproduct original ) ∗ costproduct original $5K ∗ 2.94 ∗ 111.1 ∗ 0.78 #usesbe = (1 − 1 ) ∗ $1M 1.17 & ' $160K #usesbe = = 2 $150K
(22)
(23)
(24)
(25)
Let us now assume that the TIL code generator is used instead, so only the manually added code needs to be included in the size calculation. The size of the tool chain, sizeTC manual , is 1.6K LOC, according to formula 19 and table 5. All remaining parameters are as above. This yields a development cost of $19K. The proposed tool chain is thus predicted to be cost-efficient at its first use, if it is developed with the TIL code generator. In the same way we compare the cost of alternative development methods for tool chains here, alternative feature sets of the tool chain can be analyzed and compared with the cost-efficiency model.
Table 5. Size predictions and measurements of the tool chain implementation #metaclassessource #metaclassestarget #metaclasses #services Measured Generated LOC Measured Manual LOC Measured Total LOC Predicted Total LOC sizeTC Predicted Manual LOC sizeTC manual
7
TASim TAUML TASafety All CC DCuml2sim DCuml2safety DCuml2rep Sum 6 6 0 3 14 0 3 6 14 8 0 2 2030 1409 3833 368 524 524 524 9532 1118 59 317 0 49 82 0 1625 3148 1468 4150 368 573 606 524 11157 2950
1700
4200
368
560
604
495
270
720
0
36
80
524 11226 0
1601
Delimitations and Limitations
We focus in this paper on the cost savings provided by tool chains and at the same time acknowledge that cost savings are only one of the benefits of tool chains. We explicitly would like to mention that a comprehensive decision making process for the introduction of a tool chain should consider - besides cost savings - other potential improvements and additional costs of tool chains. While productivity improvements, time savings and higher speeds of execution will in the end be reflected by cost savings, other benefits such as quality improvements and increased transparency provided by tool chains are not captured by cost savings and need to be considered separately. Tool chains require additional costs, occurring before and after the introduction of a new tool chain. Before the introduction of the tool chain, there are the development cost of the tool chain. After the introduction, new or enhanced software engineering practices need to be introduced that can deal with the changes that are caused and enabled by tool chains. We explicitly list the limitations of the chosen estimation approach, they pertain to general limitations of estimation approaches and the chosen COCOMO II model. We provide a method that not merely measures the cost savings of existing tool chains, but that predicts the theoretically achievable cost savings of future tool chains before they are built; we thus build an estimation model. There is an inherent risk of the accuracy of software cost estimation models, as documented in [19]. Frameworks for measuring the accuracy have been established [13]. Our model inherits the risks of applicability and accuracy from COCOMO II, since the estimations in this paper are based on the parameters determined empirically [7, 9]. COCOMO II has been successfully used in practice, and has been calibrated for modern development processes, e.g. for real-time embedded systems development [20]. Despite these facts, we need to be prepared for estimation errors resulting from applying the COCOMO II model [18].
8
Future Work
We would like to extend both the calculation of cost savings and the development cost of tool chains to achieve higher accuracy in our estimates. While the ToolAdapter metamodel can be used for determining the number of services to be implemented, the size of each of these manual implementation
of these services may vary. We have used the average of all implementations for several ToolAdapters. Future work needs to refine the average code size for these manual additions, using a larger base of ToolAdapter implementations. The calculation of effort and cost based on the size estimation uses the empirical data used for parameterizing COCOMO II, which has been validated. In addition, we would like to validate all aspects of the derived cost-efficiency model w.r.t. measured data from industrial tool-chain development. We would like to study the relevance and influence of additional COCOMO II parameters, such as PCAP or TEAM, on the cost of the tool chain. We would like to use the extended COCOMO model [25] for the calculation of cost savings. With its three dimensions of describing tool integration, more accurate estimates might be possible. The development cost of tool chains effort is more comprehensive if we also include the effort of modeling with the domain specific language TIL, in a similar way as in [24]. Furthermore, the separate and independent evolution of software development tools is a challenge for the maintenance of tool chains. The economic implications of such maintenance aspects need to be quantified in future work.
9
Conclusion
In this work we use estimation techniques to predict reductions in work and cost through tool chains before the tool chain has been built. The cost-efficiency model for tool chains presented in this paper can be used both by practitioners in industry and researchers providing new technologies for tool chain design. The model may support industrial users, when comparing alternative tool chains. For such a decision many aspects need to be considered, and cost is only one of them, although an important one. The calculations of the efficiency model can thus provide input for well-informed decision making, especially table 3 can serve as a first rough estimate of the cost savings. The model can help to dimension the feature set of the tool chain and finding a balance between cost savings by the tool chain and cost of tool chain development.
References 1. Chris Abts, Barry W. Boehm, and Elizabeth B. Clark. COCOTS: A COTS Software Integration Lifecycle Cost Model - Model Overview and Preliminary Data Collection Findings. In In ESCOM-SCOPE Conference, 2000. 2. A. J. Albrecht and J. E. Gaffney. Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation. IEEE Trans. Softw. Eng., 9:639–648, November 1983. 3. F. Altheide. An architecture for a sustainable tool integration. In D¨ orr and Schurr, editors, Workshop on Tool integration in system development, 2003. 4. Jongmoon Baik, Barry Boehm, and Bert M. Steece. Disaggregating and Calibrating the CASE Tool Variable in COCOMO II. IEEE Trans. Softw. Eng., 28:1009–1022, November 2002.
5. Sana Ben, Abdallah B. Lamine, Lamia L. Jilani, Henda Hajjami, and Ben Ghezala. SoCoEMo-COTS: A Software Economic Model for Commercial Off-The-Shelf (COTS) Based Software Development, 2006. 6. Matthias Biehl. Tool Integration Language. Technical Report ISRN/KTH/MMK/R-11/16-SE, Royal Institute of Technology (KTH), September 2011. 7. Barry Boehm, Chris Abts, Ellis Horowitz, A. Winsor Brown, Ray Madachy, Sunita Chulani, Don Reifer, Brad Clark, and Bert Steece. COCOMO II Model Definition Manual. Technical report, Center of Software Engineering at USC, 2000. 8. Barry W. Boehm. Software Engineering Economics. Prentice Hall, 1 edition, November 1981. 9. Barry W. Boehm, Chris Abts, A. Winsor Brown, Sunita Chulani, Bradford K. Clark, Ellis Horowitz, Ray Madachy, Donald J. Reifer, and Bert Steece. Software Cost Estimation with Cocomo II. Prentice Hall, August 2000. 10. 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. 11. Mary B. Chrissis, Mike Konrad, and Sandy Shrum. CMMI: Guidelines for Process Integration and Product Improvement (Sei Series in Software Engineering). Addison-Wesley Longman, Amsterdam, 2nd ed. edition, November 2006. 12. J. El-khoury, O. Redell, and M. T¨ orngren. A Tool Integration Platform for MultiDisciplinary Development. In 31st EUROMICRO Conference on Software Engineering and Advanced Applications, pages 442–450. IEEE, 2005. 13. Stein Grimstad and Magne Jørgensen. A framework for the analysis of software cost estimation accuracy. In Proceedings of the 2006 ACM/IEEE international symposium on Empirical software engineering, ISESE ’06, pages 58–65, New York, NY, USA, 2006. ACM. 14. C. Hein, T. Ritter, and M. Wagner. Model-Driven Tool Integration with ModelBus. In Workshop Future Trends of Model-Driven Development, 2009. 15. James D. Herbsleb. Global Software Engineering: The Future of Socio-technical Coordination. In 2007 Future of Software Engineering, FOSE ’07, pages 188–198, Washington, DC, USA, 2007. IEEE Computer Society. 16. J. H. Hill. Measuring and Reducing Modeling Effort in Domain-Specific Modeling Languages with Examples. In Engineering of Computer Based Systems (ECBS), 2011 18th IEEE International Conference and Workshops on, pages 120– 129. IEEE, April 2011. 17. Steven Kelly and Juha-Pekka Tolvanen. Domain-Specific Modeling: Enabling Full Code Generation. Wiley-IEEE Computer Society Pr, March 2008. 18. Marcel Korte and Dan Port. Confidence in software cost estimation results based on MMRE and PRED. In Proceedings of the 4th international workshop on Predictor models in software engineering, PROMISE ’08, pages 63–70, New York, NY, USA, 2008. ACM. 19. K. Molokken and M. Jorgensen. A review of software surveys on software effort estimation. In Empirical Software Engineering, 2003. ISESE 2003. Proceedings. 2003 International Symposium on, pages 223–230. IEEE, 2003. 20. Cynthia Nyborg. Detailed COCOMO Applied to Real-time Systems at Xerox. Technical report, University of Southern California, November 1987. 21. M. Shepperd. Software project economics: a roadmap. In Future of Software Engineering, 2007. FOSE ’07, pages 304–315. IEEE, May 2007. 22. M. Wicks and R. Dewar. A new research agenda for tool integration. Journal of Systems and Software, 80(9):1569–1585, September 2007.
23. M. N. Wicks. Tool Integration within Software Engineering Environments: An Annotated Bibliography. Technical report, Heriot-Watt University, 2006. 24. Yali Wu, Frank Hernandez, Francisco Ortega, Peter J. Clarke, and Robert France. Measuring the effort for creating and using domain-specific models. In Proceedings of the 10th Workshop on Domain-Specific Modeling, DSM ’10, New York, NY, USA, 2010. ACM. 25. Yun Yang and Jun Han. Classification of and Experimentation on Tool Interfacing in Software Development Environments. In Proceedings of the Third Asia-Pacific Software Engineering Conference, APSEC ’96, Washington, DC, USA, 1996. IEEE Computer Society.
