The Palladio Bench started out as a tool for designing and analyzing the performance of component-based enterprise software systems. Over the following years, numerous extensions have been introduced to increase Palladio's analysis capabilities. These include in particular support for additional quality attributes. With an eye on current research projects, we expect this trend to continue. This includes opening up Palladio for multiple technology domains, besides its current focus on software systems. The ever-growing number of modeling constructs, however, easily leads to users being overwhelmed by modeling complexity they do not even need in many cases. Similarly, developers of Palladio tooling struggle with consequences of weak modularization. We therefore propose a refactoring of the historically grown Palladio Component Model (PCM) into different modules that build upon each other. A core module is planned to serve as architecture description language (ADL). Modules for different quality dimensions enrich the ADL by specific modeling and analysis capabilities. This paper presents our vision of a modular PCM. Due to the early stage of the project, we focus on discussing requirements and challenges, and present initial solution ideas.
With the Palladio approach [
To avoid these problems we are planning to modularize Palladio’s metamodel. The goal of the refactoring is to split up the metamodel into a core metamodel, which can be considered an architecture description language. Capabilities to model properties like performance, reliability, security and so on, will be contained in metamodel extensions which can be used by installing additional plug-ins. This way users can use only the functionality they are interested in. Furthermore, the PCM gets more flexible and thus can be used as integration platform for future extensions. From a technical point of view, the metamodel becomes cleaner, and further extensions of the metamodel can be included with less effort. To ensure compatibility with existing tools and legacy instances of the metamodel we plan a transformation from the modularized PCM instances to classical PCM instances. The contribution of the paper is threefold: First, we present our vision of a modularized PCM. Second, we bring our plans up for discussion to accomplish our goal. Third, we list requirements for a modularized PCM we collected from various stakeholders. The remainder of the paper is structured as follows: In Section 2, we discuss extension scenarios of the PCM. In Section 3, we present our vision and propose solutions how the refactoring can be done. Section 4 explains technical requirements and open challenges. Section 5 concludes the paper and gives an outlook to future work. 2
Several extensions to the PCM have been proposed over the last years, most of which made
their way into Palladio’s metamodel, its model editors and analysis tools. These extensions
can be divided into at least three groups. Extensions of the first group enrich Palladio by
additional quality attributes such as reliability [
From this description, we can extract the following extension types that can be found in PCM-REL:
Support for these extension types would be a good starting point for a modular PCM. Yet, to be able to support the whole range of extensions, they will most likely not suffice. 3
Our vision of how to refactor the Palladio Bench can be best described starting from the metamodel (the PCM). An illustration is shown in Figure 1. On the right side, the current version of the metamodel (here PCM Classic) is depicted. As indicated by the upper arrow labeled refactor, the current metamodel is refactored into the modular metamodel, which is shown on the left. The ellipses on the left represent metamodel modules. forward transformation: migrate legacy models backwards transformation: enable legacy tools to support modular models (not for new modules)
Current MM PCM-Per
New, Modular MM
PCM-Rel
PCM-Beh metamodel is refactored into modules which are located within the outline of the curved shape. Please note that the picture does not depict all modules, as it serves only to give an overview of our proposed approach. For example, core concepts like usage model, deployment and resource environment are not depicted. How exactly the metamodel is cut is part of future work. The modules outside of the curved shape are new extensions which will result from current research (e.g., security, code mapping [10], tracing of requirements and design decisions [9]).
The lines which connect the modules represent a relation between the modules. One possible relation is: an element of one module specializes an element of the other module. Which extension mechanisms will be ultimately used, however, is yet another open question. A transformation from the classic to the modular metamodel can migrate legacy models (forward transformation). The backwards transformation, from the modular to the classic metamodel, ensures backwards compatibility for existing tools (e.g., simulators and solvers). This eases the development process, especially with regards to release planing, as not all tools have to be adapted at once to work with the modular metamodel. Transformations and tools, which are actively developed, can be gradually ported to operate on the modular metamodel. Tools that are no longer actively maintained will remain operational. Once the modular metamodel is established, changes and new extensions will only be performed on the modular metamodel. By applying first the forward, then the backward transformation on a model, one can validate the correctness of these transformations, as well as the completeness of the modular metamodel. 4
So far, we explained only the impacts of the refactoring onto the metamodel. Based on the extension scenarios pointed out in Section 2, the refactoring also impacts tools, corresponding transformations, and editors. Our goal is to provide a framework where metamodel extensions are encapsulated within plug-ins. These plug-ins also contain the functionality needed for the other layers to handle content of the metamodel extension. This could result in the following procedure: when a new PCM model is created, the user selects the required extensions depending on the purpose of the model. The PCM ADL module will always be included. An extension is only available, if the containing plug-in is installed. Predefined configurations could be provided, which suggest specific sets of extensions to the user. For example, the performance configuration could include usage, resource environment, behavior, resource demands (an extension for the behavior extension), deployment and so forth. The extension configuration of a model can also be changed after the model was created. Adding of extensions will always be possible; removing of extensions will be more challenging, especially if the model still contains information which belongs to the extension which is to be removed. One possible and interesting feature is the hiding of information of extensions or switching between them. For example, when modeling a behavior specification, one could switch between displaying performance, reliability and security relevant information, tracing of design decision, requirement and the documentation of applied patterns. A model can only be viewed and edited, if all necessary plug-ins are installed. Otherwise the user could be prompted to install missing plug-ins. In the remainder of this section we discuss the requirements and challenges posed by the refactoring and the development of such a plug-in mechanism onto the layers of the Palladio Bench. These layers include the metamodel and model persistence layer, the transformation layer, the simulator layer, and the editor layer. 4.1
For the Palladio Bench to be able to support a plug-in mechanism poses some requirements to the metamodel layer. For the extensions presented earlier, a proper metamodel extension mechanism has to be found.
Adding a new metaclass (ET1) is straight forward. For the new metaclass to be instantiable within models, it either has to inherit a preexisting abstract metaclass or has to be referenced through ET2 or ET3. Inheriting a non-abstract metaclass is not considered ET1 but rather ET2 or ET3, as it is a decoration of a preexisting metaclass.
Another way to achieve ET2 and ET3 is through the usage of EMF profiles and stereotypes [8]. A stereotype can contain additional primitive attributes, complex typed references as well as containment references. By assigning a stereotype to a model element, it is enriched by the features defined within the stereotype. Other extension mechanisms could exist, we do not make the claim to be comprehensive.
Extension by inheritance requires the metamodel to be designed in a way that accounts for variability. Abstract metaclasses have to be put in place, where ET1 extensions are expected. The work of Heinrich et al. [5] of extending the PCM Usage Model by business process concepts is a good example for this. Amongst others, Palladio usage models are extended by new control flow actions by specializing the metaclass AbstractUserAction. Stereotypes do not require as much foresight, however, they should be defined in a way they can only be applied to the right entities. 4.2
By now, Palladio comprises several transformations that map the PCM to various targets.
Typical transformations translate PCM instances to various analysis frameworks or analysis
models, for example the simulation and prototyping frameworks SimuCom and
ProtoCom [
Most of our transformations are model-to-text transformations. They map to text-based artifacts using Xtend as a template-based transformation language. Thus their structure is driven by the target’s code structure. Each target consists of modules that override template methods and advice methods of core templates. To have self-contained conceptual extensions we must additionally cut a transformation in alignment with existing source metamodel cuts. This is possible if a core transformation module provides certain extension points, so that additional concepts can be woven in at multiple defined places, similar to aspects. Aspects can be implemented in Java using object-oriented design patterns like the decorator pattern, or with aspect-oriented programming (AOP) techniques, for instance annotations provided by Spring or AspectJ. Since Xtend is a Java-based language, we can exploit any of these facilities [14].
Palladio also incorporates model-to-model transformations. For example the PCM2QPN
transformation [
Introducing new concepts on the metamodel level usually comes along with introducing new simulation behavior to reflect the added semantics. Such simulator extensions currently flow directly into the respective simulator’s code base, leading to monolithic simulators. With a modular PCM, we see the chance of modularizing the simulation as well. In addition to metamodel extensions, each PCM module could contribute its particular extension to the overall simulation behavior. This creates the need for pluggable simulation modules. Pluggable simulation modules must declare what extension points they offer, and what extensions they provide to other modules. This is exactly the idea of the plug-in mechanism available with Eclipse’s OSGi implementation Equinox. Since most of Palladio’s simulators are Eclipse-based anyway, a natural decision would be to take advantage of the plug-in mechanism.
The definition of extension points, however, is challenging and requires in-depth knowledge
of the current simulation and of potential simulator extensions provided in future.
Furthermore, the simulation architecture must be designed with extension points in mind. As an
example, EventSim [
Palladio currently uses the Graphical Modeling Framework (GMF) to provide graphical editors for the PCM. GMF uses model-driven technologies, GMF models are used to link graphical elements to abstract concepts. From these models, graphical editors are generated. Separate GMF editors exist for six different views of the PCM, each requiring its own set of GMF models. GMF Tooling and the underlying GMF Runtime both do not allow editors to be configured dynamically regarding the modeling concepts presented to users – neither by developers at design time or by users at run time.
With a modularized PCM model, however, metamodel extensions should be able to bring their own editor extensions. At runtime, editors must be able to dynamically load these extensions depending on the user’s demands. There are two imaginable kinds of editor extensions, those that plug into existing PCM editors, and those providing additional editors for custom views on the added concepts.
The following technical challenge needs to be tackled: When a module is adding modeling
concepts in the form of new metaclasses to the PCM (ET1), these additions can require
several views and thus editors to be adapted accordingly. Scattering and tangling occurs,
because a concept can be scattered over multiple editors, or an editor tangles multiple
modeling concepts, even at the level of code artifacts. These issues occur for both graphical
and textual representations, and extensibility must be handled dynamically at runtime,
for example using an Eclipse-based plugin mechanism. Adding attributes or containment
references to existing metaclasses (ET2, ET3) is already in the process of being integrated
into GMF editors with the help of a stereotyping mechanism based on EMF Profiles [8].
Under Eclipse, there is another prominent framework to design graphical representations,
the Graphiti framework. The Graphiti framework is designed for manual programming in a
declarative style, therefore it is much leaner but still more flexible, and can be conceived as
a successor to GMF. It seems that Graphiti as well does not explicitly support extensible
editors so far. Because its streamlined API is easier to understand, we believe Graphiti is a
prime candidate to be prepared for runtime composability. Further research is required to
explore techniques to make the Graphiti framework susceptible for extensible metamodels.
In the future, textual editors may complement Palladio’s graphical editors as alternative
views with similar expressiveness. As far as we know, textual editors can be already
designed in a composable fashion, albeit only at design-time. For example, MontiCore and
Spoofax/IMP [
In this paper, we presented the motivation behind the refactoring, identified different types of extension scenarios, proposed a vision of how to solve these issues and outlined the arising requirements and challenges we identified so far.
The refactoring endeavor is especially important for the future development of the Palladio Approach. We strive to broaden the application range of the Palladio Approach to cover more and more stages of the software development process. The artifacts and information created in these stages should not be captured in separate models, managed by separate tools. Rather, we aim to consolidate them into the PCM and by doing so to relate them to the component-based architecture. Architecture design, performance and reliability are some of the features already incorporated within the PCM. Tracing of Requirements, design decisions and patterns, code mapping, security characteristics and many more are currently subject to research. In addition to that, modeling concepts from new domains like energy infrastructure and public transportation will also be incorporated. To support a conceptually clean extension mechanism we propose to form an ADL as a basis and need to modularize the current content of the metamodel. We suspect such a refactoring to also improve maintainability and understandability of the metamodel and maybe even of the Palladio Bench.
We are currently in the phase of collecting requirements and developing a concept on how to cut the metamodel and how the ADL core should look like. For the future we plan to form research questions from the scope of refactoring metamodels, metamodel quality and from the refactoring of architecture simulators. An in-depth literature review is also planned to reveal similar approaches on which we can possibly build upon. To substantiate the concept of the metamodel cut and the ADL, we also need to identify as much future extension as possible, to account for variety at the right spots of the metamodel. This will be followed by an evaluation of technical solutions. Any feedback to our approach is always very welcome. 6
We would like to thank the further members of the special interest group PCM Refactoring for their valuable input: Jörg Henß, Lucia Happe, Max Kramer and Robert Heinrich. Further we thank Klaus Krogmann, Ralf Reussner and the whole SDQ Chair for many fruitful discussions.
Miroslaw Milewski and Graham Roberts. “Patterns for Handling Crosscutting Concerns in Model-Driven Software Development”. In: 10th European Conference on Pattern Languages of Programs (EuroPLoP 2005). 2005.
Qais Noorshams, Andreas Rentschler, Samuel Kounev, and Ralf Reussner. “A Generic Approach for Architecture-level Performance Modeling and Prediction of Virtualized Storage Systems”. In: Proceedings of the ACM/SPEC International Conference on Performance Engineering. ICPE ’13. New York, NY, USA: ACM, 2013, pp. 339–342.
Christoph Rathfelder, Benjamin Klatt, Kai Sachs, and Samuel Kounev. “Modeling Event-based Communication in Component-based Software Architectures for Performance Predictions”. In: Journal of Software and Systems Modeling (SoSyM) (Mar. 2013), pp. 1–27.
Dominik Werle. “Adding a Module Concept to the Model Transformation Language Xtend”. Bachelor’s Thesis. Karlsruhe, Germany: Karlsruhe Institute of Technology, Sept. 2013.