Clean Code: Ketterien ohjelmointikäytäntöjen hyödyntäminen pelikoodin analysoinnissa

Agility in software development means being able to adapt to ever-changing requirements. A major factor in agility is keeping the codebase easy to read and to extend. This kind of code is commonly called "clean code". Clean code is simple, elegant, and does not repeat itself. Writing clean code means that the cost of adding, changing, and removing features is kept to a minimum. It front-loads more of the work into the design stages of development, where it is cheaper both financially as well as mentally. This thesis describes some of the main principles of clean code and shows how they can be used in analyzing game code. The game under scrutiny is The Last Cube, a large-scale puzzle game project in which the author is the lead programmer. The game has been in development in the Unity game engine over 3 years. Parts of the code of The Last Cube are described and then analyzed using various methods and tools. The analysis of the code revealed hundreds of major violations of the clean code principles listed in the thesis, including problems with coupling, complexity, and duplication. The problems are analyzed and discussed. One instance of coupling is taken under closer scrutiny and analyzed further. The section is then refactored, improving the section’s maintainability and reducing coupling.Ohjelmistokehityksessä termi "ketteryys" viittaa kykyyn sopeutua alati muuttuviin vaatimuksiin. Yksi suurimmista tekijöistä ketteryydessä on koodin luettavuus ja laajennettavuus. Tällaista koodia kutsutaan usein termillä "clean code"eli "puhdas koodi". Puhdas koodi on yksinkertaista ja eleganttia, eikä se toista itseään turhaan. Puhtaan koodin kirjoittaminen auttaa pitämään toiminnallisuuksien lisäämisen, muuttamisen ja poistamisen kulut minimissä. Käyttämällä enemmän aikaa työn suunnitteluvaiheissa, ohjelmointi on helpompaa sekä taloudellisesti että henkisesti. Tämä työ kuvaa puhtaan koodin pääperiaatteita ja esittelee niiden käyttöä pelikoodin analysoinnissa. Tutkittava peli on The Last Cube, suuren mittakaavan pulmapeliprojekti, jossa työn kirjoittaja on pääohjelmoijana. Peliä on kehitetty Unity-pelimoottoriin pohjautuen yli kolmen vuoden ajan. Osia The Last Cube -pelin koodista esitellään ja analysoidaan käyttäen erilaisia metodeja ja työkaluja. Koodin analysointi paljasti satoja kohtia, joissa työssä esiteltyjä puhtaan koodin periaatteita oli rikottu. Löytyneitä ongelmakohtia esitellään ja analysoidaan, ja erästä funktiota tarkastellaan lähemmin ja lopulta muutetaan puhtaammaksi. Muutoksen jälkeen tehdyn analyysin mukaan funktio on lyhyempi sekä huomattavasti parempi ylläpidettävyyden kannalta

State of Refactoring Adoption: Towards Better Understanding Developer Perception of Refactoring

Context: Refactoring is the art of improving the structural design of a software system without altering its external behavior. Today, refactoring has become a well-established and disciplined software engineering practice that has attracted a significant amount of research presuming that refactoring is primarily motivated by the need to improve system structures. However, recent studies have shown that developers may incorporate refactoring strategies in other development-related activities that go beyond improving the design especially with the emerging challenges in contemporary software engineering. Unfortunately, these studies are limited to developer interviews and a reduced set of projects. Objective: We aim at exploring how developers document their refactoring activities during the software life cycle. We call such activity Self-Affirmed Refactoring (SAR), which is an indication of the developer-related refactoring events in the commit messages. After that, we propose an approach to identify whether a commit describes developer-related refactoring events, to classify them according to the refactoring common quality improvement categories. To complement this goal, we aim to reveal insights into how reviewers develop a decision about accepting or rejecting a submitted refactoring request, what makes such review challenging, and how to the efficiency of refactoring code review. Method: Our empirically driven study follows a mixture of qualitative and quantitative methods. We text mine refactoring-related documentation, then we develop a refactoring taxonomy, and automatically classify a large set of commits containing refactoring activities, and identify, among the various quality models presented in the literature, the ones that are more in-line with the developer\u27s vision of quality optimization, when they explicitly mention that they are refactoring to improve them to obtain an enhanced understanding of the motivation behind refactoring. After that, we performed an industrial case study with professional developers at Xerox to study the motivations, documentation practices, challenges, verification, and implications of refactoring activities during code review. Result: We introduced SAR taxonomy on how developers document their refactoring strategies in commit messages and proposed a SAR model to automate the detection of refactoring. Our survey with code reviewers has revealed several difficulties related to understanding the refactoring intent and implications on the functional and non-functional aspects of the software. Conclusion: Our SAR taxonomy and model, can work in conjunction with refactoring detectors, to report any early inconsistency between refactoring types and their documentation and can serve as a solid background for various empirical investigations. In light of our findings of the industrial case study, we recommended a procedure to properly document refactoring activities, as part of our survey feedback

