=Paper=
{{Paper
|id=Vol-2019/multi_4
|storemode=property
|title=Applying Multi-level Modeling to Data Integration in Product Line Engineering
|pdfUrl=https://ceur-ws.org/Vol-2019/multi_4.pdf
|volume=Vol-2019
|authors=Damir Nešić,Mattias Nyberg
|dblpUrl=https://dblp.org/rec/conf/models/NesicN17
}}
==Applying Multi-level Modeling to Data Integration in Product Line Engineering==
https://ceur-ws.org/Vol-2019/multi_4.pdf
Applying Multi-Level Modeling to Data Integration
in Product Line Engineering
Damir Nešić Mattias Nyberg
ITM/MMK/MDA ITM/MMK/MDA
Royal Institute of Technology Royal Institute of Technology
Brinellvägen 83, Stockholm, Sweden Brinellvägen 83, Stockholm, Sweden
damirn@kth.se matny@kth.se
Abstract—Developing systems according to the Product Line ficulties. The goal of PLE is simultaneous development of a
Engineering (PLE) paradigm is a process in which different multitude of different product configurations. In other words,
types of engineering artifacts are created with the aim of reusing an additional challenge is to access and manage the data that
them in different configurations of the same system. Ensuring
that different system configurations satisfy various functional allows contextualizing the analysis operations with respect to
and non-functional properties is ensured by analyzing different possible product configurations. Similarly to the artifacts data,
artifacts but because they are maintained by different tools, it is common that the data describing the applicability of an
sometimes even manually, achieving and especially automating artifact to a particular product configuration is scattered across
such analyses is a challenging task. Overcoming this issue can be the lifecycle in different forms [4], [16].
achieved through data integration of existing data which implies
creating an information model that specifies how will the existing Enabling access to the data necessary for designing dif-
data fragments be related, captures relevant domain constraints, ferent analyses can be achieved through data integration [9]
and most importantly captures the fact that some data objects are techniques that can be used to extract and integrate existing
classes in one tool and instances in another. This paper reports artifacts data from individual tools without modifying the
on the experiences from applying the Multi-Level conceptual existing tool landscape or enterprise processes. Next to the
Theory (MLT), to the problem of information modeling for data
integration in the PLE context. Being a Multi-Level Modeling, traditional approaches for data integration [9], [12] suported
powertype-based framework, MLT allows separation of the class by technologies like relational databases [13] and ER or UML
and instance facet of modeled entities while keeping them explicit. information models [13], the idea of Linked Data (LD) [5]
Some of the MLT modeling constructs are particularly useful for has in recent years been applied to the problem of semantic
capturing the refinement levels of the modeled artifacts and for data integration on Internet, but also in different engineering
succinctly capturing constraints like disjointess or completeness
among them. The paper also reports certain aspects of the studied domains, primarily through OSLC standards [25].
case that could not be expressed using MLT. The studied case As in any data integration scenario, the integrated data must
comes from a real data-integration project from the heavy vehicle conform to an information model that in the case of LD
manufacturer, Scania CV AB. can be created using RDFS or OWL languages [24]. There
Index Terms—multi-level modeling, information modeling, are two main aspects of these languages that make their use
product line engineering, linked data
in an enterprise context difficult. Firstly, both languages are
I. I NTRODUCTION based on the Open-World Assumption (OWA) [6] which may
lead to inconclusive results of data analysis. Secondly, in data
Development and evolution of safety-critical Software- integration scenarios, some entities are simultaneously both
Intensive Systems (SIS) is a process involving various engi- classes and objects [18] and this is not expressible in OWL
neering disciplines that produce engineering artifacts across while RDFS can express this fact but without any constraints
the complete SIS lifecycle, e.g. software, hardware, various that prevent creation of inconsistent or contradictory informa-
models, and documents. Performing different analyses across tion models. As an alternative to RDFS and OWL, but also
the lifecyle is essential for sucesfull SIS development and to traditional MOF-compliant modeling frameworks that face
deployment, e.g. is versioning or tracing data consistent, or the same issue with entities being both classes and instance,
more importantly, does SIS conform to prescribed safety or work in [17] has investigated the applicability of the Multi-
reliability standards. Automating such analyses is often a Level Modeling (MLM) paradigm [2], [15] for information
daunting task [21] because individual artifacts are isolated in modeling in the PLE context. More specifically, the Multi-
individual tools that use own principles and technologies for Level conceptual Theory (MLT) [8] was used to interpret PLE-
artifact management. specific concepts inside MLT framework in order to support
Development of highly configurable SIS, also known as modeling of different artifacts and their configuration data with
Product Line Engineering (PLE) [19], brings additional dif- an emphasis on semantically rich and correct models.
This work was funded by the ITEA 14014 ASSUME project with the The present paper reports on the experiences from applying
support from Scania CV AB. the framework presented in [17] on the case of information-
model creation for LD-based data integration in the real are known as presence conditions [20] and they are exempli-
industrial PLE context from the heavy vehicle manufacturer, fied in the middle part of Figure 1. The presence conditions
Scania CV AB. This report contributes to the field of MLM in are arbitrarily complex propositional formulas over the set of
two ways: firstly, the considered case comes from a real, large- features in the variability model. Individual products can be
scale data-integration project for safety-critical SIS develop- derived in the so-called application phase of PLE by using the
ment, thus contributing to the limited knowledge about MLM product configurator, that based on the selection of features,
paradigm applicability in the industrial setting; secondly, the composes appropriate artifacts into individual products.
information model is intended for data integration in a PLE In Scania CV AB, there are several tens of different types
context based on LD principles which a is novel application of artifacts and they are maintained either manually, in hand-
for MLM approaches. written documents, or in multiple in-house and third-party
The rest of the paper is organized as follows. Section II tools. The number of features is around ten thousand while
presents relevant PLE and LD concepts followed by a brief the number of presence conditions is in the order of millions
description of the MLT framework. Section III presents the and they are maintained together with the artifacts in individual
details of the created information model and Section III-B tools.
presents its use in the data integration process. Section IV
discuses the benefits and shortcomings of the applied modeling B. Linked Data
framework and is followed by Section V that surveys related Linked Data refers to the set of principles for structuring and
work. Finally, Section VI concludes the paper. publishing data on Internet. The principles can be summarized
as: each real life entity, digital or physical, is identified by an
II. BACKGROUND
Uniform Resource Identifier (URI) and is called a resource;
This section introduces the PLE and LD concepts followed the result of any operation over resources is always presented
by a brief explanation of the MLT framework and PLE in Resource Description Framework [24] (RDF) format; re-
concepts described in [17]. sources should have links, also URIs, to other resources. The
A. Product Line Engineering main technologies used for publishing LD are the aforemen-
tioned RDF data model, its data modeling extension RDFS
Figure 1 exemplifies the overall idea of PLE. The main Schema [24], and accompanying ontology language called Web
goal of PLE is to engineer artifacts that realize or describe Ontology Language [24] (OWL). Additional standardized LD
a product in a way such that these artifacts can be reused technologies exist [24].
in several different product configurations. Capturing artifact Publishing LD is a process in which the data from existing
reuse is achieved by representing different product config- sources is assigned with URIs so that each data fragment,
urations in terms of configuration options, also known as can be serialized as RDF according to an LD schema [23].
features [19]. For example, an individual truck configuration An LD schema is an information model of the published
could be described as having features: engine, brakes, cab etc. data that is usually expressed in RDFS or OWL language
The features and their mutual dependencies are captured in which define constructs that can be used for LD information
a variability model [19], in the case of features known as modeling. Unlike in traditional data integration where a high
the feature diagram [3], that captures all possible product level modeling language describes the overall data integration
configurations in terms of features. This phase of PLE is schema, in LD ”the data schema is represented with the
known as domain engineering. Left part of Figure 1 shows a data itself” [23], i.e. RDFS and OWL are syntactically the
fragment from a feature diagram. An example of a dependency same as the RDF data model. The RDFS language defines
could be, if the feature strong engine is selected than the the concepts of a class, relation specialization, grouping of
feature small brakes cannot be selected. resources into containers, and some frequently used string-
valued attributes. Interestingly, although not stated explicitly,
RDFS is underpinned by the concept of an unlimited num-
ber of abstraction levels, similar to MLM approaches. The
OWL language defines a richer vocabulary with concepts like
class disjointness, relation cardinality, inverse relations and
others, but it does not support MLM concepts and its RDF
serialization is cumbersome. Furthermore, both RDFS and
OWL assume the open-world assumption [6] (OWA), i.e. any
Fig. 1. Basic idea behind the Product Line Engineering development paradigm information that is not stated is not false. This can lead to
inconclusive analysis operations of the RDF data which is not
Once the variability model is established, features can be desirable in an enterprise.
mapped to one or more artifacts, i.e. to specific versions of There are several benefits from using LD in an enterprise:
engineering artifacts. For example, if a product configuration use of robust, generic web-based principles for data exchange
has a strong engine, then a particular engine control sofware and querying, the possibility to reuse already published LD,
must be used. The mappings between the features and artifacts and incremental data integration because adding new entities
to the information model does not falsify the previous one. The MLT framework differentiates between three primary
The basic idea of LD-based data integration implemented in concepts. These are types that correspond to UML classes,
Scania, is shown in Figure 2. individuals that correspond to UML objects, and attributes
that correspond to UML associations. Types are semantically
interpreted as sets and they are organized into an arbitrary
number of abstraction levels where each level is represented
by an order type. Each type declared in an MLT model
is a specialization of an order type and an instance of the
immediately higher order type or some type specializing the
higher order type. In MLT, order types are called IndividualOT,
representing types whose direct instances are individuals that
cannot be instantiated further, FirstOT whose direct instances
Fig. 2. Illustration of data integration in Scania CV AB based on LD
are types specializing the IndividualOT, SecondOT whose
principles direct instances are specializing the FirstOT and so on. MLT
is a powertype-based MLM framework, i.e. unlike in deep
Figure 2 illustrates that artifacts from existing tools are instantiation [15], the type-facet and the instance-facet of a
published in RDF format and stored in a central database type is explicitly modeled on two adjacent abstraction levels.
that can then be used for designing cross-tool artifact anal- Attributes are used to represent properties of types and
yses. Grey interfaces represent adapters that implement LD instances of types. Semantically, attributes represent binary
principles and publish artifacts data from existing tools in relations; either between a type and a data-type, e.g. string,
RDF format. Currently, data integration in Scania is limited to or between two types declared in the model. This distinction
three tools: software versioning tool, product data management is reflected in the visualization of the MLT models where in
tool and the requirement specification tool. Once stored in the the former case, attributes are visualized similar to attributes
central database, the data can be accessed through a purpose- in UML class diagrams while in the later case the attributes
build LD-based application, i.e. LD tool 1. The evolution are visualized as associations between types. The attributes
of the presented data integration approach is to also enable relating two types declared in the model are referred to as
consuming LD by existing tools, like exemplified on the case relations and MLT separates them into basic and structural
of Tool 4. relations. Structural relations are predefined and they relate
Designing adapters requires an information model that two types whether any arbitrary basic relation relates instances
structures the relevant types of data objects from existing tools of types and must be declared by the modeler.
into a LD representation, potentially enriched by relations Work in [17], interprets and disambiguates basic relations
and attributes that do not exist in source tools. Since the between different artifacts that are product-configuration spe-
information model represent the interface between data models cific (PCS) and that inherently occur in the application phase
in existing tools and RDF data model, the information model of PLE. Each PCS relation is the consequence of previously
must treat two issues. Firstly, in all considered cases, the mentioned presence conditions that specify sets of product
existing tools were not OWA-based while RDF is. Conse- configurations in which a particular artifact can be used.
quently, all the constraints that implicitly exist in non-OWA Furthermore, the approach discusses the structuring of versions
frameworks, e.g. object disjointness or completeness, must be and variants of different types of artifacts and their relations to
explicitly captured and published in LD. Secondly, and more product configurations and corresponding presence conditions.
importantly, data objects which are instances in one tool can The main result of the work is the transformation of presence
be classes in another tool, also noted in [18], and the fact that conditions, that are usually just syntactical annotation, into
certain data objects exhibit this dual nature must be captured. first-class citizens with well-defined semantics. This allows
Since both RDFS and OWL languages do not provide publishing presence conditions as non-string RDF data that
support for expressing the class-instance nature of certain can be analyzed using standard LD technologies.
data objects, i.e. they are not based on MLM principles, and
they assume OWA-based modeling, a different information III. I NFORMATION M ODELING U SING MLT
modeling framework was needed in order to leverage the The model in Figure 3 captures the details about require-
benefits of LD for enterprise data-integration. ments and Electronic Control Units (ECUs), i.e. embedded
computers that control vehicle behavior. The complete model
C. Multi Level Theory for Data Integration in PLE is significantly larger and it includes more artifact types but
This section briefly introduces the Multi-Level conceptual the excerpt in Figure 3 captures all relevant model aspects.
Theory (MLT) concepts togeter with interpretations of PLE Because the information model is used for LD-
concepts that were introduced in [17]. Detailed explanations based data integration, the attributes of types and
of relevant concepts are presented in the next section on the relations between types are reused from various LD
example of the information model created using the MLT vocabularies. The notation prefix:name represents a
framework. shorthand for vocabularyURI/name. For example,
Fig. 3. MLT information model for LD-based data integration
dcterms:description attribute is a shorthand for the tioned types in order to enrich the RDF data with traceability
full URI http://purl.org/dc/terms/description links.
where the attribute description is defined. The prefix scania Instances of type ProductGroup represent product con-
indicates a vocabulary that contains Scania-specific definitions. figurations defined by different presence conditions for the pur-
An underscored attribute is an attribute of the entity labeled pose of describing product configurations in which particular
by it while a non-underscored attribute is an attribute of artifacts can be used. Unlike in Section II-A, where presence
instances of the type that is labeled by it. Figure 3 omits the conditions were propositional formulas, in the information
values of attributes common to all entities, i.e. rdfs:label, model presence conditions are represented by types defined
dcterms:description, and dcterms:created. by these propositional formulas and these types are instances
The rdf:type relation is the RDF equivalent of the in- of the type ProductGroup. For example, type EMS1 v1
stance of relation. It should be noted that all types specializing Product Group has instances that are individual product
type FirstOT are instances of the type SecondOT but the configurations, each containing an individual part that is an
rdf:type relations are omitted in order to reduce clutter. instance of typeEMS1 v1. In other words, each instance of the
type EMS1 v1 Product Group can be represented by a
A. Different Aspects of the Information Model set of features that entail the truthfulness of the presence condi-
The information model in Figure 3 captures several different tion of the type EMS1 v1. The relation dcterms:hasPart
types of information. The three types in the top part of Figure 3 between type ProductGroup and Version and Variant
represent the MLT order types which structure the model into indicates that any type that is an instance of types Version
abstraction levels. Because all entities in the model are either or Variant must be related to a particular product group
direct or indirect, through specialization relations, instances that defines the artifacts inclusion into particular product
of these three types, they model the common attributes of all configurations. In the complete model, even the instances of
entities in the information model. Direct instances of the types the type ScaniaItem can be related to an instance of the
on the IndividualOT abstraction level are the real world type ProductGroup and the relation between them can be
individuals, e.g. :ems1 v1 and :truck. different, e.g. testedBy in the case of test cases.
The information model in Figure 3 also contains some 2) Use of MLT-specific constructs: In Figure 3, types
example RDF data that illustrates the relations between the specializing the order type IndivudalOT capture the infor-
resources published by LD adapters and types in the MLT mation that each instance of the type Requirement specifies
model. All entities with a dashed border are examples of RDF one or more instances of the type Truck and that each
data. Two main aspects captured by the information model are instance of the type Truck has one or more parts which
the PLE aspect that describes all artifacts and their properties are instances of type ECU. Furthermore, a particular type of
from the PLE point of view and the use of MLT constructs requirement is a software requirement and therefore the type
for structuring and capturing the constraints over the published SW Req specializes the type Requirement.
RDF data. Type ECU is partitioned by the type ECUItem, following
1) The PLE Aspect: Types and relations in the left the so-called type-object pattern recognized in [15]. The
part of the information model, i.e. ScaniaConcept, partitions relation, based on the powertype relation, implies
ScaniaItem, Variant, Version, and ProductGroup, that all specializations of the type ECU are pairwise dis-
classify all the artifacts from individual tools into these five joint and are the only instances of the type ECUItem. For
types and also prescribe the mandatory structural and basic example, Scania currently has around 80 different ECUs
relations between them. Instances of type ScaniaConcept that are instances of type ECUItem. Type ECUItem spe-
represent abstract, stable concepts in the domain whose def- cializes the type ScaniaItem whose meaning was pre-
initions change very rarely. Instances of type ScaniaItem viously described. Unlike the type ECU, type SW Req is
represent different logical realizations of concepts. Instances disjointly categorized by the type SW Guarantee. The
of type Variant represent refinements of instances of disjointCategorization relation implies that all in-
type ScaniaItem according to different criteria, e.g. arti- stances of the type SW Guarantee are pairwise disjoint
fact generation, new product variant etc. Instances of type specializations of the the type SW Req but not the only ones.
ScaniaVersion represent particular engineering artifacts For example, in contract-based requirements specification,
that can be used to construct or describe a particular product there are additional requirement types such as SW Assumption
configuration. The only structural relation between these types whose instances also specialize the type SW Req.
is the isSubordinateTo relation which implies that in- Type ECUItem has an attribute called
stances of types related by it must be in the specialization rela- scania:componentCode that is an MLT regularity
tion, i.e. when serialized into RDF, specialization corresponds attribute, denoted by placing the attribute in
to the rdfs:subClassOf relation. Structuring instances of parenthesis preceded by the letter R. The attribute
these four types into specialization hierarchies reflects the pro- scania:componentCode represents a sticker placed on
cess of incremental refinement during the engineering of these physical ECUs and it is used to differentiate between instances
artifacts. Moreover, relations dcterms:isVersionOf and of the type ECUItem in order to connect proper cabling
scania:isVariantOf are prescribed between the men- on the assembly line. According to the MLT framework, a
regularity attribute is an attribute such that each attribute
value is unique to the instance that assigns it the particular
value. In Figure 3, the attribute scania:componentCode
is assigned with a value S8 by the type EMS which is the
Engine Management System and also an ECU. Any other
value of the scania:componentCode attribute must
belong to a different specialization of type ECU.
As mentioned, the aim of the work in [17] was to interpret
PLE concepts within the MLT framework in order to enable
capturing complex and semantically well-defined information
models in PLE. Given the previously described PLE concepts
in the information model, all other types on the FirstOT ab-
straction level whose instances will be published as RDF data
specialize the introduced PLE concepts and leverage the MLT
structural relations in order to define the semantics and capture
the constraints over RDF data. Each instance of the type
ScaniaConcept is at the top of a specialization hierarchy
that captures levels of refinement, in other words levels of vari-
ation, of artifacts in the application phase of PLE. The special-
ization hierarchies are enforced trough isSubordinateTo
relations. For example, type EMS specializes the type ECU.
Similarly, type EMS1 specializes type EMS and type EMS1
v1 specializes type EMS1. Furthermore, all types in the Fig. 4. LD adapter construction based on the MLT information model
specialization hierarchies are disjoint, and in some cases
complete, which is captured through the partitions and
disjointCategorization relations. MLM capabilities adapters using traditional programming languages with two-
of the MLT framework are essential for expressing different level concepts was possible. Each adapter was responsible for
types of information on different abstraction levels. a set of types and their instances, while the types not owned
Regarding basic relations, there are only a few between by any existing tool were published by an additional ”virtual”
types in Figure 3. Besides the dcterms:hasPart basic adapter. The ”virtual” adapter also created the links between
relation which is reused from the Dublin Core Meta Data RDF data created by tool adapters on the RDF level in order to
vocabulary, other basic relations like scania:specifies create the MLM model that conforms to the MLT information
and scania:isVariantOf are defined for the need of this model. The number of types published by the adapters is
particular model. in the order of magnitude of tens of thousands while the
number of individuals is far greater. It should be noted that
B. Using the Information Model these numbers were reached after several increments of the
information model and that initial numbers were much smaller.
This section illustrated the usage of the MLT information However, incremental data integration is one of the strengths
model for data integration according to LD principles. To that of LD and the incremental approach was beneficial for gradual
end, Figure 4 omits most of the details from the model shown adoption and structuring of the domain knowledge.
Figure 3 and only shows the model structure. As mentioned earlier, the first version of LD-based data
As previously discussed, the types in the information model integration and tool adapters is in place for three tools.
represent different engineering artifacts across the product As of now, the primary usage of the integrated data is
lifecycle. According to Section II-B and Figure 2, in order for different stakeholders to visualize, navigate, and explore
to transform the artifact data into RDF data, it is necessary to relations between different types of artifacts using an in-house
implement adapters that will transform the artifact data from developed tool called Search & Browse. Part of the future work
the internal tool formats into RDF format. is to define and implement standardized analysis operations
In Figure 4, black boxes indicate that a particular tool over the data that target different use cases like consistency
maintains instances of the indicated classes. The entities with checking or change impact analysis. Also, in order to automate
a dashed border, either types or individuals, are instances of adapter development and data validation, future versions of
the types owned by a tool and they are published as RDF data the information model shall be created using a model-driven
by tool adapters. The need for an MLM based approach is approach based on the Lyo Toolchain tool [10].
illustrated by types owned by Tool 1 which are instances of
types owned by Tool 2. Because MLT forces strict stratification IV. D ISCUSSION
of modeled entities into abstraction levels with instantiation, The case introduced in the present paper indicates that
i.e. rdf:type, relation between them, the implementation of creating information models for data integration requires the
use of an MLM framework because instances from one tool V. R ELATED W ORK
can be types in another tool. The particular MLM framework Reports about applications of Multi-Level Modeling ap-
that was used in the present paper, the MLT framework, offers proaches on real cases are still rare, particularly in areas other
many benefits but there are also some shortcomings. than model-based software development including software
architectures and domain-specific languages.
Most importantly, MLT defines the partitions, disjoint cat-
In [11], standardized IT management frameworks for enter-
egorization, and subordination relations which were essential
prise infrastructure modeling, evolution and decision making
for capturing the item-variant-version pattern. Furthermore,
are surveyed and common chanllenges and prospects for
regularity attributes are a succinct way to express the con-
improvement are identified. Following the survey, multi-level
straint that different attribute values lead to the creation of new
modeling approach was used to construct a language that
types. The fact that MLT is a powertype-based MLM frame-
tackles identified challenges. The report in [22] also looks at
work means that for each partitions relation, there is an
enterprise architecture modeling using a modeling language
additional type defined [15] compared to deep instantiation
developed during industrial projects. The language Txture uses
approaches. However, because each type in the information
both multi-level modeling concepts and traditional two-level
model represents a data fragment, it is desirable to explicitly
modeling concepts and the authors claim that a language with
define all of them. Moreover, the separation into two types,
enough expressiveness for capturing complex domains must
provides a type where instance-facet attributes can be declared
support concepts both paradigms.
and a type where type-facet attributes can be declared which
Work in [1] tackles the problem of mapping domain specific
was helpful in explaining the MLM concepts to employees in
concepts to concepts from automotive safety standards by
Scania.
introducing a mapping layer which leads to a multi-level
Regarding the practical aspects of using the MLT frame- model. In the absence of an adequate MLM framework for the
work, the absence of tool support was the biggest challenge. presented problem, the paper introduces the DeepML language
Although a MLT-UML profile was suggested in [7], it was not that combines constructs from several MLM frameworks. The
implemented and MLT models had to be created and debugged approach in [14] is motivated by the problem of interop-
manually. A part of the future work with the Lyo toolchain is erability between information systems, a similar problem to
about extending its graphical modeling tool based on results the one discussed in the present paper. The authors propose
from [17]. additional disambiguation of instantiation and specialization
relations in order to facilitate tool interoperability but they do
As a purely powertype MLM approach, MLT does not not apply their approach to a realistic case study. However, the
support expressing some information. There are two exam- introduced extensions are formally captured and then evaluated
ples where deep instantiation and dual-deep instantiation against a set of criteria such as modularity, level stratification
are needed. First example concerns the componentCode and etc.
regularity attribute. As mentioned earlier, componentCode
VI. C ONCLUSIONS
is a sticker on physical individuals which are instances of
version artifacts, e.g. EMS1 v1, and therefore it should be Constant increase of product complexity in PLE devel-
considered as the attribute of individuals. However, because opment of SIS requires seamless access to well-structured
types like EMS1 v1 are added by the adapters, i.e. they are artifacts data with the purpose of making decisions or ensuring
not present in the information model, the componentCode different properties of developed SIS. One way to enable such
attribute must be modeled as an attribute of instances of the operations is data integration of existing artifacts data into a
ECUItem type on the FirstOT level. If MLT framework unified representation. This paper has reported on the expe-
had supported deep instantiation, the componentCode attribute riences from applying an MLM framework, specifically the
could be modeled as an attribute of type ECUItem with MLT framework, for the creation of an information model for
potency=2 and then all specializations of the type EMS would LD-based data integration used in a real industrial case from
inherit that attribute thus yielding the desired result. the heavy vehicle manufacturer, Scania CV. MLM capabilities
of MLT enabled capturing several aspects of the considered
The second example concerns the use case for dual-deep data while the relations partitioning, disjoint categorization
instantiation. For example, individual ems1 v1 could have and subordination have enabled expressing constraints and
an attribute scania:assembledBy whose value is of type structuring published LD with well-defined semantics. Being a
ScaniaEmployee. Simultaneously, any type on any abstrac- powertype-based MLM approach, MLT forces clear separation
tion level has an attribute dcterms:created whose value of modeled entities into abstraction levels which has facil-
should also be of type ScaniaEmployee. In this scenario, itated adapter implementation using traditional programming
two different attributes on two different abstraction levels are languages. Although MLT provides formal definitions of all of
related to the same type which is basic idea of dual-deep its constructs, the lack of tool support prevented using them
instantiation. Currently, the information model does not treat in an automated fashion. As an integration technology, LD
this issue in any way because the type ScaniaEmployee is has proven useful primarily in two aspects. Firstly, the ability
not modeled. to reuse definitions of attributes like creator, description, or
hasPart relation were a significant time-saver. Secondly, the
possibility to incrementally integrate data allowed gradual
adoption and structuring of domain knowledge. Future work is
targeted towards providing tool support for model-driven LD
adapter generation based on information models created using
MLT framework.
R EFERENCES
[1] Al-Hilank, S., Jung, M., Kips, D., Husemann, D., Philippsen, M.: Using
multi level-modeling techniques for managing mapping information. In:
MULTI@MoDELS (2014)
[2] Atkinson, C., Kühne, T.: Reducing accidental complexity in domain
models. Software & Systems Modeling (2008)
[3] Batory, D.: Feature models, grammars, and propositional formulas. In:
SPLC ’05 (2005)
[4] Berger, T., Rublack, R., Nair, D., Atlee, J.M., Becker, M., Czarnecki, K.,
Wasowski, A.: A survey of variability modeling in industrial practice.
In: VaMoS ’13 (2013)
[5] Bizer, C., Heat, T., Berners-Lee, T.: Linked Data: The Story so Far. IGI
Global (2011)
[6] Brachman, R., Levesque, H.: Knowledge Representation and Reasoning.
Morgan Kaufmann Publishers Inc. (2004)
[7] Carvalho, V.A., Almeida, J.P.A., Guizzardi, G.: Using a well-founded
multi-level theory to support the analysis and representation of the
powertype pattern in conceptual modeling. In: CAISE ’16 (2016)
[8] Carvalho, V.A., Almeida, J.P.A.: Toward a well-founded theory for
multi-level conceptual modeling. Software & Systems Modeling (2016)
[9] Doan, A., Halevy, A., Ives, Z.: Principles of Data Integration. Morgan
Kaufmann Publishers Inc., San Francisco, CA, USA, 1st edn. (2012)
[10] El-Khoury, J., Gurdur, D., Nyberg, M.: A model-driven engineering
approach to software tool interoperability based on linked data (2016)
[11] Frank, U.: Designing models and systems to support IT management:
A case for multilevel modeling. In: MULTI@MoDELS (2016)
[12] Halevy, A., Rajaraman, A., Ordille, J.: Data integration: The teenage
years. VLDB ’06 (2006)
[13] Halpin, T., Morgan, T.: Information Modeling and Relational Databases.
Morgan Kaufmann Publishers Inc. (2008)
[14] Jordan, A., Mayer, W., Stumptner, M.: Multilevel modelling for inter-
operability. In: MULTI@MoDELS (2014)
[15] Lara, J.D., Guerra, E., Cuadrado, J.S.: When and how to use multilevel
modelling. ACM Transactions on Software Engineering Methodology
(2014)
[16] Nešić, D., Nyberg, M.: Multi-view modeling and automated analysis of
product line variability in systems engineering. In: SPLC ’16 (2016)
[17] Nešić, D., Nyberg, M.: Modeling product-line legacy assets using multi-
level theory. In: REVE@SPLC ’17. To appear. (2017)
[18] Neumayr, B., Jeusfeld, M.A., Schrefl, M., Schütz, C.: Dual Deep
Instantiation and Its ConceptBase Implementation (2014)
[19] Pohl, K., Böckle, G., van der Linden, F.J.: Software Product Line
Engineering. Foundations, Principles, and Techniques. Springer-Verlag
Berlin Heidelberg (2005)
[20] v. Rhein, A., Grebhahn, A., Apel, S., Siegmund, N., Beyer, D., Berger,
T.: Presence-condition simplification in highly configurable systems.
ICSE ’37 (2015)
[21] Sudarsan, R., Fenves, S., Sriram, R., Wang, F.: A product information
modeling framework for product lifecycle management. Computer-
Aided Design (2005)
[22] Trojer, T., Farwick, M., Haeusler, M.: Modeling techniques for en-
terprise architecture documentation: experiences from practice. In:
MULTI@MoDELS (2014)
[23] W3C Consortium: Best practices for publishing linked data (2017),
https://www.w3.org/TR/ld-bp
[24] W3C Consortium: Semantic web (2017),
https://www.w3.org/standards/semanticweb
[25] OASIS consortium: Open services for lifecycle colaboration (2017),
http://open-services.net