=Paper=
{{Paper
|id=Vol-1463/paper6
|storemode=property
|title=A Modular Reference Structure for Component-based Architecture Description
Languages
|pdfUrl=https://ceur-ws.org/Vol-1463/paper6.pdf
|volume=Vol-1463
|dblpUrl=https://dblp.org/rec/conf/models/StrittmatterRHR15
}}
==A Modular Reference Structure for Component-based Architecture Description
Languages==
https://ceur-ws.org/Vol-1463/paper6.pdf
A Modular Reference Structure for
Component-based Architecture Description
Languages
Misha Strittmatter, Kiana Rostami, Robert Heinrich and Ralf Reussner
Chair for Software Design and Quality (SDQ)
Karlsruhe Institute of Technology
Karlsruhe, Germany
{strittmatter | rostami | heinrich | reussner}@kit.edu
Abstract—Metamodels are used to define languages, code gen- feature similar concepts to: classes, containment-, inheritance-
eration and they serve as data structures for metamodel-centric and association relations between classes.
software systems. In software engineering, these metamodels are There are multiple ways to found metamodel-based lan-
crafted, evolved and extended, e.g., by further quality dimensions
or structural features. However, an ad-hoc modeling approach guages: 1) a new metamodel is developed. 2) an existing meta-
does not properly support metamodel reuse by extension or model (e.g., UML) is extended by annotations or stereotyping.
composition. Nor does it enforce a proper modularization which 3) a variant or branch of an existing language is created. The
helps with tackling complexity. We present an approach to development of new metamodels is straightforward, if they do
design and extend metamodels for component-based architecture not evolve and are isolated. However, this is seldom the case.
description languages in a modular way. The information which
is to be metamodeled is divided into paradigm, domain, quality The major problem is that growing metamodels structurally
and analysis content. We constrain the usage of dependencies degrade over time. Extensions by annotation or stereotyping
and give instructions how to modularize in accordance to are problematic as they may result in a flat, unstructured
concerns. Related approaches try to modularize and compose organization of information. Branches and variants are prob-
transformations, generators, and tools in general. However, in lematic, because duplicated parts have to be maintained when
the field of metamodels, little support is given. Our approach
is applied to several concerns of the Palladio Component Model the original language evolves.
and an extension thereof. An example of this is the Palladio Component Model
(PCM) [1]. It is a metamodel-based language which was
I. I NTRODUCTION initially developed for the specification of component-based
In model-based software engineering (e.g., model-driven software architectures and their resource demands to be able
software development or software performance engineering) to predict their performance. With time, the research focus
and in general in many fields of computer science, software broadened and more structural features and quality dimensions
is described using models. These models capture different were incorporated. Some of this information was directly
aspects like the object-oriented design, more coarse-grained built into the language [2]. Other aspects were specified as
architecture, deployment and so forth. Each discipline has its extensions or wound up in branches (e.g., the integration
own focus and may add more information to this founda- of business processes modeling and analysis [3] as well as
tion. E.g., design decisions, implementation documentation, modeling and analysis of maintainability [4]). This impedes
requirements and quality related information like service level the structure and reuse potential of inner parts of the PCM.
agreements for performance or security. There are approaches, which put forward modular, com-
A metamodel is a model which defines the structure of other posable or extensible concepts which are more or less related
models. If a model conforms to a metamodel, the model is to metamodels. These concepts include components [5], [6],
considered an instance of the metamodel. Thus, metamodels classes of object-oriented design [7], domain specific and
are similar to grammars, as they define languages. A prominent general purpose languages [8], transformations [9], genera-
example is the Unified Modeling Language (UML) meta- tors [10] and simulators [11]. However, for metamodels, little
model [12]. A sequence diagram (instance) is a model which support is given.
is an instance of the UML metamodel. Our approach primarily Our approach aims to tackle these problems with a ref-
targets MOF [13] (i.e., the meta-metamodel of UML) conform- erence structure for metamodels for architecture description
ing metamodels. However, we expect that it also directly appli- languages. The reference structure proposes a modularization
cable to metamodels conforming to meta-metamodels which of information into layers for paradigm, domain, quality and
analysis information. The layers can further be divided: e.g.,
This work was supported by the Helmholtz Association of German Research
Centers and the DFG (German Research Foundation) under the Priority for separate quality dimensions or different domains. This
Programme SPP1593: Design For Future – Managed Software Evolution. leads to a modular, flexible and extensible structure, which
satisfies separation of concerns and thus is better understand- to the extension being made. This unnecessary complexity
able and maintainable. It also increases the potential for reuse leads to a decline in understandability and may even lead to
as a basis for new extensions. In addition, modularity leads metamodeling mistakes. Further, both extension approaches
to localization of change impact in the case of metamodel are adverse to the maintainability of the metamodel. Intrusive
evolution. This does not only apply to the metamodel but to extensions increase the complexity and external extensions
everything which is dependent on the metamodel (e.g., editors, often lack extension points in the base metamodel. Extension
analyzers, generators). The applicability of our reference over time, regardless of intrusive or non-intrusive, increases
structure is demonstrated on an selection of basic concerns either complexity or the amount of software artifacts that are
and extensions of the PCM. dependent on the core metamodel. Thus, if the base metamodel
Our approach aims at the structuring of metamodels for the is in need of restructuring but the restructuring is postponed,
description of component-based software architecture and their the cost of the refactoring will increase. This is especially
qualities. However, we expect that it can also be applied to an critical in metamodel centric applications and can be called
even broader spectrum of metamodels, where the proposed metamodel debt (cf. technical debt).
decomposition is meaningful. These may be architecture de- Negative effects of unstructured extensions on users are
scription languages (ADLs) or even description languages of twofold. Users have specific needs with regards to the features
software-intensive systems in general. of the program. They may be confused or overwhelmed
This paper is outlined as follows: Section II describes the when confronted with too much content irrelevant to them.
example scenario. Section III presents the reference structure Further, to support the additional metamodel content, the code
and its concepts. Section IV applies the reference structure of all extensions has to be shipped. For these issues, there
onto the example scenario. Section V presents related work. are technical workarounds to minimize their negative impact.
Section VI concludes the paper. Shipped code of extensions may be reduced to a minimum
by only including the model code. Tools and editors may be
II. P ROBLEM S CENARIO configurable to hide content which is not wanted by the user.
The scenario for our motivating example is the PCM. The However, this is only a workaround, as each extension needs
PCM (i.e., a metamodel) is used for several analyses and to intrusively modify the tool in question.
simulations (see Figure 1). At the core of the PCM is a well For the means of the running example, the relevant concepts
formed construct to specify components, interfaces, and their of the PCM will be explained in a condensed way (illustrated
composition. In the past, this part of the metamodel has served in Figure 2). For a complete and detailed description of the
as a basis for new metamodel content which was emerging PCM, please consult the technical report [18]. At the core of
from new research. Initially this content was added directly the PCM are components and interfaces (I). Both are first class
to the PCM [14]. Examples of such intrusive extensions are entities and a components may implement or require interfaces
reliability [15], event communication [16] and infrastructure (II). Components can be placed within an architecture by creat-
components [17]. Later, as their number and diversity grew, ing an assembly context (III). The interfaces of these assembly
extensions were no longer included directly in the PCM. They contexts can be linked by connectors (IV). A component may
either came in the form of branches of the metamodel or be either atomic or composite (V). Composite components
metamodels which referenced into the PCM. Examples of such contain further assembly contexts and connectors. For the
extensions are KAMP (Karlsruhe Architectural Maintainability modeling of performance and reliability, atomic components
Prediction) [4] and support for modeling business processes contain abstractions of control flow (VI) (similar to activity
that interface with system services [3]. diagrams or flow charts). These control flow specifications
carry resource demands and failure probabilities in some of
Components, Palladio Simulation Simulation
Interfaces tio
n
Code
their states. To conduct performance simulation [19] of such a
Component forma Performance
Pa
s model, there is further information needed like the maximum
rt
Model Tran
#include
of
unsigned main()
Java Code Completion
{
ation
dummy code;
Pa
code dummy = writes
Composition rt o f or m
some dummy code;
writing dummy(code is)
boring;
simulation time or the maximum measure count.
Trans Skeletons immitate an if?
f
if(immitate) {
do immitate;
}
return 42;
Another part of the running example is KAMP [4]. It is
}
∙∙∙
Part of ∙∙∙ ∙∙∙
f Trans
to fo rmati an extension for the PCM that deals with maintainability.
Performance Par on Performance Execution +
Characteristics Instance Prototype Measurement Performance It is a tool-supported approach to semi-automatically predict
of
€
rt
change propagation in a software system. In contrast to
Pa
Maintain- Maintainability Analysis
ability other approaches, KAMP considers not only the architecture
Effort of a software system, but also organizational aspects (e.g.,
Fig. 1. Excerpt of Concerns and Capabilities of the PCM management or various roles such as tester or deployer) as
well as technical artifacts (e.g., testing, build configurations,
Branches as well as intrusive extensions are problematic or deployment). KAMP comprises two phases: 1) Preparation
and have negative implication on users, developers, and re- Phase: After the user models a software architecture using
searchers. Developers and researchers should have a clean base the PCM (e.g., Figure 2), she or he enriches the model with
upon which they can build their extensions. If the metamodel is context annotations such as test cases and build configuration.
not modularized, it often contains content, which is irrelevant 2) Change Request Analysis Phase: After the user has modeled
Interface1 «requires» (I) Interface2 file, or they may just manifest within the package structure or
«provides» comparable subdivisions within one metamodel. The contents
(I) (e.g., classes) of one module may depend on the contents of
Basic Basic Composite
Component1 Component2 Component another module. This is either in the form of simple reference,
(V )
(V) containment, inheritance, or stereotype application. If at least
«instance» «instance» one dependency from one module to another exists, we will
(VI)
∙∙∙
(III) regard that as the one module being dependent on the other.
Assembly
Resource Context Our reference structure organizes modules into layers as the
Demand (III) topmost unit of decomposition. A layer is a set of modules.
Assembly (IV)
The layers are ordered with regard to the dependencies of
Context their modules. The modules of a layer may only depend on
the modules of the same or more basic layers. More basic
here means, that they depend on fewer other layers. Within the
Fig. 2. Simplified Concepts of the PCM
scope of this paper, basic layers will be illustrated at the top. If
the change in the enriched architecture model, KAMP semi- a module of a layer depends on a module of another layer, we
automatically calculates the change propagation and derives will regard that as the one layer being dependent on the other
a task list, which is composed of tasks needed to implement one. Layers may depend on all higher layers. However, it is
the change request. This step calculates all affected artifacts advisable to confine the dependencies on the next higher level
annotated in the model, too. where possible. Circular dependencies between modules (as
The overall scenario of the running example is illustrated well as between layers) are not allowed. A circular dependency
in Figure 3 and contains several main concerns: the PCM is is either a result of a dependency which should be reversed,
a language to specify component-based software architecture or of a strong cohesion between the modules. These modules,
as the common basis; performance characteristics, which are thus, should be considered for merging or restructuring.
included in the PCM and partly in external sources (con- A module encapsulates a set of concerns. When modulariz-
figurations of analysis launches); maintainability information, ing, two main rules should be applied. It should be meaningful
which is contained within an external extension. The PCM is to use the basic module (or modules) with and without the
internally structured. The primary decomposition runs along concerns which have been factored out. If this is not the
its view types (submodels). However, here it is displayed as case, the modularization is still meaningful if the basic module
one module with the exception of the performance results, serves as a common foundation for multiple further modules.
which are stored in a modular way. This stems from the fact The information which is formalized in metamodels can be
that due to dependency cycles within the PCM [2], it is only grouped into categories depending on the type of information.
possible to use it as a whole. Thus, all the problems from above Multiple decomposition dimensions exist and it not always
follow for developers and users: unnecessary complexity and clear which decompositions to apply and in which order.
its implications. Intuitive design might modularize information in ways of
Component Architecture, infrastructure (abstract class hierarchies) vs. concrete content,
PCM views types or sub models, or semantic cohesion. With our
Behavior, Performance,
Reliability, Infrastructure, reference structure, we propose as the primary decomposition a
Performance
Events, Resources, layering into: paradigm, domain, quality and analysis content.
Results
Deployment, Usage, ...
Paradigm (π ) is the most basic layer. It lays the the foundation
Static Modifi- Artifacts KAMP Maintainability of the language by providing structure but without semantics.
Dependencies cations and Staff Prediction
The domain (∆) layer builds upon the paradigm and assigns
semantics to its abstract structure. The quality (Ω) layer adds
Fig. 3. Status Quo of the Scenario: Metamodel Modules
quality properties to the domain concepts. Lastly, the analysis
These problems are tackled by our approach. By mod- (Σ) layer provides modules for input-, output- and internal
ularizing the meta content and structuring it according to state and configuration options for analyses. We settled for
our reference structure, the concerns are separated and the these layers, because they provided an intuitive primary de-
extensions have a clean base. In the following sections we will composition in our research when inspecting metamodels for
present the layers of the reference structure, then build an ideal component-based architecture description languages and their
and modular version of the scenario meta model according to intrusive and external extensions. The concern constellations
the reference structure. of these layers (whereas not as explicit as proposed by our
reference structure) can be found in metamodels like UML
III. R EFERENCE S TRUCTURE OVERVIEW
MARTE, the Descartes Metamodel and the PCM.
Within our reference structure, the metamodel is subdivided
into smaller parts which we call metamodel modules or just IV. A PPLYING THE R EFERENCE S TRUCTURE
modules. On the technical level, these modules may manifest In the following subsections, we will explain the layers
in their own metamodels, each of which is persisted in its own of the reference structure and gradually construct a modular
metamodel of our example (PCM extended by maintainability) information (i.e, attributes and relations) can be added to
according to these layers. Please keep in mind, that this the derived classes. New domain concepts may be created
is a simplification and a reconstruction of the PCM. Thus, as well. However, if these new domain concepts have an
modeling of concepts and dependency directions partly do not overlap with classes of other modules in ∆, or even of π it
adhere to the current PCM. should be considered to factor that content out into a higher,
more general module or even a higher layer (i.e., in this
A. Paradigm case π ). In the scope of this paper, ∆ will capture software
The most basic layer is the paradigm layer (π ). It defines systems. In general, any ∆ layer is possible. E.g., embedded
foundational structure but without semantics. Thus, it is not and mechatronic systems or cyber-physical systems. The ∆,
directly usable. Not even for purposes which do not need however, has to fit the underlying π layer.
dynamic semantics (e.g., documentation and communication). The ∆ layer excerpt of the example scenario is illustrated
The minimal configuration of the metamodel which is mean- in Figure 5. It features the ComponentRepository module,
ingfully instantiable is π and the domain layer put together. where the modeler can specify the Components and Interfaces
First class entities in π should be abstract and no top level of an architecture. Please keep in mind that the relation
container (root) should be provided to avoid instantiation. between Components and Interfaces is already defined in the
Modules which cannot be instantiated directly, will be consid- π layer. The ComponentRepository module assigns domain
ered abstract modules. In our case π constitutes components, semantics to the abstract CoreEntities module of the π layer
interfaces and their composition. However, any π is possible. providing concrete subclasses for its abstract classes. This
It is dependent on the subject matter which is to be captured. separates the concerns of the structure of the paradigm (here
E.g., object oriented design and behavioral formalisms. component architecture) from its domain semantics, enabling
In our example, π encompasses the modules CoreEntities the reuse of the paradigm structure. The Behavior module
and Composition. This is illustrated in Figure 4. Please keep extends SoftwareComponents by a behavior abstraction, which
in mind that for the sake of presentation this is an extremely is similar to a flowchart. The Behavior module is performance
simplified depiction. Wherein Composition is dependent on agnostic and is later used as a foundation for performance
CoreEntities. CoreEntities contains the abstract metaclasses and reliability modeling. The Modification module is essential
Component and Interface. Like in the standard UML notation, to the maintainability analysis. It defines Modifications of the
abstract classes and abstract modules are indicated by a name architecture. Each concrete Modification references an element
in italic letters. A Component may reference various Interfaces of the architecture. It further defines Propagations, which
in two ways: provide and require. The Composition module express how Modifications spread through an architecture.
defines ComposedStructures which contain AssemblyContexts
and Connectors. Connectors link Interfaces of two Assem-
blyContexts. An AssemblyContext represents an instance of a
π Repository
Com-
ponent
Inter-
face
Behavior
Component. Component Operation
Behavior
Repository Interface
CoreEntities *
Composition Software Abstract
Inter- * Com- *
face * ponent Composed * Component Action
Connector 0...1
π
Structure
1 2 Business Infrastructure Internal
* Action
Assembly Component Component
Context External
Modification Call
∙∙∙
∙∙∙ Modification
Fig. 4. The π (Paradigm) Layer Start
Action
The ComposedStructure extends Component. In the illus- Mod Mod
Interface Connector ∙∙∙
tration, the UML notation for stereotype application (a filled
IntraComp
arrow) is used. However, the implementation of this relation
does not necessarily have to be stereotyping. A wide range
ModComp
∙∙∙
Propagation Propagation
∙∙∙
Δ
of different extension mechanisms is available with all their
pros and cons. Further ones are annotation, plain inheritance, Fig. 5. Excerpt of the ∆ (Domain) Layer
and the application of patterns like the decorator pattern or
aspect-oriented extension [20]. C. Quality
The π layer builds the foundation of the remainder of the The quality layer (Ω) defines the inherent quality properties
metamodel. It is important, that is has no outgoing dependen- of ∆ concepts. It contains primarily second class entities,
cies into other layers. This way, it can be reused on its own. which enrich first class entities of ∆. In the scope of this
paper, the Ω layer constitutes performance and reliability
B. Domain characteristics. Possible other Ω modules which fit the π and
The domain layer (∆) extends π and assigns domain ∆ are: security and availability. Not in every circumstance a
semantics to its abstract first class entities. By doing so, new Ω layer is needed. E.g., when the metamodel is only needed
for specification of software design or for static analysis. This In Figure 7 an excerpt of the Σ layer is shown. As a really
is the case for the KAMP maintainability analysis, which does simplified version of the performance result, here, a set of
not require information in the Ω layer. OperationResponseTimes is modeled. An OperationRespon-
The quality properties have to be inherent and not de- seTime has a unit, which is specified in the Ω layer (the
rived. Inherent with respect to the analyses which can be corresponding module was not shown in Figure 6). It further
performed on the model. E.g., when considering the PCM references the AssemblyContext and the Interface where the
and performance, the response time of an operation depends response time was recorded.
on many things, like resource demands within the operation,
Staff Assembly Operation
response time of external calls and so on. Thus, the response Specification Modification Context Interface
time of an operation in this consideration is not an intrinsic Development Propa-
value, but a derived one. Therefore, the response time of
operations should be moved to a lower layer. There may be
Artifact gation
Δ Unit
Ω
quality concepts which are needed to model derived properties. KAMP Input KAMP Result PerformanceResults
These should be specified in the Ω layer. However, their Evolution Impact Operation
instances should be contained in the Σ layer. On the other
side, the resource demand (not in terms of time but in load) is
Scenario Propagation ResponseTime
Performance
Results
* Σ
independent. It may be derived from an estimate or a real
word software artifact, but with regards to the analyses it Fig. 7. Excerpt of the Σ (Analysis) Layer
cannot be derived. Therefore, it belongs in Ω and should be
contained and specified there. If a model is used for solving, The in- and output for the KAMP maintainability prediction
analysis or simulation, the model content from Ω should is on the left side of Figure 7. In this circumstance, the
remain static during execution. If that is not the case, the quality layer is not needed. Both modules merely hold a
information belongs to the analysis layer, as it is derived or root container and reference directly into the ∆ layer. The
EvolutionScenario of KAMP Input contains everything the
state information.
analysis requires: seed Modifications, StaffSpecifications and
Figure 6 shows an excerpt of the exemplary Ω layer. It
DevelopmentArtifacts that belong to the architecture’s ele-
contains the modules for Performance and Reliability. They
ments. The ImpactPropagation contains the predicted extend
extend InternalAction, and therefore the internal behavior of
of the architecture change in the form of Propagations. The
a Component, by ResourceDemand and FailureOccurence. A
ImpactPropagation further references the input of the scenario
FailureOccurence has a probability, as well as a type. Here,
to enable inference of affected artifacts and staff.
an important advantage of the modularization shows. The
behavior metamodule is free of performance and reliability
E. Overall Module Structure
data. As required, it can be extended by one of the two, or
even both. Tools and developers are not bothered by irrelevant For an overview of all the modules of the scenario and
content. Potential future extensions can be created without the their dependencies, see Figure 8. The modules which convey
need for prearrangement. specific concerns are indicated by different levels of gray
(maintainability is dark, performance is medium, reliability
FailureTypes
Δ
is light). The remaining modules cover more fundamental
Internal Failure Software Hardware
concerns: component-based architecture and behavior. They
Action Type Failure Failure ∙∙∙
are the intersecting set of the metamodel elements of these
Ω
Performance Reliability analyzes. The illustration may seem much more complex,
Resource Failure Failure than the initial illustration in Figure 3. This is because in
Demand Occurence Probability the initial figure, all the concerns of performance, reliability,
behavior, and component architecture are contained in the big
Fig. 6. Excerpt of the Ω (Quality) Layer PCM module. The original structure cannot be subdivided into
modules. At least not into modules according to the definition
D. Analysis in this paper, as the subpackages of the PCM have cyclic
The analysis layer (Σ) is only relevant, if models are used dependencies (see [2]).
as a basis for analysis, solving or simulation (hereafter only This modular structure brings many benefits. External ex-
referred to as analysis). Σ provides new views to specify tensions now have a clean base to build on. E.g., a security
input state, configuration, run-time state and output of an extension can now be developed without having to deal with
analysis. These are all possible views, but only a subset may performance and reliability. In the modular structure, extension
be required by an analysis. It is possible for multiple analyses developers have to only understand the modules they extend
to be founded on the upper layers. Several analyses may share and to some degree modules from which they are indirectly
modules, but also posses their own ones. In the focus of dependent. This increases the potential of reuse of the more
this paper, the Σ layer is concerned with the performance basic (higher) modules. When evolving the metamodel, change
simulation and the change impact analysis KAMP. impact can be traced down the graph, following the depen-
π Core were chosen to demonstrate the applicability of the reference
Entities Compo-
structure. Our approach aims to be applicable to component-
sition based architecture description languages which also express
quality properties.
Δ Static
Software
Components
Development
Failure
Types
Our reference structure propose modularization into layers
and further into modules as well as making the dependencies
Dependencies Artifacts Behavior explicit. Dependencies are constrained to avoid dependency
cycles and improve modularization. Guidance for the modu-
Staff Modifi-
Specification cations larization with regards to concerns is given. The reward is
a more modular metamodel which allows for better compo-
Ω Performance
Metrics
Perfor-
mance
Relia-
bility
sitionality of extensions. The improved modularity leads to a
reduced complexity and all its benefits: better understandabil-
ity, maintainability and reusability.
Σ KAMP
Input
KAMP
Result
Performance
Results
Performance
Configuration
Future work include an in-detail examination of the possible
extension mechanisms which can be used for the extension
Fig. 8. The Scenario Metamodel Restructured In Concordance to the
relation. Also, we plan to develop decision support for the
Reference Structure grouping of classes and modules into the layers. Further, an
dency relations. This way changes can be assessed much faster extensive metamodel will be remade according to the reference
and more accurately. structure and its correctness and completeness proven (e.g.,
by finding an isomorphism). An interesting question worth
V. R ELATED W ORK investigating is if different types of extension with regards to
There are approaches, which deal with the modularization, the interplay of abstract and concrete module have implication
categorization or structuring of related concepts. Coad’s UML onto potential roots elements of view types.
archetypes [7] for object-oriented design are used to classify R EFERENCES
classes into things, temporal concepts, roles and descriptions.
[1] S. Becker et al. “The palladio component model for model-driven
Atkinson et al. propose a view-based approach for software en- performance prediction,” JSS, Elsevier, 82(1):3–22, 2009.
gineering. The underlying model captures every concern into [2] M. Strittmatter et al. “Identifying semantically cohesive modules within
orthogonal dimensions, which are assessed through views [5]. the palladio meta-model,” SSP, 160–176, 2014.
[3] R. Heinrich et al. “Integrating business process simulation and
Further, with deep modeling [21] they propose to enable in- information system simulation for performance prediction,” DOI
stance relations within models. These deep models are layered 10.1007/s10270-015-0457-1, SoSyM, Springer, 1–21, 2015.
with regards to instance levels. JetBrains MPS [8] features [4] K. Rostami et al. “Architecture-based assessment and planning of change
requests,” QoSA, ACM, 21–30, 2015.
capabilities for the extension of DSLs. Siedersleben [6] pro- [5] C. Atkinson et al. “Orthographic software modeling: a practical approach
posed a reference structure for software architectures, where to view-based development,” ENASE, Springer, 69:206–219, 2010.
components are categorized into so-called blood types (tech- [6] J. Siedersleben Moderne Software-Architektur: Umsichtig planen, robust
bauen mit Quasar, dpunkt, 2004.
nical, domain and library). Yet these approaches cannot be [7] P. Coad Java modeling in color with UML, Prentice Hall, 1999.
transferred to work on metamodels or they do do not offer [8] M. Voelter et al. “Language modularity with the mps language work-
support for metamodel extension and reuse. bench,” ICSE, IEEE, 1449–1450, 2012.
[9] A. Rentschler “Model Transformation Languages with Modular Infor-
There is also related work, which aims at modularizing mation Hiding,” Ph.D. thesis, Karlsruhe Institute of Technology, 2015.
concepts which are in direct interplay with metamodels. [10] R. Jung “Geco: Generator composition for aspect-oriented generators,”
Jung [10] proposes a composition approach for generators. Doctoral Symposium - MODELS, 2014.
[11] C. Föhrdes “Simulation components for software quality simulation in
Rentschler [9] developed an approach for modular transforma- eclipse,” Master’s thesis, Karlsruhe Institute of Technology, 2014.
tions. Föhrdes [11] presents a modularization into components [12] OMG “UML Infrastructure Specification 2.4.1,” 2011.
of a performance simulator which operates on the PCM [13] OMG “MOF Core Specification 2.4.2,” 2014.
[14] M. Strittmatter et al. “Towards a modular palladio component model,”
(metamodel). These approaches are especially interesting, as SSP, CEUR, 49–58, 2013.
they deal with artifacts which are used in conjunction with [15] F. Brosch “Integrated software architecture-based reliability prediction
metamodels. However, theses approaches cannot be directly for it systems,” Ph.D. thesis, Karlsruhe Institute of Technology, 2012.
[16] C. Rathfelder “Modelling Event-Based Interactions in Component-
transferred onto metamodels. Based Architectures for Quantitative System Evaluation,” Ph.D. thesis,
Karlsruhe Institute of Technology, 2013.
VI. C ONCLUSION [17] M. Hauck “Extending Performance-Oriented Resource Modelling in
In this paper, we proposed a reference structure for modu- the PCM,” Diploma thesis, University of Karlsruhe, 2009.
[18] R. Reussner et al. “The Palladio Component Model,” Tech. Rep.,
lar metamodels for component-based architecture description Karlsruhe Institute of Technology, 2011.
languages. It proposes a layering of the information into [19] M. Becker et al. “Performance analysis of self-adaptive systems for
paradigm (π ), domain (∆), quality (Ω) and analysis (Σ) requirements validation at design-time,” QoSA, ACM, 2013.
[20] R. Jung et al. “A method for aspect-oriented meta-model evolution,”
content. The reference structure is applied to the PCM [1] and VAO, ACM, 19–22, 2014.
the KAMP [4] maintainability extension. However, a remake [21] C. Atkinson et al. “Melanie: Multi-level modeling and ontology
of the PCM is not the contribution of this paper. These models engineering environment,” MW, ACM, 7:1–7:2, 2012.