An approach to safely evolve preprocessor-based C program families.

Desde os anos 70, o pré-processador C é amplamente utilizado na prática para adaptar sistemas para diferentes plataformas e cenários de aplicação. Na academia, no entanto, o pré-processador tem recebido fortes críticas desde o início dos anos 90. Os pesquisadores têm criticado a sua falta de modularidade, a sua propensão para introduzir erros sutis e sua ofuscação do código fonte. Para entender melhor os problemas de usar o pré-processador C,considerando a percepção dos desenvolvedores, realizamos 40 entrevistas e uma pesquisa entre 202 desenvolvedores. Descobrimos que os desenvolvedores lidam com três problemas comuns na prática: erros relacionados à configuração, testes combinatórios e compreensão do código. Os desenvolvedores agravam estes problemas ao usar diretivas não disciplinadas, as quais não respeitam a estrutura sintática do código. Para evoluir famílias de programas de forma segura, foram propostas duas estratégias para a detecção de erros relacionados à configuração e um conjunto de 14 refatoramentos para remover diretivas não disciplinadas. Para lidar melhor com a grande quantidade de configurações do código fonte, a primeira estratégia considera todo o conjunto de configurações do código fonte e a segunda estratégia utiliza amostragem. Para propor um algoritmo de amostragem adequado, foram comparados 10 algoritmos com relação ao esforço (número de configurações para testar) e capacidade de detecção de erros (número de erros detectados nas configurações da amostra). Com base nos resultados deste estudo, foi proposto um algoritmo de amostragem. Estudos empíricos foram realizados usando 40 sistemas C do mundo real. Detectamos 128 erros relacionados à configuração, enviamos 43 correções para erros ainda não corrigidos e os desenvolvedores aceitaram 65% das correções. Os resultados de nossa pesquisa mostram que a maioria dos desenvolvedores preferem usar a versão refatorada,ou seja,disciplinada do código fonte,ao invés do código original com as diretivas não disciplinadas. Além disso,os desenvolvedores aceitaram 21 (75%) das 28 sugestões enviadas para transformar diretivas não disciplinadas em disciplinadas. Nossa pesquisa apresenta resultados úteis para desenvolvedores de código C durante suas tarefas de desenvolvimento, contribuindo para minimizar o número de erros relacionados à configuração, melhorar a compreensão e a manutenção do código fonte e orientar os desenvolvedores para realizar testes combinatórios.Since the 70s, the C preprocessor is still widely used in practice in a numbers of projects, including Apache,Linux ,and Libssh, totail or systems to different platforms and application scenarios. In academia,however, the preprocess or has received strong critic is msinceatl east the early 90s. Researchers have criticized its lack of separation of concerns, its proneness to introduce subtle errors, and its obfuscation of the source code. To better understand the problems of using the C preprocessor, taking the perception of developers into account, we conducted 40 interviewsandasurveyamong 202 developers. We found that developers deal with three common problems in practice: configuration-related bugs, combinatorial testing, and code comprehension. Developers aggravate these problems when using undisciplined directives (i.e., bad smells regarding preprocessor use), which are preprocessor directives thatdo notrespect thesyntactic structureof thesource code. To safely evolve preprocessor based program families, we proposed strategies to detect configuration-relatedbugs and bad smells, and a set of 14 refactorings to remove bad smells. To better deal with exponential configuration spaces, our strategies uses variability-aware analysis that considers the entire set of possible configurations, and sampling, which allows to reuse C tools that consider only one configuration at a time to detect bugs. To propose a suitable sampling algorithm, we compared 10 algorithms with respect to effort (i.e., number of configurations to test) andbug-detection capabilities (i.e.,numberofbugs detected in the sampled configurations). Based on the results, we proposed a sampling algorithm with an useful balance between effort and bug-detection capability. We performed empirical studies using a corpus of 40 C real-world systems. We detected 128 configuration-related bugs, submitted 43 patches to fix bugs not fixed yet, and developers accepted 65% of the patches. The results of our survey show that most developers prefer to use the refactored (i.e., disciplined) version of the code instead of the original code with undisciplined directives. Furthermore, developers accepted 21 (75%) out of 28 patches submitted to refactor undisciplined into disciplined directives. Our work presents useful findings for C developers during their development tasks, contributing to minimize the chances of introducing configuration-related bugs and bad smells, improve code comprehension, and guide developers to perform combinatorial testing

