=Paper=
{{Paper
|id=None
|storemode=property
|title=Automated Derivation of Configurations for the Integration of Software(+) Engineering Environments
|pdfUrl=https://ceur-ws.org/Vol-688/acota2010_paper2_biffl.pdf
|volume=Vol-688
|dblpUrl=https://dblp.org/rec/conf/acota/BifflMM10
}}
==Automated Derivation of Configurations for the Integration of Software(+) Engineering Environments==
https://ceur-ws.org/Vol-688/acota2010_paper2_biffl.pdf
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
Automated Derivation of Configurations for the
Integration of Software(+) Engineering Environments
Stefan Biffl, Richard Mordinyi and Thomas Moser
Christian Doppler Laboratory “Software Engineering Integration for Flexible Automation Systems”
Vienna University of Technology
Vienna, Austria
{stefan.biffl, richard.mordinyi, thomas.moser}@tuwien.ac.at
Abstract—Today’s systems integration technologies enable the methods for each tool), different tool data formats (e.g., open
integration of (software+) engineering environments to support standards vs. proprietary data formats), and the need for
engineering processes across domain and tool boundaries. These on/offline capabilities (e.g., high availability of server-based
engineering processes heavily rely on manual configuration of tools vs. limited availability of end-user tools). The manual
integration frameworks, resulting in costly, time-consuming, and configuration of the used integration technology with respect to
error-prone human work. In this paper, we introduce an these complexity issues is often inefficient and incorrect. In
extended model-driven approach for the automated derivation of order to reduce manual configuration efforts and defects, as
integration technology configurations for supporting engineering
well as to increase the efficiency of integration, automated
processes. This allows both an efficient and effective derivation of
derivation of configurations can be used. There exist methods
initial configurations, as well as easy adaptations of existing
configurations in case of changed engineering processes. Based
for the automated derivation of configuration based on the
on a standard software engineering process, we show the Model-Driven Architecture (MDA) [15] paradigm, such as the
feasibility of the proposed approach and discuss the advantages Model-Driven System Configuration (MDSC) approach [16].
and limitations for software(+) engineering. The MDSC approach explicitly models a) the semantics of
integrated engineering tools’ requirements and capabilities
Keywords: engineering domains; systems integration; model- [17]; and b) the connectors and data transformations between
driven approach; automated configuration heterogeneous engineering tools [16], to simplify systems
integration. Based on these semantic models, the MDSC
I. INTRODUCTION approach is capable of automatically deriving integration
technology configurations.
Typical large-scale engineering projects, like power plants
or car manufactures, involve the cooperation of a wide range of In this paper, we describe an extended version of the
engineering systems and tools that use different technical MDSC approach applied to the integration of heterogeneous
platforms and heterogeneous data models (e.g., mechanical, tools originating from (software+) engineering disciplines. In
electrical, and software engineering [5]). This kind of contrast to the traditional MDSC approach, the extended
cooperation is called “(software+) engineering projects”, since MDSC (eMDSC) approach uses semantically modeled
software engineering provides additional values to software- requirements of pre-defined engineering processes to a) select a
intensive systems and also depends on the seamless set of suitable engineering tools providing the required
collaboration with other engineering fields. Today’s system capabilities; and b) to derivate configurations for the
integration technologies are suitable to bridge most of the integration technology accordingly. The eMDSC approach
technical and semantic gaps between these (software+) consists of two major steps: in the first step, requirements of
engineering systems and tools. However, error-prone and time- engineering processes are matched against capabilities of so-
consuming human work (e.g., manually copying information called tool domains [6], which abstract tools providing similar
from one to another tool) is needed to handle integration functionality. The outcome of this matching is an ordered set of
concerns at the interfaces of different engineering disciplines. tool domains required for the execution of a specific
An example for reducing the needed human work, and thus for engineering process. In the second step, for each of these
the integration of heterogeneous engineering disciplines, is the required tool domains a so-called tool instance, i.e., the actual
Engineering Service Bus (EngSB) [6], which is a process- engineering tool, is selected. Again, the engineering process
oriented framework for both technical and semantic integration requirements regarding a specific engineering domain are
of heterogeneous software tools. matched against the capabilities of a certain tool instance in
order to identify suitable engineering tools for an engineering
The configuration of such system integration technologies process step.
is time-consuming and a complex manual task that can only be
done by designated integration experts (IE) [12]. Complexity We evaluate the proposed eMDSC approach using a well-
arises from the integration of a high number of distributed and known software engineering process, the Continuous
heterogeneous engineering tools (e.g., different accessibility Integration & Test (CI&T) process [9]. The results of the
6
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
evaluation show that the proposed approach is efficient and share data across disparate and semantically heterogeneous
effective, regarding both the effort needed for setting up the data [10]. These problems include the matching of ontologies
integration environment as well as the number of error sources. or schemas, the detection of duplicate entries, the reconciliation
Furthermore, tool domains enable easy adaptations of existing of inconsistencies, and the modeling of complex relations in
integration solutions by allowing the efficient exchange of different data sources [20]. One of the most important and most
similar tools without affecting the existing engineering process. actively studied problems in semantic integration is
establishing semantic correspondences (also called mappings)
The remainder of this paper is structured as the following: between vocabularies of different data sources [8]. The
Section II reports related work regarding common technical
application of ontologies as semantic web technologies for
and semantic integration approaches as well as the MDSC. managing knowledge in specific domains is desirable. Moser et
Section III presents research issues concerning the integration al. [17] introduced the Engineering Knowledge Base (EKB)
in (software+) engineering domains, while section IV describes framework as a semantic web technology approach for
an industrial use case. Section V explains the eMDSC approach addressing challenges originating from data heterogeneity that
applied for (software+) engineering domains. Section VI can be applied for a range of domains, e.g., in the production
presents evaluation results and section VII discusses them. automation domain [17] and also Software Engineering.
Finally, section VIII concludes the paper and presents future
work. Software and Systems integration in Automation
Systems Engineering. Integration of engineering systems is a
II. RELATED WORK challenge as (particularly in the automation industry) typically
a broad range of engineering tools from different vendors are
This section summarizes related work on system integration used to solve specific problems [22]. Tools within one vendor
technologies for technical and semantic integration as well as are sometimes integrated to exchange data, but hardly between
for software and systems integration in automation systems vendors. APIs and exchange formats often do not follow
engineering, and on model-driven system configuration. established (open) standards. Therefore the AutomationML 1
project provides a standardized XML data exchange basis for
A. System Integration Technologies data integration between multi-vendor automation systems
Current developers of software systems use a wide range of engineering tools as foundation systematic information ex-
tools from software vendors, open source communities, and in- change between engineering models. The Medeia 2 project
house developers. Getting these tools to work together to develops an automation component model concept as
support a development process in an engineering environment foundation for knowledge exchange between semantically
remains challenging as there is a wide variety of standards heterogeneous domain-specific engineering models [14]. The
these tools follow [13]. Any integration approach has to results of these projects become essential for engineering teams
address the levels of technical heterogeneity, i.e., how to that have a technically well-integrated environment but need to
connect systems that use different platforms, protocols, etc., so reconcile different semantic approaches in the engineering
they can exchange messages [7, 12]; and semantic team.
heterogeneity, i.e., how to translate the content of the messages
between systems that use different local terminologies for
common concepts in their domain of discourse, so these
systems can understand each other and conduct a meaningful
conversation [1, 11, 17].
Basics of technical integration. Technical integration
follows message-based patterns [12] to connect a series of
technically heterogeneous and distributed systems. The
communication between these systems is in many cases event-
based and sometimes request/response-based. Message-
oriented middleware (MoM) and an “Enterprise Service Bus”
(ESB) [7] provide the infrastructure for physically and
logically connecting technically heterogeneous systems with
technical integration features such as message processing (like
routing, filtering and enriching messages) and a service registry
(a directory of currently available services, their names, Figure 1. Overview EngSB platform [6].
interface and behavior descriptions, and location to bind and
invoke) [2], and thus are the foundation for engineering process Engineering Service Bus (EngSB) platform. Biffl and
services on domain level. To efficiently embed these infra- Schatten proposed a platform called Engineering Service Bus
structure tools an engineering project with resource- (EngSB) which integrates not only different tools and systems
constrained, mobile, and low-cost environments, there are but also different steps in the software development lifecycle
several lightweight open source ESB and related middleware [5, 6]. Figure 1 shows an overview of the EngSB platform. The
products available [21].
Basics of semantic integration. Semantic integration is 1
http://www.automationml.org
defined as the solving of problems resulting from the intent to 2
http://www.medeia.eu
7
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
successful development of modern software-based systems, integration partners the logical solution model is transformed
such as industrial automation systems, depends on the into a technical solution model that represents the specific
cooperation of several engineering disciplines, e.g., integration configuration for the underlying integration
mechanical, electrical and software engineering, so-called network technologies. The configuration specifies routing
(software+) engineering environments. The EngSB addresses tables for efficient communication, backup routes for a fault-
requirements such as the capability to integrate a mix of user- tolerant behavior, transformation instructions to enable data
centered tools and backend systems, mobile work stations that exchange between heterogeneous business services, and
may go offline, and flexible and efficient configuration of new installation instructions for the deployment of middleware
project environments and SE processes. technologies to cope with heterogeneous network technologies.
Tool Domain concept. The EngSB platform introduces the In contrast to MDSC, the eMDSC approach focuses on
concept of tool types that provide interfaces for solving a specifying the proper communication sequence between tool
common problem, independent of the specific tool instance instances based on a description of an engineering process. The
used. This seems possible since different tools, developed to configuration therefore focuses on the efficient integration of
solve the same problem have, more or less, similar interfaces. tool instances rather than on configuring the integration
For example, the source code management (SCM) tools platform regarding efficient routing and effective fault-
Subversion and CVS both provide similar functionality, which tolerance.
allows describing these tools as instances of the SCM tool
domain. Figure 2 illustrates the SCM tool domain and other III. RESEARCH ISSUES
possible domains in the context of the EngSB. We call the
concept of tool types is in this work “tool domains” [5]. This Typical (software+) engineering processes involve a set of
concept allows the EngSB to interact with a tool domain heterogeneous engineering domains and tools, which need to
without knowing which specific tool instances are actually be integrated to allow seamless cooperation and engineering
present. Note that tool domains do not implement tool process support across domain- and tool-boundaries. However,
instances but provide the abstract description of events and the configuration of IT technologies suitable for addressing
services, which have to be provided by concrete connectors of these integration challenges often requires manual and
tool instances to the EngSB. therefore time-consuming and error-prone configuration tasks.
In this paper, we propose an extended model-driven
approach for the automated derivation of integration
technology configurations based on explicit semantic models
of engineering process requirements and engineering tool
capabilities. Based on these semantic models, the proposed
approach is capable of efficiently and effectively deriving
integration technology configurations. In order to investigate
the feasibility and applicability of the proposed extended
model-driven approach, we derive the following research
issues:
RI-1: Efficient derivation of integration technology
configurations. Investigate to what extent an automated
derivation of integration technology configurations is
achievable without the need for manual intervention. Discuss
Figure 2. Tool Domain Concept of the EngSB. the required additional effort needed before executing the
automated derivation, such as the effort for modeling
B. Model-driven System Configuration engineering process requirements and engineering tool
The major goal of the Model Driven Architecture (MDA) capabilities. Evaluate the effort needed for the adaptation of
approach is the separation of system functionality specification existing integration technology configurations in case of
and implementation [11]. The advantages [10] of the MDA changed engineering processes, such as the exchange of
framework are (1) automated generation of results improving existing and the deployment of new engineering tools.
productivity, development duration, and cost; (2) focusing on
RI-2: Effective management of defects in the process of
the creation of conceptual models rather than on logical and
configuring integration technologies. Discuss the advantages
technical details. In contrast to the MDA approach, the Model-
and limitations of the proposed extended model-driven ap-
driven System Configuration (MDSC) [5, 16] automatically
proach regarding the handling of defects in the process of con-
derives integration technology configurations from business
figuring integration technologies. To what extent can the pro-
requirements rather than implementation code. Based on
posed approach transform the explicit engineering process re-
requirement and capability models which represent documents,
quirement models into correct and valid integration technology
integration expert knowledge and estimation/measurements of
configurations without significant sources of defects like
the integration network capabilities [12], a logical solution
manual interaction; better quality measurement and feedback
model which represents the set of suitable integration partners
on intermediate models during configuration derivation?
(i.e. business services) is derived automatically [13]. Based on
described network capability models and the derived
8
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
We discuss the extended model-driven approach based on a typical Java project a Maven 6 or Ant 7 script will guide the CI
standard software engineering process. We show the feasibility process [5].
of the proposed approach and discuss the advantages and
limitations in the context of software(+) engineering. For
XMPP Chat
empirical evaluation we determine the integration effort needed logi.CAD
Server
for each configuration process step to compare the steps in the 1 7 6 10
proposed extended model-driven approach with both the
traditional model-driven approach as well as the manual SMTP Mail
approach. 6 10 Server
Test
Connector
3 9
Processing
IV. USE CASE
Message
Testcase SMTP Issue
This section describes the use case of the standard Tracker
5
Continuous Integration and Test (CI&T) process. We selected Python
Testframework XML-RPC
the CI&T process approach because of the involvement of a set
of various tools (build, automated tests, and deployment) as a Test RTS Issue
representative best-practice approach from the agile software Adapter
Test 4
engineering. Nevertheless, this use case seems appropriate for Adapter 2 8
illustrating the proposed eMDSC approach.
Logger
Build System Send Report
start check in build-start build-failed end
Figure 4. Overview and Sample Tools for CI&I Process.
build-
successful As shown in Figure 4, a typical execution of the CI&T
Process may be performed as follows. (1) an updated version
Run Tests
test-
of a software component is put into the archive using a client
start
test-failed
tool such as logi.CAD 8 . This leads to (2) the execution of the
testing process, i.e., a service call to the test adapter. This test
test- adapter then executes the test, e.g., using the shown Python test
successfull framework. After the tests are finished, the test results are put
Deploy
back into the Engineering Service Bus (EngSB) (3). If the tests
deploy-start
deploy-failed resulted in one or more errors, for each of these errors an issue
(e.g., an email or a ticket) is generated (4) using the issue
adapter of the EngSB. The EngSB is then notified (5) about
deploy-successfull each of these newly created issues and (6) notifies all interested
roles/persons, e.g., by using a chat server. After the errors of
Legend
Start Intermediate End Error
Task
Sequence Flow
the originally checked-in component have been resolved, the
Event Activity Connection component is checked-in again (7), again the tests are executed
(8) and the, now error-free, test results are put back into the
Figure 3. Continuous Integration and Test (CI&T) Process. EngSB (9). Finally, all interested roles are notified (10) about
the successful updated of the software component.
The expected SE process model for the CI&T use case is
represented in Figure 3 using Business Process Modeling V. AUTOMATED DERIVATION OF CONFIGURATIONS
Notation (BPMN) 3 notation. The model consists of a set of The automated derivation of configuration for the
activities for the CI&T process implementation: building the integration of tools across engineering boundaries is described
system, running tests, deploy activities, and finally reporting in Figure 5. The process of configuration derivation consists of
test and deployment results. The CI&T use case shows a key 4 main processing components and 4 QA steps described in the
feature of an iterative software development process: if parts of following.
a system or engineering model get changed, the system has to
be rebuilt and tested in order to identify defects early and to
provide fast feedback on the implementation progress to the
project manager and the owners of the changed system parts. In
modern SE environments this part is done by Continuous
Integration (CI) servers like Continuum 4 or Hudson 5 . For a
6
3
http://www.bpmn.org http://maven.apache.org
7
4
http://continuum.apache.org http://ant.apache.org
5 8
http://hudson-ci.org http://www.logicals.com
9
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
Figure 5: The process of configuration derivation for tool integration in (software+) engineering domains.
Step 1. In the first processing step engineering tool experts Step 5. Once proper tool domains have been found and
from each engineering domain independently model the tested for the given engineering process, appropriate
capabilities of used tool instances (e.g., issue tracker) within engineering tool instances need to be derived by matching tool
their domain as well as tool domain requirements and domain requirements and tool instance capabilities [18, 19].
capabilities. Furthermore, engineering process experts model The process of matching capabilities and requirements is the
the requirements of the engineering process requiring the same as in step 3. The result is a set of tool instances matching
integration of several engineering disciplines. A way of tool domain requirements. Tool domain requirements represent
modeling capabilities and requirements based on ontologies is the capabilities the tool domain promises the engineering
described in [17]. The result of this step is semantically process. In case there are several tool instances matching the
described models. specified requirements a further selection of suitable tool
instances has to be performed. Criteria for final selection may
Step 2. In the second processing step first QA steps are base on non-functional requirements which may also be
deployed to check models automatically for correctness and optional. The result of this processing step, i.e. Technical
syntax validity [3, 4]. The QA step may make use of reasoning Solution Model, is a set of tool instances each matching the
capabilities provided by e.g., protégé to assure certain model requirements of the tool domain they belong to.
constraints (e.g., security properties). In case of errors models
described in step 1 need to be refined. Step 6. The derived tool-instances are tested based on test
scenarios pre-defined in tool domains. Such scenarios check
Step 3. In the third processing step a matching between
proper functionalities of engineering tools and therefore
modeled engineering process requirements and modeled tool consistency between real tool capabilities and tool capability
domain capabilities is performed. The approach of matching models. In case of inconsistencies either bugs in the
capabilities and requirements using ontologies is described in engineering tool have to be fixed or the model updated
[18, 19]. The result of this step is a possible set of integration accordingly. In the latter case the process of configuration
partners where engineering process requirements are matched derivation has to be restarted since initial conditions have
by several tool domain capabilities. In such case engineering changed.
process experts need to perform a manual selection of suitable
tool domains based on characteristics of the derived tool Step 7. In the next processing step the technical solution
domains which were not explicitly used in the matching model, representing selected tool instances and tool domains, is
process or cannot be explicitly modeled, like the confidence of transformed into real configuration parameters. The generated
the experts into the tool instances within the tool domain. The configuration is useable by the underlying integration
outcome of this processing step, i.e. Logical Solution Model, is technology and represents the original engineering process.
an engineering process with well defined and explicitly The described process creates configuration solution for the
referred tool domains capable of satisfying the process’ proposed EngSB. A more general approach taking into account
requirements. technology specific aspects is explained in [16].
Step 4. The following QA step is capable of simulating Step 8. Finally, in the last QA processing step the generated
engineering processes using selected tool domains by means of configuration solution is evaluated by means of consistency
pre-defined test scenarios. The simulation shows whether the and syntax checks.
engineering process is capable of working as originally
intended. In this step tool domains emulate tool instance VI. EVALUATION
functionality as defined in the test scenario. In case of errors or
an invalid engineering process either the selection process has The evaluation of the E-MDSC approach was conducted by
to be restarted and new tool domains found, or tool domain means of a standard software engineering process regarding a
capabilities and engineering process models have to be set of evaluation criteria. We compare the proposed E-MDSC
redefined in more detail. with both the traditional MDSC as well as with a primarily
manual way of configuration. We derived the used evaluation
10
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
criteria together with experts from our industry partner in the Adaptation Effort. In case of adaptation, the MDSC
field of automation systems engineering. The evaluation is variants have proven to be more efficient than the manual
based on two scenarios. The first scenario determines the approach, since once the knowledge has been externalized, it
results based on an integration project from the scratch. The can be reused with little extra effort, while for the manual
second scenario assumes that an initial integration project has approach this knowledge exists implicitly only. In addition,
been accomplished providing a first integration solution, but both MDSC variants report errors or missing information
due to changing business requirements some system immediately due to in-time consistency and completeness
adaptations have to be performed, like the need to exchange of checks based on ontology reasoning. In case of manual
a tool instance. Table 1 summarizes the initial results of our derivation, documents may be changed with the risk that other
evaluation with respect to the derived criteria. related documents are not updated accordingly, resulting in
inconsistent and therefore erroneous knowledge. The eMDSC
Configuration Knowledge. The results of the evaluation variant requires less adaption than the traditional MDSC
show that the main difference between the two MDSC variants variant, since there is an additional separation between tool
and a manual configuration approach is the type of sources instances and tool domains. The tool domain concept of the
used for the derivation of the configuration. On the one hand eMDSC allows more efficient modeling of new or updated
side, human-readable documents or other implicit knowledge is engineering tool instances by providing templates for the core
used by experts to manually generate the configuration. On the functionalities of each used tool domain. Additionally, the
other hand side, this knowledge is externalized in machine- separation into engineering processes, tool domains and tool
understandable models which enable and act as input for an instances allows experts to entirely focus on specific parts of
automated derivation of configuration parameters. the model, rather than taking into account the entire model
Initial Effort. The initial effort (i.e., an integration scenario (e.g., in case of new or updated tool instances, the process of
starting from the scratch) needed for the manual derivation of selecting the appropriate instance is limited to the tool domain
configurations is lower than in case of automated derivation. the tool instanced belong to).
The reason for this is that in case of MDSC, documented
knowledge still needs to be transferred into explicit and
machine-understandable format (e.g., ontologies), while in case
of manual derivation this step is done implicitly by experts.
Furthermore, the eMDSC variant requires slightly more effort
than the traditional MDSC variant, since tool domains need to
be described additionally.
Table 1: Evaluation results of manual, MDSC, and eMDSC approach.
Manual Traditional MDSC eMDSC
Configuration knowledge has to be Configuration knowledge is similar to traditional MDSC
Configuration derived from human-readable externalized in a machine-readable
knowledge documents or implicitly known by ontology by integration experts
integration experts
Initial effort medium high slightly higher
Adaptation high medium low
effort
high low medium - duration is longer due
Duration to additional abstraction (tool
domains need also to be modeled)
Low - Manual checks of documents Medium - Automated ontology High – additionally to MDSC tool
and models needed reasoning allows quickly locating domains allow tool domain-
QA efficiency
inconsistent knowledge in the model specific integration tests of tool
instances
Model High and distributed Medium and centralized Low and centralized
complexity
Low - Exhaustive communication Medium - Semantic models of High – additionally to MDSC,
of engineering tool experts needed engineering process requirements already modeled engineering
Level of
to clarify configuration and engineering tool capabilities processes can be efficiently
automation
with ontology-based reasoning reused because of their explicit
support
allows the automated derivation of modeling in the eMDSC approach
configuration
11
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
Duration. The duration of the manual approach is higher VII. DISCUSSION
due to error-prone mainly manual process steps resulting in This section discusses the proposed eMDSC approach, as
additional efforts to discuss error sources and possible well as the initial results of the evaluation with regard to the
solutions. In case of describing systems, parallel processing is defined research issues.
possible in both approaches. However, the MDSC processing
steps are running mainly automated, while the manual Efficient derivation of integration technology
approach is still human-driven resulting in time consuming and configurations. The explicit and machine-understandable
error-prone processing steps. Therefore, the duration depends knowledge of the eMDSC approach, as well as the explicit
strongly on the automation support. The eMDSC variant distinction between engineering process, engineering tool
requires a slightly longer duration, since the tool domains need domain and engineering tool instance allows a derivation of
to be described before the actual tool instances can be modeled. integration technology configurations with a high level of
automation. This results in an efficient configuration of
QA Efficiency. Since the manual approach focuses on integration solutions for engineering processes across various
manual validity checks, it is therefore more time consuming engineering disciplines. The level of automation and modeling
and error-prone. This also results in the fact that missing methodology enables effective modeling (i.e., modeling of
information is often detected probably only in later process either engineering processes, engineering tool domains or
steps. The MDSC variants use ontology-based reasoning. This engineering tool instances) and supports the reuse of particular
allows performing consistency and completeness checks in- parts of engineering processes for new automation systems
time automatically, resulting in a lower failure rate and in-time engineering projects with minimal adaptation effort. Although
notification of experts about missing/incorrect information. the process of deriving configurations from the described
Furthermore, based on tool domains the eMDSC variant is models is more complex than in the traditional MDSC variant,
capable of additionally executing integration tests to check the cognitive complexity of modeling is lower for the particular
whether all published functionalities of tool domains are experts because of the explicit distinction between engineering
correctly supported by tool instances. The tool domain processes, engineering tool domains and engineering tool
abstraction allows experts to define tests on the engineering instances.
process level, rather than on the engineering tool instance level.
This allows testing the engineering process even before tool Effective management of defects in the process of
instances have been modeled. configuring integration technologies. In contrast to the
manual approach and the traditional MDSC variant, the
Model Complexity. The complexity of the manual eMDSC variant provides a higher level of QA support for the
approach is high because the process requires the cooperation process of integration technology configuration derivation.
of experts from the different engineering disciplines, as well as This higher level of support results from the explicit and
because of heterogeneous and distributed knowledge sources machine-understandable modeling of knowledge sources and
(e.g., documents) which have to be kept consistent all the time. the distinction between engineering processes, engineering tool
The traditional MDSC variant is less complex because the domains and engineering tool instances. These two aspects
knowledge is kept centralized in an explicit format. Each allow automated consistency and completeness checks for all
expert is responsible for maintaining the model of his/her types of used models (i.e., engineering process requirements,
engineering tool instances without the need for cooperation tool domain requirements and capabilities, tool instance
with other experts. However, the links between the different capabilities, logical solution model, and technical solution
engineering disciplines (i.e., the link between tool instances model). Furthermore, the tool domain concept enable experts
belonging to different engineering disciplines) have to be predefining tests on an engineering process level, even before
modeled and kept consistent by designated engineering process suitable engineering tool instances have been modeled or
experts. The complexity of the eMDSC variant is even lower identified. Manual intervention is still necessary, however
because of the distinction between tool domains and tool limited to the selection of engineering tool domains and
instances. This even allows experts of the individual engineering tool instances out of a set of suitable candidates.
engineering disciplines to separately model either engineering Nevertheless, this manual intervention does not introduce
processes, tool domains and tool instances without requiring additional sources of defects, since only valid candidates can
knowledge of the entire engineering discipline. be chosen.
Level of Automation Support. Besides supporting the The evaluation scenarios supported the feasibility of the
engineering tool experts while modeling engineering tool eMDSC approach and provided promising initial results.
instances with consistency and completeness checks, the However, practical issues such as effort and defect rates for
traditional MDSC variant automatically suggests an setting up and using eMDSC within larger-scale need to be
engineering process to be verified by the engineering process explored in settings with industrial experts.
expert. In contrast the manual approach requires exhaustive
communication of engineering tool experts and manual update
of knowledge sources to derive a valid configuration. The VIII. CONCLUSION AND FURTHER WORK
proposed eMDSC variant has a higher level of automation (Software+) engineering, such as the engineering of power
support, since it enables the reuse of already modeled plants, typically involves the cooperation of a set of both
engineering processes, resulting in the appropriate tool technically and semantically heterogeneous engineering tools.
domains to be selected automatically for the new (or adapted) The configuration of technologies enabling the integration of
engineering process. these engineering tools originating from various engineering
12
ACoTA 2010 First International Workshop on Automated Tailoring and Configuration of Applications
disciplines is usually a manual and therefore time-consuming Systems Lifecycle,” Proc. IEEE Industrial Informatics (IndIn)
and error-prone task. Conference, 2009, pp. 576 - 581.
In this paper, we introduced the so-called eMDSC [7] D. Chappell, Enterprise Service Bus, O'Reilly Media, Inc., 2004.
(extended Model-Driven Systems Configuration) approach for [8] A. Doan, N.F. Noy, and A.Y. Halevy, “Introduction to the
the automate derivation of integration technology special issue on semantic integration,” SIGMOD Rec., vol. 33, no. 4,
configurations based on explicit and machine-understandable 2004, pp. 11-13.
models of engineering process requirements, engineering tool [9] P. Duvall, S. Matyas, and A. Glover, Continuous Integration:
domain requirements and capabilities, as well as engineering Improving Software Quality and Reducing Risk, Addison-Wesley,
tool instance capabilities. The eMDSC is based on the Mode- 2007.
Driven Architecture (MDA) paradigm and therefore enables an [10] A. Halevy, “Why your data won't mix,” Queue, vol. 3, no. 8,
efficient, less complex, and less error-prone configuration
2005, pp. 50-58.
derivation process.
[11] G. Hohpe, “Conversation Patterns,” Dagstuhl Workshop Report,
We evaluated the proposed eMDSC approach by using a 2006.
well-known software engineering process, the Continuous [12] G. Hohpe, and B. Woolf, Enterprise Integration Patterns:
Integration & Test (CI&T) process. Major results of the Designing, Building, and Deploying Messaging Solutions, Addison-
evaluation were a) that the proposed approach has proven to be Wesley Longman Publishing Co., Inc., 2003.
efficient and effective, regarding both the effort needed for
[13] IEEE, “IEEE Recommended Practice for CASE Tool
setting up the integration environment as well as the number of
error sources; and b) that tool domains enable easy adaptations Interconnection: Characterization of Interconnections,” IEEE
of existing integration solutions by allowing the efficient Standard 1175.2-2006, 2007, pp. c1-36.
exchange of similar tools without affecting the existing [14] Medeia-Consortium, “Requirements Analysis and Technology
engineering process. Review,” Medeia, 2008.
[15] S.J. Mellor, K. Scott, and D. Weise, MDA distilled: principles of
Future work will include investigation of the eMDSC
approach in large-scale industry projects regarding practical model-driven architecture, Addison-Wesley Professional, 2004.
issues such as effort and defect rates. In addition, the usability [16] R. Mordinyi, T. Moser, E. Kühn, S. Biffl, and A. Mikula,
of the eMDSC approach will be evaluated in settings with “Foundations for a Model-Driven Integration of Business Services in
industrial experts. a Safety-Critical Application Domain,” 35th Euromicro Conference
on Software Engineering and Advanced Applications, IEEE, 2009,
ACKNOWLEDGMENT pp. 267-274.
[17] T. Moser, R. Mordinyi, A. Mikula, and S. Biffl, “Making Expert
This work has been supported by the Christian Doppler
Knowledge Explicit to Facilitate Tool Support for Integrating
Forschungsgesellschaft and the BMWFJ, Austria.
Complex Information Systems in the ATM Domain,” Intl. Conf. on
Complex, Intelligent and Software Intensive Systems (CISIS 2009),
REFERENCES
IEEE, 2009, pp. 90-97.
[18] T. Moser, R. Mordinyi, W.D. Sunindyo, and S. Biffl, “Semantic
[1] L. Aldred, W. van der Aalst, and M. Dumas, “Understanding the Service Matchmaking in the ATM Domain Considering
Challenges in Getting Together: The Semantics of Decoupling in Infrastructure Capability Constraints,” 21st International Conference
Middleware,” BPM Center, Eindhoven, The Netherlands, 2006. on Software Engineering and Knowledge Engineering (SEKE 2009),
[2] G. Alonso, F. Casati, H. Kuno, and V. Machiraju, Web services: 2009, pp. 222-227.
concepts, architectures and applications, Springer Verlag, 2004. [19] T. Moser, K. Schimper, R. Mordinyi, and A. Anjomshoaa,
[3] S. Biffl, R. Mordinyi, T. Moser, and D. Wahyudin, “Ontology- “SAMOA - A Semi-Automated Ontology Alignment Method for
supported quality assurance for component-based systems Systems Integration in Safety-Critical Environments,” Complex,
configuration,” Proceedings of the 6th international Workshop on Intelligent and Software Intensive Systems, 2009. CISIS '09.
Software Quality, ACM, 2008, pp. 59--64. International Conference on, 2009, pp. 724-729.
[4] S. Biffl, R. Mordinyi, and A. Schatten, “A Model-Driven [20] N.F. Noy, A.H. Doan, and A.Y. Halevy, “Semantic Integration,”
Architecture Approach Using Explicit Stakeholder Quality AI Magazine, vol. 26, no. 1, 2005, pp. 7-10.
Requirement Models for Building Dependable Information Systems,” [21] T. Rademakers, and J. Dirksen, “Open-source ESBs in action,”
Software Quality, 2007. WoSQ'07: ICSE Workshops 2007. Fifth Manning Publications, 2008.
International Workshop on, 2007, pp. 6-6. [22] R.M. Rangan, S.M. Rohde, R. Peak, B. Chadha, and P.
[5] S. Biffl, and A. Schatten, “A Platform for Service-Oriented Bliznakov, “Streamlining Product Lifecycle Processes: A Survey of
Integration of Software Engineering Environments,” Eight Product Lifecycle Management Implementations, Directions, and
Conference on New Trends in Software Methodologies, Tools and Challenges,” Journal of Computing and Information Science in
Techniques (SoMeT 09), 2009, pp. 75 - 92. Engineering, vol. 5, 2005, pp. 227-237.
[6] S. Biffl, A. Schatten, and A. Zoitl, “Integration of
Heterogeneous Engineering Environments for the Automation
13