-Metamodels are used to define languages, code gen- feature similar concepts to: classes, containment-, inheritanceeration 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 lancorrasftterdu,cteuvroalvlefdeaatnudreesx.teHndoewde,vee.rg,.,abnyafdu-rhthocermqoudaeliltiyngdiampepnrsoiaocnhs guages: 1) a new metamodel is developed. 2) an existing metadoes 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. idsestocrbipetimonetlaamngoudaegleeds iins daivmidoeddulianrtowpaay.raTdhigemin,fdorommaatiino,nqwuahliicthy 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 probtransformations, generators, and tools in general. However, in lematic, because duplicated parts have to be maintained when itsheapfipellidedoftomseevtaemraoldceolns,celirtntlse osfutphpeorPtalilsadgiioveCn.omOpuonreanpt pMrooadcehl 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. INTRODUCTION 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, comA 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], generaexample 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 reftargets 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., CeTntheirsswaonrkd wthaes sDupFpGort(eGdebrymtahne HReelsmeahroclhtz FAosusoncdiaattiioonn)oufnGdeerrmtahneRPesrieoarricthy 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 understandable and maintainable. It also increases the potential for reuse as a basis for new extensions. In addition, modularity leads to localization of change impact in the case of metamodel evolution. This does not only apply to the metamodel but to everything which is dependent on the metamodel (e.g., editors, analyzers, generators). The applicability of our reference structure is demonstrated on an selection of basic concerns and extensions of the PCM.
Our approach aims at the structuring of metamodels for the description of component-based software architecture and their qualities. However, we expect that it can also be applied to an even broader spectrum of metamodels, where the proposed decomposition is meaningful. These may be architecture description languages (ADLs) or even description languages of software-intensive systems in general.
This paper is outlined as follows: Section II describes the example scenario. Section III presents the reference structure and its concepts. Section IV applies the reference structure onto the example scenario. Section V presents related work. Section VI concludes the paper.
The scenario for our motivating example is the PCM. The
PCM (i.e., a metamodel) is used for several analyses and
simulations (see Figure 1). At the core of the PCM is a well
formed construct to specify components, interfaces, and their
composition. In the past, this part of the metamodel has served
as a basis for new metamodel content which was emerging
from new research. Initially this content was added directly
to the PCM [
Performance #include<nothing> unsignedmain() {}iis}crdbwfmoeodou(rtmidromiumtieerniinmdtngdaguy;iu4tmdeac2miuo;taeadmn)yeey{i;;f=c?yow(dcroei;dteesis) ∙ ∙ ∙ € Effort to the extension being made. This unnecessary complexity leads to a decline in understandability and may even lead to metamodeling mistakes. Further, both extension approaches are adverse to the maintainability of the metamodel. Intrusive extensions increase the complexity and external extensions often lack extension points in the base metamodel. Extension over time, regardless of intrusive or non-intrusive, increases either complexity or the amount of software artifacts that are dependent on the core metamodel. Thus, if the base metamodel is in need of restructuring but the restructuring is postponed, the cost of the refactoring will increase. This is especially critical in metamodel centric applications and can be called metamodel debt (cf. technical debt).
Negative effects of unstructured extensions on users are twofold. Users have specific needs with regards to the features of the program. They may be confused or overwhelmed when confronted with too much content irrelevant to them. Further, to support the additional metamodel content, the code of all extensions has to be shipped. For these issues, there are technical workarounds to minimize their negative impact. Shipped code of extensions may be reduced to a minimum by only including the model code. Tools and editors may be configurable to hide content which is not wanted by the user. However, this is only a workaround, as each extension needs to intrusively modify the tool in question.
For the means of the running example, the relevant concepts
of the PCM will be explained in a condensed way (illustrated
in Figure 2). For a complete and detailed description of the
PCM, please consult the technical report [
Another part of the running example is KAMP [
Branches as well as intrusive extensions are problematic and have negative implication on users, developers, and researchers. Developers and researchers should have a clean base upon which they can build their extensions. If the metamodel is not modularized, it often contains content, which is irrelevant
Interface1 «requires» (I) Interface2 «provides» the change in the enriched architecture model, KAMP semiautomatically calculates the change propagation and derives a task list, which is composed of tasks needed to implement the change request. This step calculates all affected artifacts annotated in the model, too.
The overall scenario of the running example is illustrated
in Figure 3 and contains several main concerns: the PCM is
a language to specify component-based software architecture
as the common basis; performance characteristics, which are
included in the PCM and partly in external sources
(configurations of analysis launches); maintainability information,
which is contained within an external extension. The PCM is
internally structured. The primary decomposition runs along
its view types (submodels). However, here it is displayed as
one module with the exception of the performance results,
which are stored in a modular way. This stems from the fact
that due to dependency cycles within the PCM [
These problems are tackled by our approach. By modularizing the meta content and structuring it according to our reference structure, the concerns are separated and the extensions have a clean base. In the following sections we will present the layers of the reference structure, then build an ideal and modular version of the scenario meta model according to the reference structure.
Within our reference structure, the metamodel is subdivided into smaller parts which we call metamodel modules or just modules. On the technical level, these modules may manifest in their own metamodels, each of which is persisted in its own file, or they may just manifest within the package structure or comparable subdivisions within one metamodel. The contents (e.g., classes) of one module may depend on the contents of another module. This is either in the form of simple reference, containment, inheritance, or stereotype application. If at least one dependency from one module to another exists, we will regard that as the one module being dependent on the other.
Our reference structure organizes modules into layers as the topmost unit of decomposition. A layer is a set of modules. The layers are ordered with regard to the dependencies of 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 scope of this paper, basic layers will be illustrated at the top. If a module of a layer depends on a module of another layer, we will regard that as the one layer being dependent on the other one. Layers may depend on all higher layers. However, it is advisable to confine the dependencies on the next higher level where possible. Circular dependencies between modules (as well as between layers) are not allowed. A circular dependency is either a result of a dependency which should be reversed, or of a strong cohesion between the modules. These modules, thus, should be considered for merging or restructuring.
A module encapsulates a set of concerns. When modularizing, two main rules should be applied. It should be meaningful to use the basic module (or modules) with and without the concerns which have been factored out. If this is not the case, the modularization is still meaningful if the basic module serves as a common foundation for multiple further modules.
The information which is formalized in metamodels can be grouped into categories depending on the type of information. Multiple decomposition dimensions exist and it not always clear which decompositions to apply and in which order. Intuitive design might modularize information in ways of infrastructure (abstract class hierarchies) vs. concrete content, views types or sub models, or semantic cohesion. With our reference structure, we propose as the primary decomposition a layering into: paradigm, domain, quality and analysis content. Paradigm ( ) is the most basic layer. It lays the the foundation of the language by providing structure but without semantics. The domain ( ) layer builds upon the paradigm and assigns semantics to its abstract structure. The quality ( ) layer adds quality properties to the domain concepts. Lastly, the analysis ( ) layer provides modules for input-, output- and internal state and configuration options for analyses. We settled for these layers, because they provided an intuitive primary decomposition in our research when inspecting metamodels for component-based architecture description languages and their intrusive and external extensions. The concern constellations of these layers (whereas not as explicit as proposed by our reference structure) can be found in metamodels like UML MARTE, the Descartes Metamodel and the PCM.
In the following subsections, we will explain the layers of the reference structure and gradually construct a modular metamodel of our example (PCM extended by maintainability) according to these layers. Please keep in mind, that this is a simplification and a reconstruction of the PCM. Thus, modeling of concepts and dependency directions partly do not adhere to the current PCM.
The most basic layer is the paradigm layer ( ). It defines foundational structure but without semantics. Thus, it is not directly usable. Not even for purposes which do not need dynamic semantics (e.g., documentation and communication). The minimal configuration of the metamodel which is meaningfully instantiable is and the domain layer put together. First class entities in should be abstract and no top level container (root) should be provided to avoid instantiation. Modules which cannot be instantiated directly, will be considered abstract modules. In our case constitutes components, interfaces and their composition. However, any is possible. It is dependent on the subject matter which is to be captured. E.g., object oriented design and behavioral formalisms.
In our example, encompasses the modules CoreEntities and Composition. This is illustrated in Figure 4. Please keep in mind that for the sake of presentation this is an extremely simplified depiction. Wherein Composition is dependent on CoreEntities. CoreEntities contains the abstract metaclasses Component and Interface. Like in the standard UML notation, abstract classes and abstract modules are indicated by a name in italic letters. A Component may reference various Interfaces in two ways: provide and require. The Composition module defines ComposedStructures which contain AssemblyContexts and Connectors. Connectors link Interfaces of two AssemblyContexts. An AssemblyContext represents an instance of a Component.
face Component 1
Composed Structure * *
Connector
2 Assembly Context Fig. 4. The
(Paradigm) Layer
The ComposedStructure extends Component. In the
illustration, the UML notation for stereotype application (a filled
arrow) is used. However, the implementation of this relation
does not necessarily have to be stereotyping. A wide range
of different extension mechanisms is available with all their
pros and cons. Further ones are annotation, plain inheritance,
and the application of patterns like the decorator pattern or
aspect-oriented extension [
The layer builds the foundation of the remainder of the metamodel. It is important, that is has no outgoing dependencies into other layers. This way, it can be reused on its own.
The domain layer ( ) extends and assigns domain semantics to its abstract first class entities. By doing so, new information (i.e, attributes and relations) can be added to the derived classes. New domain concepts may be created as well. However, if these new domain concepts have an overlap with classes of other modules in , or even of it should be considered to factor that content out into a higher, more general module or even a higher layer (i.e., in this case ). In the scope of this paper, will capture software systems. In general, any layer is possible. E.g., embedded and mechatronic systems or cyber-physical systems. The , however, has to fit the underlying layer.
The layer excerpt of the example scenario is illustrated in Figure 5. It features the ComponentRepository module, where the modeler can specify the Components and Interfaces of an architecture. Please keep in mind that the relation between Components and Interfaces is already defined in the layer. The ComponentRepository module assigns domain semantics to the abstract CoreEntities module of the layer providing concrete subclasses for its abstract classes. This separates the concerns of the structure of the paradigm (here component architecture) from its domain semantics, enabling the reuse of the paradigm structure. The Behavior module extends SoftwareComponents by a behavior abstraction, which is similar to a flowchart. The Behavior module is performance agnostic and is later used as a foundation for performance and reliability modeling. The Modification module is essential to the maintainability analysis. It defines Modifications of the architecture. Each concrete Modification references an element of the architecture. It further defines Propagations, which express how Modifications spread through an architecture.
The quality layer ( ) defines the inherent quality properties of concepts. It contains primarily second class entities, which enrich first class entities of . In the scope of this paper, the layer constitutes performance and reliability characteristics. Possible other modules which fit the and are: security and availability. Not in every circumstance a layer is needed. E.g., when the metamodel is only needed π
Repository
Component Repository
* Business
Component
∙ ∙ ∙
Mod Interface ModComp ∙ ∙ ∙
Component
Operation
Interface Infrastructure Component ∙ ∙ ∙
Mod Connector
∙ ∙ ∙ IntraComp Propagation ∙ ∙ ∙ Δ for specification of software design or for static analysis. This is the case for the KAMP maintainability analysis, which does not require information in the layer.
The quality properties have to be inherent and not derived. Inherent with respect to the analyses which can be performed on the model. E.g., when considering the PCM and performance, the response time of an operation depends on many things, like resource demands within the operation, response time of external calls and so on. Thus, the response time of an operation in this consideration is not an intrinsic value, but a derived one. Therefore, the response time of operations should be moved to a lower layer. There may be quality concepts which are needed to model derived properties. These should be specified in the layer. However, their instances should be contained in the layer. On the other side, the resource demand (not in terms of time but in load) is independent. It may be derived from an estimate or a real word software artifact, but with regards to the analyses it cannot be derived. Therefore, it belongs in and should be contained and specified there. If a model is used for solving, analysis or simulation, the model content from should remain static during execution. If that is not the case, the information belongs to the analysis layer, as it is derived or state information.
Figure 6 shows an excerpt of the exemplary layer. It contains the modules for Performance and Reliability. They extend InternalAction, and therefore the internal behavior of a Component, by ResourceDemand and FailureOccurence. A FailureOccurence has a probability, as well as a type. Here, an important advantage of the modularization shows. The behavior metamodule is free of performance and reliability data. As required, it can be extended by one of the two, or even both. Tools and developers are not bothered by irrelevant content. Potential future extensions can be created without the need for prearrangement. Δ
Resource Demand Internal Action
Ω
∙ ∙ ∙
Failure Occurence
Failure Probability
The analysis layer ( ) is only relevant, if models are used as a basis for analysis, solving or simulation (hereafter only referred to as analysis). provides new views to specify input state, configuration, run-time state and output of an analysis. These are all possible views, but only a subset may be required by an analysis. It is possible for multiple analyses to be founded on the upper layers. Several analyses may share modules, but also posses their own ones. In the focus of this paper, the layer is concerned with the performance simulation and the change impact analysis KAMP.
In Figure 7 an excerpt of the layer is shown. As a really simplified version of the performance result, here, a set of OperationResponseTimes is modeled. An OperationResponseTime has a unit, which is specified in the layer (the corresponding module was not shown in Figure 6). It further references the AssemblyContext and the Interface where the response time was recorded.
KAMP Input
Evolution Scenario
The in- and output for the KAMP maintainability prediction is on the left side of Figure 7. In this circumstance, the quality layer is not needed. Both modules merely hold a root container and reference directly into the layer. The EvolutionScenario of KAMP Input contains everything the analysis requires: seed Modifications, StaffSpecifications and DevelopmentArtifacts that belong to the architecture’s elements. The ImpactPropagation contains the predicted extend of the architecture change in the form of Propagations. The ImpactPropagation further references the input of the scenario to enable inference of affected artifacts and staff.
For an overview of all the modules of the scenario and
their dependencies, see Figure 8. The modules which convey
specific concerns are indicated by different levels of gray
(maintainability is dark, performance is medium, reliability
is light). The remaining modules cover more fundamental
concerns: component-based architecture and behavior. They
are the intersecting set of the metamodel elements of these
analyzes. The illustration may seem much more complex,
than the initial illustration in Figure 3. This is because in
the initial figure, all the concerns of performance, reliability,
behavior, and component architecture are contained in the big
PCM module. The original structure cannot be subdivided into
modules. At least not into modules according to the definition
in this paper, as the subpackages of the PCM have cyclic
dependencies (see [
This modular structure brings many benefits. External extensions now have a clean base to build on. E.g., a security extension can now be developed without having to deal with performance and reliability. In the modular structure, extension developers have to only understand the modules they extend and to some degree modules from which they are indirectly dependent. This increases the potential of reuse of the more basic (higher) modules. When evolving the metamodel, change impact can be traced down the graph, following the depen
Software
Components
Performance
Results
Performance Configuration Fig. 8. The Scenario Metamodel Restructured In Concordance to the Reference Structure dency relations. This way changes can be assessed much faster and more accurately.
There are approaches, which deal with the modularization,
categorization or structuring of related concepts. Coad’s UML
archetypes [
There is also related work, which aims at modularizing
concepts which are in direct interplay with metamodels.
Jung [
In this paper, we proposed a reference structure for
modular metamodels for component-based architecture description
languages. It proposes a layering of the information into
paradigm ( ), domain ( ), quality ( ) and analysis ( )
content. The reference structure is applied to the PCM [
Our reference structure propose modularization into layers and further into modules as well as making the dependencies explicit. Dependencies are constrained to avoid dependency cycles and improve modularization. Guidance for the modularization with regards to concerns is given. The reward is a more modular metamodel which allows for better compositionality of extensions. The improved modularity leads to a reduced complexity and all its benefits: better understandability, maintainability and reusability.
Future work include an in-detail examination of the possible extension mechanisms which can be used for the extension relation. Also, we plan to develop decision support for the grouping of classes and modules into the layers. Further, an extensive metamodel will be remade according to the reference structure and its correctness and completeness proven (e.g., by finding an isomorphism). An interesting question worth investigating is if different types of extension with regards to the interplay of abstract and concrete module have implication onto potential roots elements of view types.