Analysis and Transformation of Configurable Systems

Static analysis tools and transformation engines for source code belong to the standard equipment of a software developer. Their use simplifies a developer's everyday work of maintaining and evolving software systems significantly and, hence, accounts for much of a developer's programming efficiency and programming productivity. This is also beneficial from a financial point of view, as programming errors are early detected and avoided in the the development process, thus the use of static analysis tools reduces the overall software-development costs considerably. In practice, software systems are often developed as configurable systems to account for different requirements of application scenarios and use cases. To implement configurable systems, developers often use compile-time implementation techniques, such as preprocessors, by using #ifdef directives. Configuration options control the inclusion and exclusion of #ifdef-annotated source code and their selection/deselection serve as an input for generating tailor-made system variants on demand. Existing configurable systems, such as the linux kernel, often provide thousands of configuration options, forming a huge configuration space with billions of system variants. Unfortunately, existing tool support cannot handle the myriads of system variants that can typically be derived from a configurable system. Analysis and transformation tools are not prepared for variability in source code, and, hence, they may process it incorrectly with the result of an incomplete and often broken tool support. We challenge the way configurable systems are analyzed and transformed by introducing variability-aware static analysis tools and a variability-aware transformation engine for configurable systems' development. The main idea of such tool support is to exploit commonalities between system variants, reducing the effort of analyzing and transforming a configurable system. In particular, we develop novel analysis approaches for analyzing the myriads of system variants and compare them to state-of-the-art analysis approaches (namely sampling). The comparison shows that variability-aware analysis is complete (with respect to covering the whole configuration space), efficient (it outperforms some of the sampling heuristics), and scales even to large software systems. We demonstrate that variability-aware analysis is even practical when using it with non-trivial case studies, such as the linux kernel. On top of variability-aware analysis, we develop a transformation engine for C, which respects variability induced by the preprocessor. The engine provides three common refactorings (rename identifier, extract function, and inline function) and overcomes shortcomings (completeness, use of heuristics, and scalability issues) of existing engines, while still being semantics-preserving with respect to all variants and being fast, providing an instantaneous user experience. To validate semantics preservation, we extend a standard testing approach for refactoring engines with variability and show in real-world case studies the effectiveness and scalability of our engine. In the end, our analysis and transformation techniques show that configurable systems can efficiently be analyzed and transformed (even for large-scale systems), providing the same guarantees for configurable systems as for standard systems in terms of detecting and avoiding programming errors

Consolidation of Customized Product Copies into Software Product Lines

In software development, project constraints lead to customer-specific variants by copying and adapting the product. During this process, modifications are scattered all over the code. Although this is flexible and efficient in the short term, a Software Product Line (SPL) offers better results in the long term, regarding cost reduction, time-to-market, and quality attributes. This book presents a novel approach named SPLevo, which consolidates customized product copies into an SPL

Consolidation of Customized Product Copies into Software Product Lines

Copy-based customization is a widespread technique to serve individual customer needs with existing software solutions. To cope with long term disadvantages resulting from this practice, this dissertation developed an approach to support the consolidation of such copies into a Software Product Line with a future-compliant product base providing managed variability

Advances in Computer Science and Engineering

The book Advances in Computer Science and Engineering constitutes the revised selection of 23 chapters written by scientists and researchers from all over the world. The chapters cover topics in the scientific fields of Applied Computing Techniques, Innovations in Mechanical Engineering, Electrical Engineering and Applications and Advances in Applied Modeling

