FULL ENJOY 🔝 8264348440 🔝 Call Girls in Diplomatic Enclave | Delhi
TIL - Tool Integration Language
1. 1Matthias Biehl
A Modeling Language for the
Integration of Tools
Matthias Biehl
matt.biehl@gmail.com
www.matt-biehl.de
2013-01-17
2. 2Matthias Biehl
Overview
Context Embedded systems development
Problem How to integrate tools used for
embedded systems development?
Approach Systematic description and
development of tool chains
Results Tool chains can be tailored
and efficiently developed using
A modeling language and
Automated development support
Conclusion Implications for tool chain development
3. 3Matthias Biehl
Context: Development of Embedded Systems
Product
A computer system that is part of a
larger system and performs some of
the requirements of
that system [IEEE Glossary]
Processes, Methods, Tools
Tools are used to support:
Design and analyis of product properties
Different engineering disciplines
Different phases of the lifecycle
People
Diverse expertise needed:
hardware, software, control,
mechanics
Heterogeneity
Complexity
4. 4Matthias Biehl
Tools for Embedded Systems Development
Software Engineering
Control Engineering
Hardware Engineering
System Architect
Mechanical Engineering
Process
Engineering
Disciplines
Requirements Verification
Prototyping
Support
5. 5Matthias Biehl
Overview
Context Embedded systems development
Problem How to integrate tools used for
embedded systems development?
Approach Systematic description and
development of tool chains
Results Tool chains can be tailored
and efficiently developed using
A modeling language and
Automated development support
Conclusion Implications for tool chain development
6. 6Matthias Biehl
Need for Integration
Tools provide limited native integration
• are island solutions
• difficult to connect tools
• to transfer data,
• to create traces,
• to create scripts involving multiple tools
Integration Concerns
Semantic
Structural
Technical
7. 7Matthias Biehl
Integration through Tool Chains
Tool chains provide external integration:
• bridge the gap between the tools
• realized as software
• cover several integration aspects
Benefits: reuse, automation, productivity
Data-Transfer
Data-Tracing
Control-Invocation
Control-Notification
Process
Platform-Distribution
Integration Aspects
Presentation
8. 8Matthias Biehl
Market for Integration of Tools
• Tool Integration = Application Lifecycle Management (ALM)
• Planning and governance activities of the software development life cycle (SDLC).
• Market size and growth
• $1.5 billion for 2011
• CAGR 4%
• High-level approaches
• Individual Integration Software (best of bread, customization but high cost)
• One-Size-Fits-All (cost-efficient, but lock-in and not fulfilling all requirements)
• We use middle road: (best of bread, customization and cost-efficient)
• reuse of components, automated code generation, standards
• Data according to Gartner Report “Magic Quadrant for Application Life
Cycle Management”, June 2012
9. 9Matthias Biehl
Need for Customization
• Customization needed
• Many different tools, combination of tools
• Different processes, different information needs, different ways of using the tools
• Customized tool chains need to be developed
10. 10Matthias Biehl
Challenges in Tool Chain Development:
Several Stakeholders
Tool Vendors
Developers
IT Infrastructure
Tool Integration Specialist
OSLC
Process Engineer
?
11. 11Matthias Biehl
WSDL
BPEL
Challenges in Tool Chain Development:
Development
Java
ATL
• Limited development support
• Mostly built manually
• Low levels of reuse
• High effort to build
?
Stakeholders
OSLC, IBM
12. 12Matthias Biehl
Overview
Context Embedded systems development
Problem How to integrate tools used for
embedded systems development?
Approach Systematic description and
development of tool chains
Results Tool chains can be tailored
and efficiently developed using
A modeling language and
Automated development support
Conclusion Implications for tool chain development
17. 17Matthias Biehl
Technologies
• Workbench + Code Generator
• Java
• Eclipse Libraries: EMF, GMF
• Model to Text Transformations: Code Generation
• Runtime
• Java
• Service Component Architecture (SCA) for realizing SOA
• REST
• Jetty Server
• RDF (Resource Description Format)
• JSON
• OSLC (Open Services for Lifecycle Integration)
• AJAX: JavaScript
• Model to Model Transformation Languages
18. 18Matthias Biehl
Compare: Enterprise Application Integration (EAI)
• Challenge is similar to tool integration
• Frameworks and patterns exist already
• E.g. Apache Camel
20. 20Matthias Biehl
Evaluation of Development Efficiency Gains
• Using the TIL approach: Percentage of
generated lines of code
vs.
manually added lines of code.
• Manually added code: LOC with
TIL
vs.
a completely manual implementation
80% Reduction of Manual Development Effort and Cost
22. 22Matthias Biehl
Cost Savings by Tool Integration
in the Business of our Industrial Partners
• Based on software cost estimation model (COCOMO)
23. 23Matthias Biehl
Cost Savings by Tool Integration
in the Business of our Industrial Partners
• Depending on Level of existing integration (Rows)
• Depending on Desired Level of Integration (Columns)
24. 24Matthias Biehl
Overview
Context Embedded systems development
Problem How to integrate tools used for
embedded systems development?
Approach Systematic description and
development of tool chains
Results Tool chains can be tailored
and efficiently developed using
A modeling language and
Automated development support
Conclusion Implications for tool chain development
25. 25Matthias Biehl
Review: Challenges of Tool Chain Development
?
Challenges in
• Customizing tool chains
• Describing tool chains
• Developing tool chains
26. 26Matthias Biehl
Implications for Tool Chain Development
Infrastructure for
• Customizing tool chains
(for each company, for each project)
• Describing tool chains
technology- agnostic and domain-specific
• Developing tool chains
faster and at reduced cost
Hinweis der Redaktion
During the next half hour I will introduce the context of this work, the problem addressed by this work, the specific approach I took to solve the problem, the results, and the conclusion in terms of the implications of this work.To start with, lets look at embedded systems development as the context of this work
(I have studied tool chains in the context of embedded systems development.)First, what is an embedded system? It is a small computer that is part of a bigger product and fulfills some of its requirements. These products are all around us and they are part of our daily life, and you mighthave already used several of them … today.The development of such embedded systems is complex, due to the heterogeneity of the product and the tight integration with the surroundings. Engineers from diverse fields are required for the development, such as hardware, software, control, mechanics. A number of different processes and methods are used by the different engineering disciplines. In this talk I will focus on the tools used in embedded systems development.Tools are used to design and analyse the properties of the product, to support the different engineering disciplines, and to support the different phases of the development process.---------------------------------Innovative functions in traditionally mechanical products realized by embedded systemsIncreasing in numberIncreasing in complexityExamplesAdvanced driver assistance systemsActive safety systemsDevelopment of embedded systems requires a number of development tools to support:Different phases of the lifecycleDifferent engineering disciplinesAnalysis and verification of the different system properties
Here I would like to illustrate the landscape of toolsfor embedded systems development by providing some examples.First of all, each engineering discipline uses specific tools, here illustrated by a numberof examples, there are many alternatives to the tools I picked here.Throughout the different phases of the development process, specific tools are used.In addition to the design and implementation we have tools for prototyping, requirements or verification. In addition, crosscutting tools are used that support the process as a whole, such as repositories or tools for data management.Tools for the largest part are commercial-off-the-shelf tools, but may also be open-source or in-house developed tools. The tools can thus not be changed and have to be used as they are.Why do we use these tools?We use these tools because each of these tools can help us to be more productive, manage knowledge, and manage the complexity of development.But there is also a problem.
And that problem comes up, whenever we use not only single tools but several tools in combination, leading to the question: how to integrate tools for embedded systems development.
So, due to the heterogeneity of embedded systems, not only single tools, but a large number and a large variety of tools are used.Here I selected a number of tools and each of these tools captures a different aspects of the same embedded system. The data in these tools is related and for this reason, we would like to…reuse this data in different tools by transferring data between the tools, document how the data in the different tools is related by creating traces between data elementsOr automate development tasks involving several tools.This is however difficult, since these tools provide limited forms of integration and connection…. The tools are isolated … and you can think of the tools as islands.And that is due to technical differences, syntactic differences and semantic differences.----(… now lets look at an example. We selected a set of tools to develop an embedded system. )And in order to transfer things between islands one could create ad-hoc solutions and swim over to the other shore, but this requires a lot of effort and is not sustainable.Since the data in thesese tools is related …
Due to the limited native integration between the tools, we create external solutions, called tool chains.Tool chains bridge the gap between the tool islands. Tool chains are realized as software and can be used several times.Tool chains cover different aspects of integration, such as Data integration in terms of data transfer and data tracesControl integrationProcess integrationPlatform integrationPresentation integration to provide a common user interface is providedThe benefits we expect from tool chains areIncreased reuse of development artefactsIncreased levels of automationIncreased productivity of product development(7:50)----------What would be better is if we could have a connection between the islands, that is sustainable and that we can reuse, such as a bridge.When integrating tools these bridges allow us to transfer data, create traces or create automated scripts.Tools: provide limited native integrationLarge number of tools in embedded systems developmentTool Chains Provide external integration
(7:50)How many different tool chains do we need?There are a lot of different tools, more ways of using these tools, and even more ways of combining these tools.To provide the expected benefits, tool chains need to be customized and need to fit the selection of tools, the process used for developing the embedded system, the people and their best practices.One-size-fits-all is not applicable for these diverse requirements and tool chains need to be customized to the specific requirements of each company or project.One project might use require a tool chain like this…Another project might use a similar landscape with an alternative tool which is connected in a slightly different way…But then there are project that use completely different tools with different connections.So the point is, we need to customize tool chains since one size fits all is inappropriateThis leads to the challenge of having to develop a number of different tool chains, which leads to a number of challenges…Since we have a large number of potential tool chains, it makes sense to invest in the infrastructure of building tool chains. This will enable us to build a particular tool chain that is required in a specific context faster.(10:00)-----Development of customized tool chains is costly, inappropriateArtemis Strategic Research Agenda 2012: Design Methods and Tools Tool Integration is a high priorityObjectives: design efficiency, systematic design, productivity and qualityTools cannot be used because of missing/costly integrationTyranny of tools-----------------design tools and methods for embedded systems development.focus on single tools and the improvements they providehowever, multiple tools need to be used in combination, thus environments need to be built from several single tools.environments differ from each other, depend on process, tools ...need to be customized
Now when we look at the stakeholders for tool chain development, we see that most stakeholders are not familiar with the integration technology. It is thus inappropriate form of description for tool chains.Each one of the different stakeholders provides some input:Embedded Systems developers know the tools they use and how they use themIT infrastructure deploys the toolsTool vendors know how to interface their toolsProcess engineers have the big picture of the development process.Tool integration specialists are the only ones who know the integration technologies and conventions-----------------Unclear responsibilities.In the process of customization and development of the tool chain a numberof different stakeholders are involved.Tool vendors: Tyranny of tools, tools dictate the process, focus on one tool, no overall picture
(13:00) There is also a lack of development support that guides us in realizing the idea of a tool chain as a software.Since there is limited methodological and tool support and little reuse of tool chain parts, Tool chains are mostly built manually and it requires a high effort to build a tool chain.Since many different, customized tool chains need to be developed, it makes sense to invest into an infrastructure for tool chain development.(13:30)-------------What is missing, is the development support for building tool chains
Based on the identified limitations and challenges, we propose an approach for the systematic description and development of tool chains.
This is the overview of the approach.There are stakeholders who have an idea about the tool chain they want to buildThey describe the tool chain as a model, using a domain specific modeling language. Based on the language, we want to provide development support.We have a description of the tool chain as a model, not only as a picture which allows us to support the stakeholders during tool chain development in terms of design, refinement, analysis amd synthesis.And in the end they will receive the tool chain implementation. (18:00) ----------A model of the tool chain can be designed and refined, can be analyzed and finaly an implementation can be synthesized.Mention the different stakeholders: tool vendors, tool chain developers, embedded systems developers as the users of tool chainsOn the previous slide I showed that tool chains as a set of islands with the tool logo… but that was just a picture.what information is required to describe a tool chain so we can build it?And how can we support the construction?
We performed a domain analysis to elicit the concepts of the tool integration language, TIL.In this language we have the following concepts…A tool adapter which is a representative of a tool in the tool chain.A user of the tools or tool chainA repository of the dataA tool chain is described as a composition of the other conceptsA data channel representing the transfer and conversion of dataA trace channel representing the creation of tracelinks between dataA control channel representing the invocation of services and the notification of usersA sequencer for an ordered sequence of service invocationsHere you see the concrete graphical syntax of the language-------------The concepts of TIL are …
(21:00)So how do I use this language? Here is an ideaof a tool chain I would like to describe, consisting of a UML tool, Matlab/simulink and a safety analysis tool called hiphops.We create an architectural model of the tool chain using til.We can recognize there are tool adapters representing the 3 tools.And these tools are connected using data channels to facilitate data transfer and conversion.This tool chain intends to support model-based engineering: whenever the UML model changes, we want to analyze it automatically using the safty analysis tool and simulink.This is described in TIL:The control engineer uses the checkin functionality of the tool chain to commit the UML data to the repository. Whenever new data is in the repository, a sequence of invocations is started, first a data transfer and conversion, then an invocation of the safety analysis, another data transfer and conversion and an analysis in Simulink. Finally the user is notified.When we describe a tool chain in til, we need to describe the role of the tool in the context of the tool chain by describing the data and services exposed by the tool adapter.This needs to be done for all tools.We also need to describe the conversion rules of the data channel for allowing data transfer between the tool adapters.Together this is a fully specified model of the tool chain.(24:00)---------------So here is an example of how we describe the tool chain as a product model (transition to next slide).
To support the stakeholders to specify a tool chain model in TIL, the TIL Workbench is provided.So far we can describe, communicate and document a tool chain, but we can do much more with a tool chain model.----------------So far we can describe the idea of a tool chain as a model.This model is graphical and can be used for communication among the stakeholders.It can be used as a blueprint for the tool chain implementation.But more can be done with the model.
We regard the tool chain as a product to be developed based on the TIL model.The TIL model goes through several phases of tool chain design, such as a requirements engineering phase, conceptual design phase, refinement in the detailed design phase, analysis and implementation.Here we have modeled the tool chain development process as a SPEM model, the software process engineering metamodel.------------------------To study development support, we identify the different development stages.We describe not only the tool chain as a model, but also the process for developing the tool chain.So here is a model of the process we use for tool chain development – it is described using the software process engineering metamodel (SPEM) of the OMG. – What do we need to do in order to describe a tool chain?This process model is slightly different to the process model I have shown earlier, since it includes the
A part of the tool chain implementation needs to be manually coded, since it is too specific.The question is: how much source code can be generated?In the first graph we have studied the percentage of generated vs manually added code.Dark blue is the percentage of generated code, light blue is the percentage of manually added code.Simulink required a lot of manually added code, because it is very specific in its interface technology.Then we can compare the manually added code in the TIL approach to a completely manual implementation of a tool chain. The code that needs to be manually added with the TIL approach is only a fraction of the code that would have been necessary for a completely manual implementation.
In the beginning we identified the challenge of creating a customized tool chain based on the idea of a tool chain.---StrengthsWeaknesses/LimitationsWhat did I learn?
With TIL we have a modeling language for describing a tool chain systematically, a process for developing tool chains, and tool support for the modeling language and automated development support that helps us to create the tool chain.This approach provides the ability to customize tool chains.The language is technology agnosticAnd the language is close to the domain of tool integration.The approach thus has the potential to provide faster tool chain development at a reduced cost.
