Challenges in the Evolution of Metamodels: Smells and Anti-Patterns of a Historically-Grown Metamodel Misha Strittmatter Georg Hinkel Michael Langhammer Chair for Software Design and Software Engineering Division Chair for Software Design and Quality (SDQ) FZI Research Center of Quality (SDQ) Karlsruhe Institute of Information Technologies Karlsruhe Institute of Technology Karlsruhe, Germany Technology Karlsruhe, Germany hinkel@fzi.de Karlsruhe, Germany strittmatter@kit.edu langhammer@kit.edu Reiner Jung Robert Heinrich Software Engineering Group Chair for Software Design and Christian-Albrechts-University Quality (SDQ) Kiel Karlsruhe Institute of Kiel, Germany Technology reiner.jung@email.uni- Karlsruhe, Germany kiel.de heinrich@kit.edu ABSTRACT allow the addition of new features by creating metamodel In model-driven engineering, modeling languages are devel- extensions (which we will refer to as external extensibility). oped to serve as basis for system design, simulation and Some bad smells in metamodels make external extensions code generation. Like any software artifact, modeling lan- impossible. Other bad smells degrade a metamodels general guages evolve over time. If, however, the metamodel that maintainability. defines the language is badly designed, the effort needed for In this paper, we present the results of a thorough meta- its maintenance is unnecessarily increased. In this paper, model review of the PCM in the form of a list of bad smells. we present bad smells and anti-patterns that we discovered The PCM [26] is a metamodel to describe component-based in a thorough metamodel review of the Palladio Compo- software architectures with a focus on their performance nent Model (PCM). The PCM is a good representative for properties. It is implemented in EMF’s Ecore [29], which big and old metamodels that have grown over time. Thus, is an implementation of EMOF [24]. The metamodel is ap- these results are meaningful, as they reflect the types of proximately 10 years old and has been extended by features smells that accumulate in such metamodels over time. Re- over time. While later features have been extended exter- lated work deals mainly with automatically detectable bad nally, earlier additions were made intrusively. Thus, the smells, anti-patterns and defects. However, there are smells PCM is a representative specimen of a big, old and grown and anti-patterns, which cannot be detected automatically. over time metamodel. That is the reason why we think the They should not be neglected. Thus, in this paper, we focus results of our review are important to the community. They on both: automatically and non-automatically detectable show what type of smells typically accumulate in metamod- smells. els over time. Related work mainly focuses on the automatic detection of metamodel smells and simple defects of the metamodel. Keywords Being able to detect these problems automatically is im- metamodel smells; metamodel maintainability; metamodel portant. However, smells and anti-patterns that cannot be anti-patterns; Palladio Component Model automatically detected should not be ignored. Thus, be- sides four bad smells that can be automatically detected, we also present 6 smells which can only be detected man- 1. INTRODUCTION ually. This paper does not cover any metamodel defects, Model-driven engineering uses domain-specific modeling which break conformance to the meta-metamodel (compa- languages (DSMLs) to express abstractions of reappearing rable to compiler errors in programming). These defects are domain concepts. DSMLs can then be used to design sys- usually taken care of by the modeling frameworks validation tems. The resulting models (instances of DSMLs) can be functionality. analyzed and used for simulation. Depending on the DSML, This paper is structured as follows: Section 2 gives foun- its instances can be used for purposes ranging from stub gen- dational information about metamodels, their evolution and eration to the generation of fully functional code. DSMLs maintainability, anti-patterns and bad smells. Section 3 are defined by metamodels. presents the state of the art in evaluating metamodel qual- The evolution of metamodels is a big challenge, as they ity and detecting bad smells in metamodels. Section 4 will tend to be central artifacts with many tools that depend briefly give background information and present the internal on them. A change in a metamodel may cause many errors structure of the PCM. Section 4 will show how the PCM has in dependent code. Thus, it is important that metamodels 30 developed over the year. Section 5 contains the list of bad manually. As the PCM is a valid metamodel, metamodel- smells in the PCM. Section 6 concludes the paper. ing errors (which prevent the generation of the model code) will not appear in our list. For each smell we identified, we 2. FOUNDATIONS explain the characteristics of this smell, its consequences, reasons why they appeared in the PCM, how we think they In this paper, we are concerned with Essential Meta-Ob- can be best corrected, whether we can automatically detect ject Facility (EMOF)-conforming metamodels [24] (e.g. in- them and where they occurred in PCM. stances of the EMF’s Ecore meta-metamodel). A metamodel defines and constrains the set of its instances (i.e. models). In the sense of EMOF, a metamodel consists of metaclasses, 3. STATE OF THE ART which in turn contain relations and attributes. If the ele- EMF Refactor [2, 1] is a tool that can be used to au- ments of a model conform to the definitions in the meta- tomatically detect bad smells and perform refactorings in model, the model is an instance of the metamodel. EMOF- Ecore-based metamodels and UML models. They detect conforming metamodels are similar to UML class diagrams. bad smells either by a violation of a specific metric or by The differences are that they have to be complete and have the detection of an anti-pattern. For Ecore they feature to form a containment tree. automated detection of the following anti-patterns1 : Large The relations that can be defined in a metamodel connect EClass, Speculative Generality EClass, Unnamed EClass. two metaclasses. Attributes of metaclasses have only prim- They feature an even longer list for UML anti-patterns. Of itive types. Metaclasses are able to inherit from each other. these, some may also be applicable to Ecore metamodels. A special case of a relation is the containment relation. Each Elaasar [7, 8] developed an approach for automated detec- element of a model, except its roots, has to be contained tion of patterns and anti-pattern in MOF-based models. His in another element. A metamodel can be subdivided into approach provides a ready to use catalog with patterns spec- packages. A metamodel may also reference metaclasses of ifications but also supports the creation of new pattern spec- another metamodels. Constraints can be defined (e.g. using ifications by the user. His MOF anti-patterns are grouped the Object Constraint Language (OCL) [25]). in the categories well-formedness, semantic and convention. Metamodels evolve because their languages evolve. New López et al. propose a tool and language to check for prop- features have to be added, concepts have to be adapted, erties of metamodels [20]. In their paper, they also provide and bugs have to be fixed. A more detailed classification of a catalog of properties, which they categorize in: design metamodel evolution can be found in [31]. In our experience flaws, best practices, naming conventions and metrics. They with the PCM, the biggest driver is the inclusion of new check for breaches of fixed thresholds for the following met- features. rics: number of attributes per class, degree of fan-in and How easy it is to evolve a metamodel can be considered -out, depth of inheritance tree and the number of direct the maintainability of a metamodel. The maintainability is subclasses. influenced directly by a metamodel’s complexity and under- Vépa et al. present a repository for metamodels, models, standability. Understandability is not completely derived and transformations [35]. The authors apply metrics that from complexity, as it is possible to metamodel a simple were originally designed for class diagrams onto metamodels concept in a way which is not intuitive. The concepts of co- from the repository. For some of the metrics, Vépa et al. hesion [36] and coupling [4] can be transferred from object- provide a rationale how they relate to metamodel quality. oriented software development. The cohesion of a module Di Rocco et al. [6] applied metrics onto a large set of meta- is described as how related its classes are. Coupling of one models. Besides the usual size metrics, they also feature the module to another expresses how dependent the first module number of isolated metaclasses and the number of concrete is on the second. Both measures are heuristics for maintain- immediately featureless metaclasses. Further, they searched ability. A high cohesion is beneficial, as related classes tend for correlations of the metrics among each other. E.g., they to evolve together. A high coupling between packages is found that the number of metaclasses with superclass is pos- detrimental, because modifications may have a bigger im- itively correlated with number of metaclasses without fea- pact on dependents. tures. Based on the characteristics they draw conclusions In object-oriented software development, a bad smell [9] about general characteristics of metamodels. Their long- is considered an indicator for a possible problem in the soft- term goal is to draw conclusions from metamodel character- ware’s design or code. An anti-pattern was originally de- istics concerning the impact onto tools and transformations fined as being “... just like pattern, except that instead of that are based on the metamodel. a solution it gives something that looks superficially like a Gómez et al. [13] propose an approach, which aims at eval- solution, but is none.” [27]. However, the meaning of anti- uating the correctness and expressiveness of a metamodel. patterns changed over time to mean a recurring pattern that I.e. weather it allows invalid instances (correctness) and is has negative consequences [28, 14], regardless if it was pur- it able to express all instances it is supposed to (expressive- posely used or not. When transferring these terms to the ness). Their approach automatically generates a (preferably domain of metamodeling, some bad smells can be defined as small) set of instances to evaluate these two criteria. anti-patterns [2]. Other bad smells may be indicated by met- Garcı́a et al. [11] developed a set of domain specific meta- rics [2]. Some are only detectable by manual investigation. model quality metrics for multi-agent systems modeling lan- In the following, we will refer to bad smells in metamodels guages. They propose three metrics: availability, specificity as metamodel smells or simply smells. Metamodel smells and expressiveness. These metrics take domain knowledge may have various negative effects on metamodel maintain- into account, e.g., the “number of necessary concepts” or ability, which we will explain in this paper. In our list of the “number of model elements necessary for modeling the smells, we include automatically detectable smells, but even 1 more importantly smells which can only be reliably detected https://www.eclipse.org/emf-refactor/index.php 31 system of the problem domain”. as the concerns. For instance, the repository package con- There is much work on quality metrics for object-oriented tains all classes that are necessary to build a Repository design and UML class diagrams [5, 22, 21, 12]. Further, with its DataTypes and ComponentTypeHierarchy. How- there are publications that present empirical analyses of ever, some packages contain information for multiple con- object-oriented design metrics [3, 34]. E.g. Subramanyam cerns. found that the correlation between metrics and bug detec- tion varied when applied to different programming languages Legend Entity and observed interactions between metrics. The purpose and usage of object-oriented design and class diagrams is Concern Variable very different compared to metamodels, thus their benefit Characterization cannot be assumed for metamodels. Dependency Environment 4. THE PALLADIO COMPONENT MODEL Component DataTypes Composition The Palladio approach [26] is an approach to component- Type Hierarchy Repository based software engineering. At its core is the PCM, a meta- Allocation model, which defines a language to express component-based SEFF software architectures and abstractions of several quality as- pects. In this section, we present insights into the structure Usage Resource Model Types of the PCM. Resource The PCM is separated in different hierarchical packages. RDSEFF Environment The root package is called pcm and directly or indirectly Performance contains the remaining packages. In this paper, we consider Reliability packages, that are directly contained in the root packages as first level packages. Packages contained in first level pack- ages are considered as second level packages and so on. The Figure 2: The main concerns of the PCM [32] containment hierarchy of the packages is depicted in Fig- ure 1, while dependencies between the packages implied by inheritance of classes within the packages are depicted in Starting in August 2006, the PCM has a long evolution Figure 5. history. Since then, many new features have been added. Although Palladio initially was built for performance predic- tion, it now also supports to simulate reliability, data consis- pcm tency, energy consumption and maintainability. At the same core time, besides the original call characteristics, a system can now be specified in an event-based manner and PCM has entity built-in support for extensions in the form of stereotypes. composition qosannotations Total Number of Classes qos_performance 250 qos_reliability resourcetype 200 reliability 150 repository seff 100 seff_performance 50 seff_reliability system 0 resourceenvironment allocation subsystem Figure 3: Evolution of the Palladio Component usagemodel Model between March 2007 and September 2012 in parameter terms of the number of classes protocol Many of these perfective changes have had a footprint to the metamodel. Today, the version control system registers Figure 1: The package containment hierarchy of the more than 120 revisions of the core metamodel plus several PCM revisions for underlying shared functionality it is using. To give an impression on the evolution of the metamodel, we In [32], we identified different main concerns of the PCM, have depicted the total number of classes between spring which can be seen in Figure 2. The figure shows dependen- 2007 and fall 2012 in Figure 3. Most changes to the PCM cies how they should be, not how they actually are. As one were mad in this period and the metamodel size in terms of can see, in these two figures, the packages are mainly sliced number of classes has more than doubled. 32 5. METAMODEL SMELLS obfuscated that this is indeed a type check. In this Section, we will present the list of metamodel In some UML metamodels, associations are used where smells we found in the most recent version of the PCM. both ends are named, and one end is declared as composite. This version of the metamodel was released with the Pal- If this property of the UML metamodel must be preserved, ladio Bench 4.0. For each metamodel smell, the following an explicit container reference cannot be omitted. However, aspects will be elaborated: general description, its conse- such naming can exist only for documentary reasons, which quences, reasons for its forming, or even rationale why it allows ignoring them for the EMF mapping of the UML might have been purposefully used, possible resolutions, if metamodel. the smell is automatically detectable as well as brief men- tion of its occurrences in the PCM. In a smell’s description, Correction: The explicit container reference can be re- we will also briefly discuss the relation of a smell to object- moved and its usage in code can be replaced by accessing the oriented design and programming (OO). eContainer reference. If only the explicit container reference was used before, the eContainer reference can be safely cast 5.1 Redundant Container Relation to that container. If, however, the explicit container refer- ence is checked for null, the eContainer reference has to be Description: Containment relations are necessary to be checked for the type of the expected container. able to specify entities that are more complex and they guide serialization. To navigate models, it can be necessary to tra- Automatic Detection: Opposite references for containment verse from a contained element to the containing element. references can be detected automatically. For this purpose, the container reference can be used. In EMF, this feature is provided by a generic and implicit ref- Occurrences: In the PCM, 85 explicit container references erence eContainer. However, it is also possible to define an can be found with 17 of these references originating from the explicit container reference utilizing the concept of opposite aforementioned PCMRandomVariable. references. This smell does not exist in OO, as there are in general no 5.2 Obligatory Container Relation explicit containers. Objects are contained in the heap mem- ory and are merely referenced by other objects. If no more Description: This smell is a special case of the redundant references to an object exist, the object is eventually deleted. container relation smell (Section 5.1). If a containment re- In metamodeling and modeling on the other hand, an EOb- lation has an opposite reference that has a lower bound of ject must have a container. If that container is deleted, all 1, we call it an obligatory container relation. This is illus- contained elements are also deleted and all references to the trated in Figure 4. Class C1 contains A and the container deleted elements are unset. relation is obligatory. As with the redundant container re- lation smell, this smell is not relevant in OO, as there is no Consequence: This smell has several negative implica- explicit containment. tions. First, it introduces redundancy, as the implicit eCon- tainer reference is always present and an explicit container 1 * reference is a duplication. Second, it increases metamodel C1 A complexity due to this duplication. In case a class is used in different containments, multiple explicit container references * C2 exist. These references are all mutually exclusive, but this cannot be declared with EMF itself. Furthermore, the op- posite references must be declared as optional, which weak- Figure 4: Obligatory Container Relation for Classes ens their meaning. For example, the PCMRandomVariable C1 and A of the PCM metamodel is used in 17 contexts. Therefore, the class has 17 opposite references, but only one is used by an instance. Third, the explicit container reference can Consequence: A cannot be used in any other context. E.g., harm reuse and evolution of metamodels. In case a con- although C2 has a containment relation to A, an instance of tainer class is added or removed, this always also requires C2 can never contain any instances of A, as the container the adaption of the contained class. In case different as- relation to an instance of C1 has to be set. In such cases, pects and partitions of metamodels are stored separately, the EMF framework does not even allow code generation. a cyclic reference between the metamodel of the contain- ing class and the contained class is necessary. This hinders Reason and Rationale: There are some reasons to use an reuse, as both metamodels must be present. However, using obligatory container relation. It ensures type safety when an implicit eContainer reference, the metamodel with the navigating to the container. It is also possible, that the de- contained class can be reused in other contexts. velopers want to restrict reuse explicitly. However, in most circumstances the developers were most likely unaware of Reason and Rationale: Some may argue that container these consequences. Obligatory container relations can also references allow ensuring static type safety. However, this be the result of translation from another format or language only applies for cases with only one container reference and (e.g., UML) by a transformation. realized in Java directly. In case of multiple containing classes, the static type safety property is weakened, as the Correction: To fix this smell, remove the container rela- containing class type cannot be determined statically. In- tion (this will also resolve the redundant container smell). stead, at runtime each property must be checked which is As the class could only be in one type of container, the eCon- similar to testing the type of the containing class, but it is tainer can be safely cast to that container class. 33 Automatic Detection: Obligatory container relations can Automatic Detection: This bad smell is not automatically easily be detected. However, manual evaluation is still re- detectable. An algorithm is not able to automatically infer quired, as in some cases they may be intended by the devel- the semantics of parts of the metamodel. oper. Occurrences: It is difficult to nail down the exact number Occurrences: In the PCM, many container relations are of occurrences in the PCM, as this depends on how fine- obligatory. We suspect this to be the result of the transfor- grained its concerns are identified. Looking at quite coarse- mation from Rational Software Architect. grained concerns, there are at least six occurrences of this smell in the PCM [32]. The following concerns are affected: 5.3 Concern Scattered in Package Hierarchy resource interfaces, middleware infrastructure, performance, repository (especially interfaces), event communication and Description: The package hierarchy of a metamodel is reliability. mainly for logical partitioning of its content. We consider it a bad smell, if the classes that constitute a feature or concern of the language are spread over multiple packages. 5.4 Multiple Concerns in Package Even crosscutting concerns can be modularized in a more Description: Conversely to the scattered concern smell, meaningful way. we also consider it a smell, if a package contains the classes In OO, there are issues similar to this smell, e.g., when of multiple concerns. The relation of this smell to OO is cohesive classes are scattered over packages or assemblies. analog to the scattered concern smell. Insufficient modular- However, to our knowledge, there is no explicit smell that ization on the package level is an issue in OO. However, we covers the problem on this level. OO smells are more con- are not aware of an explicit smell definition. cerned with the internals of packages: relations between classes and the internals of classes and methods. Consequence: Having multiple concerns in one package, increases the effort to understand the package, because the Consequence: This bad smell has negative consequences developer has to identify the contained concerns and their on the understandability and thus maintainability of meta- respective classes. Simply put, the package is needlessly models. When a developer tries to understand a metamodel, complex. This bad smell might also decrease the cohesion he examines its packages and from their content and docu- within the package. mentation (if there is any) tries to conclude its purpose. If a concern is scattered, the purpose of the package cannot Reason and Rationale: We suspect that this smell has two be fully comprehended without tracing relations that leave explanations. Developers tend to place classes in packages, the package. The smell may also increase coupling between which hold their container or represent a closely related con- affected packages and reduce relative cohesion within the cern. It is just more convenient to use the existing package packages. hierarchy than to think of a new structure yourself. Reason and Rationale: We suspect that this smell occurs Correction: How to modularize and package concerns is mostly, when new concerns are implemented in an already already well explained in the resolution part for the scat- existent metamodel. The new concern is related to the con- tered concern smell (see Section 5.3). As already suggested, cerns of multiple other packages. Parts of the new concern new concerns should be placed in their own package. If a are then placed in the packages of the related concerns and concern is a subconcern, then its package should be placed so the new concern is ripped apart. as a subpackage. Correction: A better approach would be to place the new Automatic Detection: This bad smell is not automatically concern in its own package. The package should further detectable. An algorithm is not able to automatically infer contain sub-packages for each related concern, which then the semantics of parts of the metamodel. contain the classes that are related to these concerns. The package of the new concern should be placed meaningfully. Occurrences: There are at least two occurrences of this If it is a first order concern, it should be placed below the smell in the PCM [32]. The following concerns are affected: root package. If it is a subconcern, its package should be data types and the abstract component type hierarchy, which placed as a subpackage of the parent concern. If it is a both are located in the repository package. crosscutting concern, it should be placed on the same level, as the concerns it is intersecting with. 5.5 Package Dependency Cycles Moving classes can be done through refactorings. Even Description: When creating a metaclass, one of the most the code, which depends on the classes, may be automat- important choices is the selection of appropriate base classes, ically fixed. A mere moving of affected classes may lead from which some functionality can be reused. However, in- to other bad smells, if the dependencies are not modified. heritance is a white-box technique. Therefore, one needs The new dependencies between packages may lead to pack- to fully understand the base classes. Hence, a closer look age dependency cycles (see Section 5.5) and violations of into the containing packages is required. This dependency the dependency inversion principle on the package level (see between packages implied by inheritance can be shown vi- Section 5.6). This is not the fault of consolidating a concern, sualized as a graph. We depicted this graph for the latest but of dependencies that were improper in the first place. PCM version in Figure 5. This graph may contain cycles An explicit reference structure (e.g., [33, 30]) can help in (shown in red). structuring packages and directing their properties properly. In OO, having dependency cycles in assemblies is consid- 34 Part a) of Figure 6 shows a violation of the principle on the class level. Package H contains high-level concepts, relative to which the content from the package L is low-level. Class A has a dependency (relation, inheritance or containment) to K. Thus, a high-level class is dependent on a low-level one. Class K contains further information about A (indicated by the data attribute). Although it is illustrated as a single at- tribute, this information may come in the form of attributes, relations and containments. Consequence: A violation of the dependency inversion principle may have detrimental effects on the maintainabil- ity of a metamodel. During evolution, modifications of a concern may influence a more high-level concern. Such vi- Figure 5: Dependencies between packages in PCM olations do also hinder understanding. When a developer implied by inheritance of classes, thickness of arrows tries to understand a concern, he may trace the outgoing indicates how many classes use an inheritance rela- relations to more low-level concerns. Thus, he may exam- tion, cycles are marked in red. ine concerns which are not necessary for understanding the high-level concern or even irrelevant to his intent. ered a bad practice, or is even treated as an error on some Reason and Rationale: In our opinion, these violations platforms. However, there is not so much emphasis placed stem from the integration of features. It is most conve- on dependency cycles on the package level. nient for a developer to extend an existing class hierarchy by adding dependencies that point to the new content. How- Consequence: A consequence of such a circular depen- ever, there is a difference between object-oriented design and dency may be that to fully understand a package contained metamodels. In OO, it is easier and more natural to intro- in such a circle, a developer has to understand all packages duce new abstraction layers. In metamodels, on the other contained in this circle. This challenges the appropriateness hand, interfaces cannot be used in a similar way, because of the package structure. usually it is not similar functionality that is added, but new Especially if the cycle is formed from inheritance depen- and different data. At first glance, it seems to be a good so- dencies, the maintainability of the metamodel may suffer. lution just to create a new subclass, which adds the needed Changes made to the metamodel propagate down the class information. However, when multiple new features are im- hierarchy and thus into other packages where they should plemented this way, they cannot be combined. Therefore, not. in metamodeling, it can be reasonable to violate the depen- dency inversion principle in certain cases. A possible rule Reason and Rationale: PCM makes extensive use of mul- would be to do so for core features of the language. A fea- tiple inheritance and the inheritance hierarchy of some meta- ture can be considered a core feature, if it is useful in every classes is quite high. Therefore, it may have become difficult use case of the language and for every possible type of user. to keep an eye on package dependencies. Core features should be integrated intrusively into the meta- model with a violation of dependency inversion principle. Correction: In situations when developers have lost an This has the following advantages: type safety, adherence overview of the package dependencies, we think that an to cardinality and retrieval in O(1) (constant time). overview such as in Figure 5 can already be helpful to avoid this anti-pattern. Correction: When implementing non-core features, the dependency inversion principle should be used. In Figure 6, Automatic Detection: A circular dependency can be de- we point out two possible options. tected automatically (in fact, Figure 5 is entirely generated In b), the new abstract class B is created as well as a con- by a tool) and could be even automatically resolved by merg- ing the affected packages. However, we think a manual in- spection can be more beneficial in such a scenario. H a) b) c) Occurrences: The occurrences of this pattern in the latest A A B A High-Level version of Palladio is shown in Figure 5. Concepts 5.6 Dependency Inversion Principle Violated L Description: The dependency inversion principle [23] is Low-Level a design principle from OO. When translated to metamod- K K K eling it states that high-level classes should not depend on Concepts low-level classes (high- and low-level regarding the level of data data data abstraction). Both may depend on abstractions. The same can be said about packages and even metamodels, when the dependencies of a package or metamodel are regarded as the Figure 6: Violation and Application of the Depen- combined dependencies of their elements. dency Inversion Principle 35 tainment from A to B. Class K then inherits from B. Thus, the dependency is reversed and now goes from L to H. This Automatic Detection: It is possible to statically detect solution has some benefits. The instances of K are con- that a class cannot be contained in another class. However, tained in instances of A. This enables direct navigation and a manual assessment is then required to decide whether this thus retrieval in constant time. In addition, the cardinality class is dead, as for root container classes, it is viable (though can be controlled directly without having to specify complex not obligatory) to be uncontainable. constraints. However, type safety is not guaranteed, as the extended data is not placed in B but in K. This solution has Occurrences: A static analysis of PCM delivers in to- to be enabled in the initial development, as the class B is tal nine uncontainable classes. From these, the classes Us- required. This is no issue, if K is also already created during ageModel, Repository, ResourceRepository, System, Re- the initial development or if the future extension of K can sourceEnvironment and Allocation represent view types be foreseen. The main disadvantage of this solution is that and therefore serve as model roots. Thus, it is perfectly H has to be modified, if this solution should be implemented valid for them to be uncontainable. The class DummyClass in hindsight. has been introduced to overcome a technical limitation in In c), an alternate solution is shown which does not re- the QVT-O compiler, but this is a rather different issue (the quire modification of H. By either stereotype application [18, purpose of this class is hardly documented, but developers 17], aspect-oriented extension [15, 16] or plain referencing, trying to understand PCM would not expect any reasonable instances of K can be associated with instances of A. Com- semantics from a class named like this). However, over the pared to b) this has the disadvantage, that the look-up is in history, two classes have been left over from refactoring op- O(k), where k is the number of instances of K. erations, CharacterisedVariable and ResourceInterface- ProvidingRequiringEntity. For both of these cases, it is Automatic Detection: This smell is not automatically de- not obvious that they are no longer needed, so developers tectable. An algorithm is not able to deduce if concepts are may try to find usages and fail to do so. higher- or lower-leveled compared to others. 5.8 Concrete Abstract Class Occurrences: Within the PCM is at least one serious oc- Description: This smell is concerned with classes that currence of this smell with regard to the inheritance hierar- should be abstract, but are not. Usually, in a class hier- chy. The superclass that represents entities that require and archy, a class with subtypes is abstract. However, not every provide interfaces, inherits from a superclass which repre- occurrence is necessarily bad design, as sometimes even a sents entities which require and provide resource interfaces. concrete class might have concrete subclasses. While the usage of interfaces is a core feature of the PCM, In OO, having a concrete abstract class is also a problem. resource interfaces are not. Regarding violations with ref- However, we are not aware of an existing smell definition. erences, there are countless occurrences. They stem from the intrusive integration of features into more abstract con- Consequence: However, if a class that should be abstract cepts. is not declared as such, this has a negative impact on the metamodels correctness and understandability. Due to the 5.7 Dead Class fact, that an instance of the metamodel may validly contain Description: As a result of a refactoring, in some cases direct instances of a class that should not have any instances, a class is no longer required as its responsibilities are taken the metamodel is less correct. Usually this problem is hid- care of by another class. Sometimes, although the references den by self-built model editors, which just do not offer any to the class are deleted, the class itself is not. In OO, this possibility to create direct instances of the affected class. smell falls under the category of dead code or oxbow code. However, using fully generated model editors (like the EMF tree editors), this problem does manifest. Further, the un- Consequence: This has a negative impact on understand- derstandability of the metamodel is slightly reduced by this ability since the class has to be considered, even though it smell. A developer, who investigates the metamodel, can- cannot be contained in the rest of the model. Furthermore, not instantly identify the class as abstract and has to reflect. developers may have a hard time trying to understand how the class is used. When they finally find out that it is not Reason and Rationale: We expect this smell to appear used at all, this has an impact on their opinion of the meta- mainly because of carelessness mistakes. model. Correction: The correction of this smell is trivial. The Reason and Rationale: The pattern is mainly a result of affected class just has to be declared as abstract. bad metamodel reuse. As the metamodel gets large, it is no longer obvious in which places a class is used. Thus, Automatic Detection: Occurrences of this smell can only when the class is no longer required in one specific scenario, partly be detected automatically. When a concrete class has it still may be required in another. However, as developers subclasses, it might be a true case of this smell [2]. If any of do not check whether the class is used in some other place, the subclasses are abstract, it is even more likely that there the class may be left behind with no usage elsewhere in the is an issue. However, manual evaluation is still required, as it metamodel. might be the case that the superclass is validly concrete. In constellations, where all subclasses of the concrete abstract Correction: This problem can be avoided if developers class are in external metamodels, the smell is not detectable make sure that classes they no longer need are either still if the external metamodels are not analyzed. This smell used elsewhere or deleted. might lead to wrongful detections of the dead class smell 36 (5.7). This is the case when the class and its superclasses the detection may result false positives and false negatives. are never used within the metamodel but carry the informa- First, there could be identical typed and named features tion of an abstract concept that should be specialized in an that do not represent the same relationship. Second, fea- external metamodel. tures may be named differently, but still represent the same idea. Therefore, manual intervention is required. Occurrences: Within the PCM, the CallReturnAction class from the SEFF package is a true occurrence of the con- Occurrences: In the PCM, the classes OperationSigna- crete abstract class smell. It is a concrete superclass and ture, InfrastructureSignature and EventType have all cannot be instantiated by the custom build graphical model a property returnType with the same intended semantic. editors of the PCM bench. This class cannot be meaning- These could be extracted into an IValueReturning inter- fully instantiated, as it or its superclasses have no container. face, which is inherited by the three classes. However, it can still be confusing for a developer. 5.10 Classification by Enum 5.9 Duplicate Features in Sibling Classes Description: If an enum is used as an alternate way to Description: In metamodels, classes represent concepts classify a class, we consider it a bad smell. This should not and inheritance is used to specialize concepts by providing a be confused with using an enum to model a mere property. more comprehensive specification. For example, an abstract Using an enum for classification is one possible solution component type only describes that a component type has of how to model multiple orthogonal classifications. Part a) an interface. This class can be specialized into a component of Figure 7 illustrates the problem. It should be possible to type that allows having internal components. In case a class classify the class Base as either A1 or A2 and additionally has multiple children, of which some realize the same feature, either as B1 or B2. This is not possible by just using an this can be seen as a redundancy in the model. inheritance hierarchy of the depth of just one. Part b) of In OO, one could argue that this issue falls under the du- Figure 7 shows a solution by using an enum for the second plicate code smell [9]. classification dimension. Consequence: Redundant declarations harm maintainabil- Base Base Base BType ity, as they must be maintained equally in all classes. If one a) «enum» class is overlooked, the metamodel degrades, which hinders BType long time evolution of the metamodel. They also have a neg- b1 B1 ative impact on implementing transformations, as for each A1 A2 B1 B2 b2 B2 sibling class, the transformation rule must be able to support the feature. This is necessary, as from a syntactic viewpoint a1 a2 b1 b2 b) on the model these features are different. Aspect A Aspect B A1 A2 Reason and Rationale: Duplicated features can appear when metamodels are altered iteratively. In that case, one a1 a2 of the sibling classes is extended with a specific feature, and later another sibling is extended in the same way. Through Figure 7: a) Problem of Orthogonal Classifications this process, more and more classes have a semantically iden- b) Classification by Enum tical feature, but they are declared syntactically as different features. While in some cases this situation may be the ef- fect of limited time, carelessness, or overlooked, it can also The naive solution to modeling orthogonal classifications be made intentional. The latter case occurs when not all is shown in Figure 8. There, every possible combination is siblings require the feature. explicitly modeled by inheritance. This obviously has sev- eral disadvantages. It produces high amounts of classes. Correction: To mitigate the issue of duplicate features, Although, a single classification dimension is externally ex- in OO, a refactoring would move the feature up to the par- tensible, it is not possible to develop independent extensions, ent class in case all siblings have the feature [19]. However, as every combination of every dimension has to be modeled. this can be in violation with the underlying semantics of the concepts, which are expressed in the classes. Furthermore, Base the pull up cannot be used in cases where not all, but some siblings declare the same feature. An alternative strategy A1 A2 is to define an interface that provides the feature in ques- tion and inherit the interface by all siblings that require the A1B1 A1B2 A2B1 A2B2 particular feature. The strategy has two advantages. First, the meaning of the feature is encapsulated in its own con- B1 B2 cept. Second, the interface can be used in transformations. Therefore, the transformation must only test whether the interface exists instead of testing multiple classes. Figure 8: Naive Solution to Orthogonal Classifica- tions Automatic Detection: An automatic detection of dupli- cations based on name and type is unreliable, as the de- In OO, classification by enum is also a problematic solu- tection is based only on syntactic properties. Therefore, tion to the problem of orthogonal classification dimensions. 37 However, we are not aware of any bad smell definition. included, as the PCM is already in operation and thus does not contain any. Consequence: Using an enum for additional classifica- Two of the presented smells are exclusive to metamod- tions makes the classification impossible to extend exter- els. The remaining eight smells also represent issues in OO. nally. Further, in contrast to classification by inheritance, it However, there are differences in the usage of metamodeling, is not possible to add features to parts of the classification OO design and code. Therefore, in OO there is not as much selectively. This might lead to the developer adding features emphasis on the smells which were presented here. to the base class, which are only used for specific values of The smells presented in this paper are specific to lan- the enum. By doing that, the complexity of the class in- guages that are similar to EMOF. All smells are concerned creases unnecessarily and its understandability suffers. This with the following basic concepts: classes, relations and is shown in part b) of Figure 7. attributes. Some smells are concerned with more specific meta-language features: explicit containments (5.1, 5.2), Reason and Rationale: As already stated, using an enum modularization (5.3, 5.4, 5.5), inheritance (5.8, 5.9) and for classification is one possible solution of how to model enums (5.10). multiple orthogonal classifications. In most situations, how- Four of the smells might be detected by scanning for anti- ever, it is not a very suited one. Developers use it because patterns. However, all of them still have to be reviewed, of lack of knowledge of more appropriate solutions. In ad- as there are circumstances where an occurrence is not nec- dition, it looks simple and little intrusive compared to the essarily bad design. The remaining six smells can only be naive approach (see Figure 8). If, however, the developer detected by manual review. wants one classification to be closed for extension and it For each smell, we explain how it might come into be- does not carry any new features that vary for its subtypes, ing. Some smells are built in by mere carelessness or lack of classification by enum can be legitimately used. knowledge. Therefore, knowledge of these metamodel smells is very valuable for metamodel developers. Other smells, Correction: There are two ways to resolve this smell. If however, do only manifest with time, when multiple evolu- the classification is already known when the metamodel is tion steps have been performed (some of them in a short- initially implemented, or it is possible to modify the meta- sighted manner). model, the composition over inheritance principle [10] should For each smell, we explained the effects we observed and be applied. This is shown in part a) of Figure 9. If not, further consequences that we expected. Some smells add un- stereotypization should be applied. This is shown in part b) necessary complexity. Others simply impair understandabil- of Figure 9. ity by obfuscating design decisions or the intended structure of the metamodel. Some have negative effects on coupling Automatic Detection: This smell is not automatically de- and cohesion of packages. Thus, these metamodel smells tectable. One could scan for each usage of an enum. How- have detrimental effects on metamodel maintainability. The ever, not every usage is a classification. Therefore, each consequences are even worse, if the metamodel is long living, enum usage has to be checked manually. is evolved and the smells accumulate without being fixed. Metamodels tend to live in metamodel-centric software sys- tems. Many tools, like editors, analyzers and simulators, Base B Base b) are built upon them. If the metamodel is changed, all tools A1 A2 have to be fixed. The effort caused by resolving smells in B1 A the metamodel increases over time, as new dependencies pile up. Thus, smells should be fixed as early as possible. A1 A2 B2 B1 B2 Future work includes inspecting further metamodels also a) including less mature ones. Further, results from smell and B error detection tool could be incorporated and analyzed. Figure 9: Solutions to Orthogonal Classifications 7. ACKNOWLEDGMENTS This work was supported by the Helmholtz Association of German Research Centers and the DFG (German Research Occurrences: In the PCM, the classification by enum oc- Foundation) under the Priority Program SPP1593: Design curs in the class ImplementationComponentType. It con- For Future – Managed Software Evolution. We would like to tains an enum that declares its component type: business thank Anne Koziolek, Richard Rhinelander, Kiana Rostami, component or infrastructure component. This classification Dominik Werle, Kateryna Yurchenko and the anonymous is orthogonal to the classification of atomic vs. composite, peer-reviewers for their valuable input. which is implemented by inheritance. This enum makes it impossible to add further component types without intru- References sively modifying the PCM. [1] T. Arendt and G. Taentzer. “A tool environment for quality assurance based on the Eclipse Modeling 6. CONCLUSION Framework”. In: Automated Software Engineering 20.2 Within this paper, we presented a list of metamodel smells (2013), pp. 141–184. we found in the current version of the PCM. We identified [2] T. Arendt et al. “Defining and checking model smells: 10 different types of smells. Simple metamodel errors (which A quality assurance task for models based on the cause validation errors and prohibit code generation) are not 38 eclipse modeling framework”. In: BENEVOL work- [20] J. J. López-Fernández et al. “Assessing the Quality of shop. 2010. Meta-models”. In: Proceedings of the 11th Workshop [3] V. Basili et al. “A validation of object-oriented design on Model Driven Engineering, Verification and Vali- metrics as quality indicators”. In: Software Engineer- dation (MoDeVVa). 2014, p. 3. ing, IEEE Transactions on 22.10 (Oct. 1996). [21] M. Manso et al. “No-redundant Metrics for UML [4] P. Bourque et al. Guide to the software engineering Class Diagram Structural Complexity”. In: Advanced body of knowledge. IEEE, 2014. Information Systems Engineering. Vol. 2681. Lecture Notes in Computer Science. Springer Berlin Heidel- [5] S. R. Chidamber and C. F. Kemerer. “Towards a Met- berg, 2003, pp. 127–142. rics Suite for Object Oriented Design”. In: SIGPLAN [22] M. Marchesi. “OOA metrics for the Unified Modeling Not. 26.11 (Nov. 1991), pp. 197–211. Language”. In: Proceedings of the Second Euromicro [6] J. Di Rocco et al. “Mining Metrics for Understanding Conference on Software Maintenance and Reengineer- Metamodel Characteristics”. In: Workshop on Model- ing. Mar. 1998, pp. 67–73. ing in Software Engineering. ACM, 2014. [23] R. Martin. Agile Software Development: Principles, [7] M. Elaasar. “An approach to design pattern and anti- Patterns, and Practices. PH, 2003. pattern detection in mof-based modeling languages”. [24] Object Management Group (OMG). MOF 2.4.2 Core PhD thesis. Carleton University Ottawa, 2012. Specification (formal/2014-04-03). 2014. [8] M. Elaasar et al. “Domain-Specific Model Verification [25] Object Management Group (OMG). Object Constraint with QVT”. In: ECMFA. Springer, 2011. Language, v2.0 (formal/06-05-01). 2006. [9] M. Fowler et al. Refactoring: Improving the Design of [26] R. H. Reussner et al. Modeling and Simulating Soft- Existing Code. Addison-Wesley, 1999. ware Architectures – The Palladio Approach. to ap- [10] E. Freeman et al. Head First Design Patterns. Head pear. Cambridge, MA: MIT Press, Oct. 2016. 408 pp. First. O’Reilly Media, 2004. [27] L. Rising. The Patterns Handbook: Techniques, Strate- [11] I. Garcı́a-Magariño et al. “An evaluation framework for gies, and Applications. SIGS, 1998. MAS modeling languages based on metamodel met- [28] C. U. Smith and L. G. Williams. “Software perfor- rics”. In: Agent-Oriented Software Engineering (2009). mance antipatterns”. In: Workshop on Software and [12] M. Genero et al. “Building measure-based prediction Performance. 2000, pp. 127–136. models for UML class diagram maintainability”. En- [29] D. Steinberg et al. EMF: Eclipse Modeling Framework. glish. In: Empirical Software Engineering 12 (5 2007). second revised. Eclipse series. Addison-Wesley Long- [13] J. J. C. Gómez et al. “Searching the Boundaries of man, Amsterdam, Dec. 2008. a Modeling Space to Test Metamodels”. In: Software [30] M. Strittmatter and R. Heinrich. “A Reference Struc- Testing, Verification, and Validation, 2008 Interna- ture for Metamodels of Quality-Aware Domain-Specific tional Conference on (2012), pp. 131–140. Languages”. In: 13th Working IEEE/IFIP Conference [14] K. Julisch. “Understanding and overcoming cyber se- on Software Architecture. Apr. 2016, pp. 268–269. curity anti-patterns”. In: Computer Networks 57.10 [31] M. Strittmatter and R. Heinrich. “Challenges in the (2013), pp. 2206–2211. Evolution of Metamodels”. In: 3rd Collaborative Work- [15] R. Jung et al. “A Method for Aspect-oriented Meta- shop on Evolution and Maintenance of Long-Living Model Evolution”. In: Proceedings of the 2Nd Work- Software Systems. Vol. 36. Softwaretechnik-Trends 1. shop on View-Based, Aspect-Oriented and Ortho- 2016, pp. 12–15. graphic Software Modelling. VAO ’14. York, United [32] M. Strittmatter and M. Langhammer. “Identifying Kingdom: ACM, July 2014, 19:19–19:22. Semantically Cohesive Modules within the Palladio [16] R. Jung et al. “GECO: A Generator Composition Ap- Meta-Model”. In: Symposium on Software Perfor- proach for Aspect-Oriented DSLs”. In: Theory and mance. Universitätsbibliothek Stuttgart, Nov. 2014, Practice of Model Transformations: 9th International pp. 160–176. Conference on Model Transformation, ICMT 2016. [33] M. Strittmatter et al. “A Modular Reference Structure Springer International Publishing, 2016, pp. 141–156. for Component-based Architecture Description Lan- [17] M. E. Kramer et al. “Extending the Palladio Compo- guages”. In: Model-Driven Engineering for Component- nent Model using Profiles and Stereotypes”. In: Palla- Based Systems. CEUR, 2015, pp. 36–41. dio Days 2012. Ed. by S. Becker et al. Karlsruhe Re- [34] R. Subramanyam and M. Krishnan. “Empirical analy- ports in Informatics ; 2012,21. Karlsruhe: KIT, Faculty sis of CK metrics for object-oriented design complex- of Informatics, 2012, pp. 7–15. ity: implications for software defects”. In: IEEE Trans- [18] P. Langer et al. “EMF Profiles: A Lightweight Exten- actions on Software Engineering 29.4 (2003). sion Approach for EMF Models”. In: Journal of Object [35] E. Vépa et al. “Measuring model repositories”. In: Pro- Technology 11.1 (2012), 8:1–29. ceedings of the 1st Workshop on Model Size Metrics. 2006. [19] K. Lano and S. K. Rahimi. “Case study: Class diagram restructuring”. In: Proceedings Sixth Transformation [36] E. Yourdon and L. L. Constantine. Structured Design: Tool Contest, TTC 2013, Budapest, Hungary, 19-20 Fundamentals of a Discipline of Computer Program June, 2013. 2013, pp. 8–15. and Systems Design. 1st. Prentice-Hall, 1979. 39