Consolidation of Customized Product Copies into Software Product Lines

In software development, project constraints lead to customer-specific variants by copying and adapting the product. During this process, modifications are scattered all over the code. Although this is flexible and efficient in the short term, a Software Product Line (SPL) offers better results in the long term, regarding cost reduction, time-to-market, and quality attributes. This book presents a novel approach named SPLevo, which consolidates customized product copies into an SPL

Automated Improvement of Software Design by Search-Based Refactoring

Le coût de maintenance du logiciel est estimé à plus de 70% du coût total du système, en raison de nombreux facteurs, y compris les besoins des nouveaux utilisateurs, l’adoption de nouvelles technologies et la qualité des systèmes logiciels. De ces facteurs, la qualité est celle que nous pouvons contrôler et continuellement améliorer pour empêcher la dégradation de la performance et la réduction de l’efficacité (par exemple, la dégradation de la conception du logiciel). De plus, pour rester compétitive, l’industrie du logiciel a raccourci ses cycles de lancement afin de fournir de nouveaux produits et fonctionnalités plus rapidement, ce qui entraîne une pression accrue sur les équipes de développeurs et une accélération de l’évolution de la conception du système. Une façon d’empêcher la dégradation du logiciel est l’identification et la correction des anti-patrons qui sont des indicateurs de mauvaise qualité de conception. Pour améliorer la qualité de la conception et supprimer les anti-patrons, les développeurs effectuent de petites transformations préservant le comportement (c.-à-d., refactoring). Le refactoring manuel est coûteux, car il nécessite (1) d’identifier les entités de code qui doivent être refactorisées ; (2) générer des opérations de refactoring pour les classes identifiées à l’étape précédente ; (3) trouver le bon ordre d’application des refactorings générés, pour maximiser le bénéfice pour la qualité du code et minimiser les conflits. Ainsi, les chercheurs et les praticiens ont formulé le refactoring comme un problème d’optimisation et utilisent des techniques basées sur la recherche pour proposer des approches (semi) automatisées pour le résoudre. Dans cette thèse, je propose plusieurs méthodes pour résoudre les principaux problèmes des outils existants, afin d’aider les développeurs dans leurs activités de maintenance et d’assurance qualité. Ma thèse est qu’il est possible d’améliorer le refactoring automatisé en considérant de nouvelles dimensions : (1) le contexte de tâche du développeur pour prioriser le refactoring des classes pertinentes ; (2) l’effort du test pour réduire le coût des tests après le refactoring ; (3) l’identification de conflit entre opérations de refactoring afin de réduire le coût de refactoring ; et (4) l’efficacité énergétique pour améliorer la consommation d’énergie des applications mobiles après refactoring.----------ABSTRACT: Software maintenance cost is estimated to be more than 70% of the total cost of system, because of many factors, including new user’s requirements, the adoption of new technologies and the quality of software systems. From these factors, quality is the one that we can control and continually improved to prevent degradation of performance and reduction of effectiveness (a.k.a. design decay). Moreover, to stay competitive, the software industry has shortened its release cycles to deliver new products and features faster, which results in more pressure on developer teams and the acceleration of system’s design evolution. One way to prevent design decay is the identification and correction of anti-patterns which are indicators of poor design quality. To improve design quality and remove anti-patterns, developers perform small behavior-preserving transformations (a.k.a. refactoring). Manual refactoring is expensive, as it requires to (1) identify the code entities that need to be refactored; (2) generate refactoring operations for classes identified in the previous step; (3) find the correct order of application of the refactorings generated, to maximize the quality effect and to minimize conflicts. Hence, researchers and practitioners have formulated refactoring as an optimization problem and use search-based techniques to propose (semi)automated approaches to solve it. In this dissertation, we propose several approaches to tackle some of the major issues in existing refactoring tools, to assist developers in their maintenance and quality assurance activities

Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model Environments

