=Paper=
{{Paper
|id=Vol-1286/paper11
|storemode=property
|title=Using multi level-modeling techniques for managing mapping information
|pdfUrl=https://ceur-ws.org/Vol-1286/p11.pdf
|volume=Vol-1286
|dblpUrl=https://dblp.org/rec/conf/models/Al-HilankJKHP14
}}
==Using multi level-modeling techniques for managing mapping information==
https://ceur-ws.org/Vol-1286/p11.pdf
Using Multi Level-Modeling Techniques for
Managing Mapping Information
Samir Al-Hilank2 , Martin Jung1,2 ,
Detlef Kips , Dirk Husemann2 , and Michael Philippsen1
1,2
1
Friedrich-Alexander University Erlangen-Nürnberg (FAU),
Programming Systems Group, Martensstr. 3, 91058 Erlangen, Germany
philippsen@cs.fau.de
2
develop group Basys GmbH, Am Weichselgarten 4, 91058 Erlangen, Germany
alhilank|husemann|jung|kips@develop-group.de
Abstract. Traditional modeling approaches support a limited set of
instantiation levels (typically one for classes and another adjacent one
for objects). Multi-level modeling approaches on the other hand have no
such limit to the number of levels. As a consequence, an arbitrary number
of levels may be used to define models, and the distinction between class
and instance is redefined.
The paper summarizes the experience gained from applying multi-level
modeling techniques to a real application from the domain of develop-
ment process improvement (DPI). The underlying case study has been
conducted in cooperation with a large automotive supplier. We discuss
the pros and cons of using multi-level modeling techniques and propose
areas that we think would benefit from further research.
1 Introduction
Although problem domains often have a natural structure that spans more than
two logical levels, traditional modeling languages like, for example, MOF [20] or
UML [21] are limited to only two layers. As a consequence, using UML or MOF
to capture such problem domains leads to squeezing several logical levels into
two. This in turn causes accidental complexity [12] that does not originate from
the problem domain itself. Consequently, concepts like powertypes [17], potency
[12], dual classification [11], etc. have been developed to allow for the definition
of an arbitrary set of classification levels.
This paper reports on experience with defining and using deep models in an
industrial case study. It is organized as follows: Sec. 2 presents the case study’s
problem statement. Sec. 3 describes our experiences with using deep modeling
techniques. Sec. 4 discusses related work. We conclude with a list of research
areas that could improve the applicability of multi-level modeling.
2 Problem Statement
Most companies working in the automotive domain need to use development pro-
cesses (DP) that comply with requirements defined by quality standards (QS)
103
like CMMI [14] or ISO 26262 [18]. Company specific standards or laws enforced
by governments may pose additional requirements. Moreover, those companies
often have to provide evidence that their DP complies with all requirements, for
example, due to economic reasons (precondition of contracts) or legal consider-
ations (product liability). Hence, there is a strong need to collect this evidence
information in a systematic way.
The basic approach is straightforward: Just collect and later analyze map-
pings between QS requirements and elements of the DPs. Here is a typical ex-
ample mapping that we illustrate at the bottom of Fig. 1:
– Integrate SW Component is an item (e.g., a Task) defined by the company’s
DP.
– SW Integration and Testing is a QS requirement (e.g., a description of a
phase) that has to be implemented by elements of the company’s DP.
– Mapping connects both elements with the following semantics: The require-
ment SW Integration and Testing is fulfilled by the element Integrate
SW Components.
QS Domain Mapping Domain DP Domain
QSElement QSDPMapping DPElement Kernel Layer
Mapping Type
Phase PhaseTaskMapping Task
Layer
SW Integration and Integrate SW
Mapping Mapping Layer
Testing Component
Fig. 1. Organization by responsibility (horizontal) and domain (vertical).
Note that these are items from three different domains. First, items from
the DP domain need to be taken into account. There is no commonly used
standard approach for describing DPs, but typical items found in DPs are Task,
Step, Function or Template. In our case study, we use ARIS [6] to describe the
company’s DP. Second, we capture QS requirements in the QS domain. In
our case, the company’s process has to comply with three QSs simultaneously
(CMMI, Automotive SPICE [13] and ISO 26262). Last, the mapping domain
collects mappings between items of the DP and QS domain.
Fig. 1 also structures the problem into three orthogonal layers:
– The Mapping Layer collects mapping information.
– The Mapping Type Layer defines valid mappings.
– The Kernel Layer provides the foundation with respect to the terminology
used within the DP, QS, and mapping domain.
The natural structure of the problem domain in Fig. 1 does not fit into two
levels. Instead, Fig. 1 shows a scenario that is well suited for deep modeling
104
techniques. Below we present such a deep model that we have implemented in
an industrial application.
3 The Case Study
3.1 DeepML in a Nutshell
None of the research papers on concepts and features of deep modeling offers
the flexibility and freedom needed for our case study (for details see Sec. 4). In
general, existing approaches lack
– freedom to combine concepts from several approaches. There is no
common set of deep modeling concepts, that would allow to cherry-pick
suitable concepts from various approaches.
– freedom to omit concepts. Known approaches do not allow to omit con-
cepts that are unnecessary for our solution.
– freedom to experiment with new ideas. None of the approaches we
know of provides means to explore new ideas or to add new concepts.
As we needed this degree of freedom for our case study, we designed the
DeepML language and infrastructure. DeepML supports the usual modeling
concepts like inheritance, primitive data types, and enumerations. Furthermore,
DeepML builds on the idea of dual classification and potency that is unified
in the ontological classification architecture (OCA) [8]. OCA distinguishes be-
tween two kinds of instantiation relationships: The linguistic instantiation
(lio) is a relation between elements of the model (that describes the core lan-
guage capabilities, e.g., attributes, references, etc.) and elements of the problem
domain. Linguistic instantiations therefore are not domain specific. Fig. 2 gives
examples. On the other hand, ontological instantiation (oio) relations capture
domain specific aspects. In Fig. 2, for example, Book is an ontological instance
of ProductType.
Linguistic
Model
Clabject
Underlined means
«lio» Dual classification «lio» potency zero «lio»
Ontological
Model
ProductType @2 «oio» Book /@1 «oio» LordOfTheRings /@0
ProductType
taxRate @1 taxRate = 7 /@0 price = 27.95 /@0
price @2 price /@1
Potency "derived" by ontological
Potency declaration Value (or slot)
instantiation (indicated by slash)
Fig. 2. DeepML in a Nutshell – Dual Classification.
105
Both elements (Book, ProductType) have a property called potency which
is a positive integer value. Every ontological instantiation step decrements the
potency by one. Model elements with a potency zero cannot be further instan-
tiated. Consequently, the element Book has both an instance and a class facet.
This is commonly called a clabject [10]. DeepML clabjects ”derive” the po-
tency in the same way as attributes. To express this inheritance, we use the ”/”
character as in Book/@1.
Due to space restrictions, instead of describing DeepML’s language capabil-
ities in full detail, the next sections highlight some of its key features. We also
compare them to other deep modeling languages in Sec. 4.
3.2 Sample Mapping Scenario from the Case Study
As outlined in Sec. 2, collecting mappings is always done with a specific goal in
mind. For example, in our case study, the DP needs to fulfil the requirements
of a new and emerging QS (ISO 26262). However, the company’s DP already
fulfils a subset of the requirements as defined by the QS CMMI. One strategy
to minimize the effort of gap analysis in such a situation is to map elements
from both QSs onto each other. We consider those ISO 26262 requirements that
we can map to CMMI requirements as already covered by the company’s DP.
ISO26262 requirements that cannot be mapped to CMMI necessitate further
investigation.
The following subsections present parts of our Process Improvement and
Quality Standard Harmonization Model (PIQSH-M), a deep model that under-
lies our mapping management application for the QS-DP-Mapping (Sec. 2) and
QS-QS-Mapping (see below) scenario.
3.3 Ontological Containment
QSs are usually published as large text documents. These documents are typ-
ically organized with a specific ordering structure in mind. For example, each
chapter at a specific level (e.g., ”9.5.6 SW Integration and Testing”) represents
a phase. On its left side, Fig. 3 shows how to model the following clabjects for
capturing QSs in DeepML:
– QSDElement (Quality Standard Domain Element): Base clabject of
all elements that belong to the QS domain.
– QSTM (Quality Standard Type Model): Instances of this clabject are
top level elements of models used for capturing the structure of one QS
(e.g. entities, relations, etc.). An example is the clabject ISO26262/@1.
– QSElement: Instances of QSElements represent non top level elements of
QSs (e.g., clabject Phase/@1).
To capture the relationships between elements of one QS, we introduce ref-
erences. In DeepML, relationships among clabjects are expressed by references
that are always unidirectional and owned by exactly one clabject. They are, thus,
106
QS Domain Mapping Domain
{ refAllowed=True; containmentAllowed=False }
QS-Domain Mapping Domain
* intraQSRelation @2 MTM @2
QSDElement@2
«oio»
ownedQSElements @1 * UnidirectedMap *
QSTM@2 QSElement@2
* pingTD @2
mappedQSElements @2 ownedMTDs
@1
«oio» ISO26262CMMI
ownedPhases:intraQSRelation /@1 /@1
*
* PhasePAMapping
ISO26262:QSTM /@1 Phase /@1
/@1 :ownedMTDs
phases:mappedQSElements
:ownedQSElements /@0
«oio» «oio» /@1
SW Integration & * «oio»
:ISO26262 /@0
Testing /@0 :phases
:ownedPhases /@0
ownedPAs:intraQSRelation /@1 :PhasePAMapping
/@0
*
*
CMMI:QSTM /@1 ProcessArea /@1
:ownedQSElements /@0 processAreas:mappedQSElements /@1
«oio» «oio»
*
:CMMI /@0 :Integration /@0
:ownedPAs /@0 processAreas /@0
Elements at kernel layer Elements at mapping type layer Elements at mapping layer
Fig. 3. An extract of the PIQSH-model.
more similar to references in MOF than to association classes in UML. Refer-
ences may participate in classification hierarchies in the same way as clabjects
do. Consequently, the potency of a reference is either directly specified or derived
from a classifying reference. For example, the reference intraQSRelation@2 clas-
sifies the set of relationships (not values) between QS elements. Thus, instances
of this reference, for example ownedPhases:intraQSRelation/@1, express that
ISO 26262 is made up of a set of phases. A slot concept is used to store values and
in DeepML underlined text is used as notation. For example, :ownedPhases/@0
is a slot, and SW Integration and Testing/@0 is owned by :ISO26262/@0.
A similar model structure captures mapping information: Instances of the
clabject Mapping Type Model (MTM) are top level containers of models for speci-
fying meaningful mappings. An example for such a mapping is PhasePAMapping/@1
which links Phases (from ISO26262) and ProcessAreas (from CMMI). Concrete
mappings can then be captured on the mapping layer (e.g., :PhasePAMapping/@0).
Although, references optionally may be containment references, most deep
language specifications ignore this. Instead, DeepML adds an ontological con-
tainment concept because: Firstly, a containment is a common constraint that
should be natively supported. Secondly, and more importantly, a containment
hierarchy reflects the hierarchical structure that the domain expert had in mind.
Finally, persistance layers typically use containments to find the one (or no)
resource to store elements into. An example for a containment reference is
107
ownedQSElements@1 (see Fig. 3). Given its definition, QSElements are part of
exactly one QSTM.
3.4 Domain Stacks and Model Organization
One of the key requirements of the PIQSH-M is to support reuse. For example,
other companies or organizational units may need to comply with a different set
of QSs. The basic idea for addressing this problem is to develop a library of com-
monly used QSs that grows over time. Missing QSs can simply be transformed
into deep models and added to that library for later reuse.
When managing such a library, it is important to define what kinds of models
are part of it. Restricting and managing dependencies between models is equally
important. We decided to use the matrix-like organization shown in Fig. 1 as a
guideline because it separates model content with respect to the domain (QS,
Mapping, DP) and to the role (kernel, mapping, and mapping type definition
layer). For example, direct and indirect instances of QSTMs@2 (e.g., CMMI/@1 and
:CMMI/@0, respectively) are models managed by the library.
As explained above, restrictions should apply to the set of permissible re-
lations between models from different domains and layers. DeepML allows the
definition of references without a classifying reference at any level. For exam-
ple, we could define a direct reference between Phase and ProcessArea without
defining the corresponding mapping type. However, such a direct reference would
lead to a direct dependency between ISO26262/@1 and CMMI/@1 — thus break-
ing the intentional decoupling introduced by the mapping layer and leading to
a pollution of model content.
To prevent pollution of this kind, the concept of domain stacks is added to
DeepML, formalizing the separation into domains as illustrated in Fig. 1. Every
clabject may be part of at most one domain stack. For example, all elements on
the left side of Fig. 3 are members of the QS domain stack. References between
elements within the same domain stack are allowed. References to elements of
other domain stacks or to domainless elements are not allowed by default.
The situation is slightly different for members of the DP domain stack (right
side of Fig. 3): They must refer to elements from other domain stacks, but must
not contain them. To express these rules, a relationship between domain stacks
is introduced that specifies which kind of references are allowed. An example is
shown at the top of Fig. 3.
To summarize, by using top level containers, ontological containment and
domain stacks, a clean separation of content is realized that spans multiple levels.
However, a capability for managing mapping projects is still missing.
3.5 A Deep Model for DPI Project Management
With a deep model for organizing items of the QS and DP domains at hand,
the practitioner also needs tool support to actually use this model for creating
and managing mapping information. Let us now demonstrate how the DeepML
108
model serves as a foundation of an application called PIQSH Support Center
(PIQSH-SC) that covers the three main use cases of managing projects in the
DPI domain:
(1) Define Quality Standards: Capture the structure and content of QSs.
(2) Define Mapping Type Models: Define the set of meaningful mappings
between certain combinations of QSs (or QSs and DPs).
(3) Collect Mapping Information: Collect mapping information within a
specific context (e.g. between QSs or between QSs and DPs).
Use case (1) is straightforward. As it is only concerned with creating models,
we do not discuss it any further. Use case (2) involves at least three models,
for example, two QSTMs (e.g., CMMI/@1 and ISO26262/@1) and one MTM (e.g.,
ISO26262CMMI/@1) as shown in Fig. 3. The inter-model relationships can also
be captured in DeepML as the PIQSH Project Management Model (PIQSH-
PMM) and the clabject Model Type Definition Project (MTDProject). With
this clabject, we string together all models in terms of an import relationship.
The resulting model is shown on the left side of Fig. 4.
:CMMI /@0 :MappingProject /@0
:impQSMs d2@0 QSTM@2
«oio»
impQSTMs @1 * «oio»
QSTM@2
* impQSMs d2@1
ISO26262 /@1
impDPTMs @1 *
MTDProject MappingProject
DPTM@2
@1 * @1 «oio»
impDPs d2@1
mtms @1
MTM@2 *
:ISO26262 /@0
* mappingModels d2@1
mappingTypes @1 *
Fig. 4. Deep Model for Project Organization.
Use case (3) requires capturing mapping information. Within use case (2),
MTDProject and the corresponding references had equal potency values, and
both were reduced within an ontological instantiation step. In contrast, in use
case (3) a project needs to store references to models on the mapping layer;
that is, to instances of instances of QSTMs or MTMSs. Since references of this kind
cannot be expressed with DeepML, we enhance references by the concept of
distance.
The distance between two clabjects A and B is defined as the number of
instantiation relationships that need to be traversed in order to reach A when
starting from B. As an example, the distance between QSTM@2 and ISO26262/@0
is 2 (see right side of Fig. 4). The rule for assigning values to a reference depends
on the distance: The distance between the reference’s target type and the value
to be assigned must be equal to the distance of the reference. Fig. 4 shows the
clabject MappingProject and the notation (d@) that is
used to specify both distance and potency. As a consequence, the semantics of
the reference impQSMs d2@1 in the context of a concrete mapping management
109
project is to store instances of instances of QSTMs. There is an example for
reference values (i.e., instances of MappingProject) shown at the top of Fig. 4.
3.6 DeepML’s Framework Architecture
Fig. 5 gives an architectural overview of our framework. DeepMLCore is the core
language implemented with the Eclipse Modeling Framework (EMF) [2]. On top
of it there is a set of supporting libraries: The DeepML Editor is a generic compo-
nent that provides views and editors for visualizing and modifying DeepML mod-
els from both perspectives, the ontological and the linguistic one. The Epsilon
Adapter is a bridge for using the language family (M2M, M2T, etc.) provided
by the Epsilon framework [3]. The Epsilon Adapter is also used to realize a
bridge to BIRT (Business Intelligence and Reporting Tool) [1]. The PIQSH-SC
in turn uses BIRT for generating reports (e.g., gap analysis).
PIQSH-SC
DeepML Code BIRT Adapter
DeepML
Generation
Editor Epsilon BIRT
Facilities
Adapter
DeepML Core
EMF
Fig. 5. DeepML’s Architecture and Framework.
4 Related Work
The need to define efficient strategies for managing mappings in scenarios as
outlined in Sec. 2 has been identified before, for example, in [16] and [22]. How-
ever, this paper focuses on experience made by using deep modeling techniques.
So we will concentrate on related work in that area of research.
Melanee [4] provides a deep modeling framework with graphical syntax and
editors. It is built on top of EMF and also incorporates ideas from the domain
of ontologies. It therefore supports an additional so-called exploratory mode [9].
In exploratory mode, a reasoning engine establishes ontological instantiation
relationships. However, our goal was to use a deep modeling language with a
minimal set of language constructs that is optimized for building models in
a constructive way, that is, by using explicit instantiation relationships. Also,
Melanee does not define a concept similar to domain stacks for managing model
partitioning. There is also no concept available in Melanee for realizing layer
spanning references as defined in Sec. 3. However, some framework capabilities
110
like for example emendation support [7] are neither provided by DeepML nor by
any other deep modeling framework we are aware of.
Another deep modeling language is MetaDepth [5]. MetaDepth provides a
convenient textual syntax for creating deep models and has some unique lan-
guage features, for example, the *-potency. A clabject with a star potency has
an unlimited potency. With each instantiation step, that potency may either
remain unlimited or a concrete potency value may be assigned. Yet, MetaDepth
lacks support for ontological containment and domain stacks that greatly sim-
plified the architecture needed for our case study 3.
5 Conclusion and Future Work
In this paper we report on our experience gained by applying deep modeling
techniques to a real life industrial use case. The corresponding application has
been successfully used by our industrial partner for approximately one year, and
we are currently discussing further extensions. The underlying deep model is very
well suited for this kind of problem: The concept of layers and stacks provides
a clean separation of concerns, and the model is very flexible. We continue to
develop both, the application and the DeepML framework, mainly focussing on
the following topics:
First, one of the main problems with traditional programming languages,
such as Java, is, that they only support two levels of instantiation (class and
object). We are currently investigating solutions to this problem either by using
appropriate patterns to emulate multiple levels or by enhancing the program-
ming language (like e.g. done in DeepJava [19]). Second, a lot of enhancements
are planned with respect to the infrastructure. For example, diagram based ed-
itors, additional code generators for automatically generating code to ease the
development of user interfaces, and so forth. Third, we are looking for other
domains that might benefit from using deep modeling techniques. A promising
candidate is the domain of variant management in software development and
systems engineering. Fourth, we intend to explore the combination of PIQSH-
M with executable process models such as eSPEM [15]. One possibility is to
introduce a process execution layer below the mapping layer, but limited to the
DP domain. This leads to a four-level model architecture.
To summarize, we think multi-level modeling techniques are very well suited
for the kinds of problem outlined in Sec. 2. However, there remains a lot of
research to be done. For example, we did not find any solutions for handling
model migration in a multi-level aware way. Yet, in our view, the major stumbling
block is the lack of an agreed and publicly available specification of the core
concepts and terminology of multi-level modeling (a standard deep meta model).
Finally, we hope our experience report encourages other people to use deep
modeling techniques — at least in areas similar to the one outlined in Sec. 2.
References
1. BIRT. http://www.eclipse.org/birt/ (July 2014)
111
2. Eclipse Modeling Framework. http://www.eclipse.org/modeling/emf/ (July 2014)
3. Epsilon. http://www.eclipse.org/epsilon/ (July 2014)
4. Melanee. http://melanee.org/ (July 2014)
5. MetaDepth. http://astreo.ii.uam.es/ jlara/metaDepth/ (July 2014)
6. software AG: ARIS. http://www.softwareag.com/aris (July 2014)
7. Atkinson, C., Gerbig, R., Kennel, B.: On-the-Fly Emendation of Multi-Level Mod-
els. In: Modelling Foundations and Applications. LNCS, vol. 7349, pp. 194–209.
Springer (2012)
8. Atkinson, C., Kennel, B., Go, B.: The Level-Agnostic Modeling Language. In:
Software Language Engineering, LNCS, vol. 6563, pp. 266–275. Springer (2011)
9. Atkinson, C., Kennel, B., Go, B.: Supporting Constructive and Exploratory Modes
of Modeling in Multi-Level Ontologies. 7th Intl. Workshop on Semantic Web En-
abled Softw. Eng. (2011)
10. Atkinson, C., Kühne, T.: Rearchitecting the UML Infrastructure. ACM Trans.
Model. Comput. Simul. 12(4), 290–321 (Oct 2002)
11. Atkinson, C., Kühne, T.: Model-Driven Development: A Metamodeling Founda-
tion. IEEE Software 20(5), 36–41 (2003)
12. Atkinson, C., Kühne, T.: Reducing accidental complexity in domain models. Soft-
ware and System Modeling 7(3), 345–359 (2008)
13. Automotive SIG: Automotive SPICE Process Reference Model, Ver. 4.5 (May
2010)
14. CMMI Product Team: CMMI for Development, Ver. 1.3. Tech. Rep. CMU/SEI-
2010-TR-033, Carnegie Mellon Univ. – Software Eng. Inst. (Nov 2010)
15. Ellner, R., Al-Hilank, S., Drexler, J., Jung, M., Kips, D., Philippsen, M.: A FUML-
Based Distributed Execution Machine for Enacting software process models. In:
ECMFA. LNCS, vol. 6698, pp. 19–34 (2011)
16. Ferreira, A.L., Machado, R.J., Paulk, M.C.: Supporting audits and assessments in
multi-model environments. In: PROFES. Lecture Notes in Business Information
Processing, vol. 6759, pp. 73–87 (2011)
17. Gonzalez-Perez, C., Henderson-Sellers, B.: A powertype-based metamodelling
framework. Software and System Modeling 5(1), 72–90 (2006)
18. Intl. Org. for Standardization: ISO 26262: Road vehicles – Functional safety (Nov
2011)
19. Kühne, T., Schreiber, D.: Can Programming be Liberated from the Two-Level
style? Multi-Level Programming with DeepJava. In: OOPSLA. pp. 229–244 (2007)
20. OMG: Meta Object Facilities. http://www.omg.org/mof/ (July 2014)
21. OMG: Unified Modeling Language. http://www.uml.org/ (July 2014)
22. Siviy, G. et al.: Maximizing your Process Improvement ROI through Harmoniza-
tion. Tech. rep., Carnegie Mellon Univ. – Software Eng. Inst. (March 2008)
112