Software has been subject to change, at all times, in order to make parts of it, for instance, more reusable, better to understand by humans, or to increase efficiency under a certain point of view. Restructurings of existing software can be complex. To prevent developers from doing this manually, they got tools at hand being able to apply such restructurings automatically. These automatic changes of existing software to improve quality while preserving its behaviour is called refactoring. Refactoring is well investigated for programming languages and mature tools exist for executing refactorings in integrated development environments (IDEs). In recent years, the development paradigm of Model-Driven Software Development (MDSD) became more and more popular and we experience a shift in the sense that development artefacts are considered as models which conform metamodels. This can be understood as abstraction, which resulted in the trend that a plethora of new so-called model-based Domain-Specific Languages (DSLs) arose. DSLs have become an integral part in the MDSD and it is obvious that models are subject to change, as well. Thus, refactoring support is required for DSLs in order to prevent users from doing it manually. The problem is that the amount of DSLs is huge and refactorings should not be implemented for new for each of them, since they are quite similar from an abstract viewing. Existing approaches abstract from the target language, which is not flexible enough because some assumptions about the languages have to be made and arbitrary DSLs are not supported. Furthermore, the relation between a strategy which finds model deficiencies that should be improved, a resolving refactoring, and the improved quality is only implicit. Focussing on a particular quality and only detecting those deficiencies deteriorating this quality is difficult, and elements of detected deficient structures cannot be referred to in the resolving refactoring. In addition, heterogeneous models in an IDE might be connected physically or logically, thus, they are dependent. Finding such connections is difficult and can hardly be achieved manually. Applying a restructuring in a model implied by a refactoring in a dependent model must also be a refactoring, in order to preserve the meaning. Thus, this kind of dependent refactorings require an appropriate abstraction mechanism, since they must be specified for dependent models of different DSLs. The first contribution, Role-Based Generic Model Refactoring, uses role models to abstract from refactorings instead of the target languages. Thus, participating structures in a refactoring can be specified generically by means of role models. As a consequence, arbitrary model-based DSLs are supported, since this approach does not make any assumptions regarding the target languages. Our second contribution, Role-Based Quality Smells, is a conceptual framework and correlates deficiencies, their deteriorated qualities, and resolving refactorings. Roles are used to abstract from the causing structures of a deficiency, which then are subject to resolving refactorings. The third contribution, Role-Based Co-Refactoring, employs the graph-logic isomorphism to detect dependencies between models. Dependent refactorings, which we call co-refactorings, are specified on the basis of roles for being independent from particular target DSLs. All introduced concepts are implemented in our tool Refactory. An evaluation in different scenarios complements the thesis. It shows that role models emerged as very powerful regarding the reuse of generic refactorings in arbitrary languages. Role models are suited as an interface for certain structures which are to be refactored, scanned for deficiencies, or co-refactored. All of the presented approaches benefit from it.:List of Figures xv List of Tables xvii List of Listings xix 1. Introduction 1 1.1. Language-Tool Generation Without Consideration Of Time And Space . . . . . 4 1.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.3. Generic Quality-Aware Refactoring and Co-Refactoring in Heterogeneous Model Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Foundations 15 2.1. Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2. Model-Driven Software Development . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1. Levels of Abstraction and Metamodelling . . . . . . . . . . . . . . . . . 17 2.2.2. Model Transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3. Role-Based Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Related Work 23 3.1. Model Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.2. Determination of Quality-Related De ciencies . . . . . . . . . . . . . . . . . . . 32 3.2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.2.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3. Co-Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.2. Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3.3. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4. Role-Based Generic Model Refactoring 51 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2. Specifying Generic Refactorings with Role Models . . . . . . . . . . . . . . . . . 53 4.2.1. Specifying Structural Constraints using Role Models . . . . . . . . . . . 55 4.2.2. Mapping Roles to Language Concepts Using Role Mappings . . . . . . . 57 4.2.3. Specifying Language-Independent Transformations using Refactoring Speci cations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.2.4. Composition of Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.3. Preserving Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5. Suggesting Role Mappings as Concrete Refactorings 73 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2. Automatic Derivation of Suggestions for Role Mappings with Graph Querying . 74 5.3. Reduction of the Number of Valid Matches . . . . . . . . . . . . . . . . . . . . . 76 5.4. Comparison to Model Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6. Role-Based Quality Smells as Refactoring Indicator 79 6.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.2. Correlating Model De ciencies, Qualities and Refactorings . . . . . . . . . . . . 80 6.2.1. Quality Smell Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.2.2. Quality Smell Calculation Repository . . . . . . . . . . . . . . . . . . . . 85 6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7. A Quality Smell Catalogue for Android Applications 89 7.1. Quality Smell Catalogue Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 7.2. Acquiring Quality Smells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.3. Structure-Based Quality Smells—A Detailed Example . . . . . . . . . . . . . . . 92 7.3.1. The Pattern Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.3.2. Quality Smell: Interruption from Background . . . . . . . . . . . . . . . 93 7.4. Quality Smells for Android Applications . . . . . . . . . . . . . . . . . . . . . . 96 7.4.1. Quality Smell: Data Transmission Without Compression . . . . . . . . . 96 7.4.2. Quality Smell: Dropped Data . . . . . . . . . . . . . . . . . . . . . . . . 98 7.4.3. Quality Smell: Durable WakeLock . . . . . . . . . . . . . . . . . . . . . 98 7.4.4. Quality Smell: Internal Use of Getters/Setters . . . . . . . . . . . . . . . 99 7.4.5. Quality Smell: No Low Memory Resolver . . . . . . . . . . . . . . . . . 101 7.4.6. Quality Smell: Rigid AlarmManager . . . . . . . . . . . . . . . . . . . . 101 7.4.7. Quality Smell: Unclosed Closeable . . . . . . . . . . . . . . . . . . . . . 102 7.4.8. Quality Smell: Untouchable . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 8. Role-Based Co-Refactoring in Multi-Language Development Environments 105 8.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 8.3. Dependency Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.3.1. Categories of Model Dependencies . . . . . . . . . . . . . . . . . . . . . 108 8.3.2. When to Determine Model Dependencies . . . . . . . . . . . . . . . . . 110 8.3.3. How to Determine Model Dependencies . . . . . . . . . . . . . . . . . . 111 8.4. Co-Refactoring Knowledge Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 8.4.1. Specifying Coupled Refactorings with Co-Refactoring Speci cations . . 114 8.4.2. Specifying Bindings for Co-Refactorings . . . . . . . . . . . . . . . . . . 116 8.4.3. Determination of Co-Refactoring Speci cations . . . . . . . . . . . . . . 118 8.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 8.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 9. Refactory: An Eclipse Tool For Quality-Aware Refactoring and Co-Refactoring 121 9.1. Refactoring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 9.1.1. Role Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 9.1.2. Refactoring Speci cation . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 9.1.3. Role Model Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 9.1.4. Refactoring Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 9.1.5. Custom Refactoring Extensions . . . . . . . . . . . . . . . . . . . . . . . 129 9.1.6. Pre- and Post-conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 9.1.7. Integration Into the Eclipse Refactoring Framework . . . . . . . . . . . . 130 9.2. Quality Smell Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 9.3. Co-Refactoring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 9.3.1. Concrete Syntax of a CoRefSpec . . . . . . . . . . . . . . . . . . . . . . . 138 9.3.2. Expression Evaluation by Using an Expression Language . . . . . . . . . 138 9.3.3. UI and Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 9.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 10. Evaluation 143 10.1. Case Study: Reuse of Generic Refactorings in many DSLs . . . . . . . . . . . . . 143 10.1.1. Threats to validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 10.1.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 10.1.3. Experience Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 10.2. Case Study: Suggestion of Valid Role Mappings . . . . . . . . . . . . . . . . . . 147 10.2.1. Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 10.2.2. Evaluation and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 151 10.3. Proof of Concept: Co-Refactoring OWL and Ecore Models . . . . . . . . . . . . 155 10.3.1. Coupled OWL-Ecore Refactorings . . . . . . . . . . . . . . . . . . . . . 156 10.3.2. Realisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 10.3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 11. Summary, Conclusion and Outlook 161 11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 11.2. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 11.3. Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Appendix 169 A. List of Role Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 B. Comparison to Role Feature Model . . . . . . . . . . . . . . . . . . . . . . . . . 171 C. Complete List of Role Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 D. List of all IncPL Patterns for Detecting Quality Smells . . . . . . . . . . . . . . . 176 E. Post-Processor of the Extract CompositeState refactoring for UML State Machines 183 F. Speci cation of the Conference Language . . . . . . . . . . . . . . . . . . . . . . 185 List of Abbreviations 187 Bibliography 19