Current climate warming is affecting arctic regions at a faster rate than the rest of the world. This has profound effects on permafrost that underlies most of the arctic land area. Permafrost thawing can lead to the liberation of considerable amounts of greenhouse gases as well as to significant changes in the geomorphology, hydrology, and ecology of the corresponding landscapes, which may in turn act as a positive feedback to the climate system. Vast areas of the east Siberian lowlands, which are underlain by permafrost of the Yedoma-type Ice Complex, are particularly sensitive to climate warming because of the high ice content of these permafrost deposits. Thermokarst and thermal erosion are two major types of permafrost degradation in periglacial landscapes. The associated landforms are prominent indicators of climate-induced environmental variations on the regional scale. Thermokarst lakes and basins (alasses) as well as thermo-erosional valleys are widely distributed in the coastal lowlands adjacent to the Laptev Sea. This thesis investigates the spatial distribution and morphometric properties of these degradational features to reconstruct their evolutionary conditions during the Holocene and to deduce information on the potential impact of future permafrost degradation under the projected climate warming. The methodological approach is a combination of remote sensing, geoinformation, and field investigations, which integrates analyses on local to regional spatial scales. Thermokarst and thermal erosion have affected the study region to a great extent. In the Ice Complex area of the Lena River Delta, thermokarst basins cover a much larger area than do present thermokarst lakes on Yedoma uplands (20.0 and 2.2 %, respectively), which indicates that the conditions for large-area thermokarst development were more suitable in the past. This is supported by the reconstruction of the development of an individual alas in the Lena River Delta, which reveals a prolonged phase of high thermokarst activity since the Pleistocene/Holocene transition that created a large and deep basin. After the drainage of the primary thermokarst lake during the mid-Holocene, permafrost aggradation and degradation have occurred in parallel and in shorter alternating stages within the alas, resulting in a complex thermokarst landscape. Though more dynamic than during the first phase, late Holocene thermokarst activity in the alas was not capable of degrading large portions of Pleistocene Ice Complex deposits and substantially altering the Yedoma relief. Further thermokarst development in existing alasses is restricted to thin layers of Holocene ice-rich alas sediments, because the Ice Complex deposits underneath the large primary thermokarst lakes have thawed completely and the underlying deposits are ice-poor fluvial sands. Thermokarst processes on undisturbed Yedoma uplands have the highest impact on the alteration of Ice Complex deposits, but will be limited to smaller areal extents in the future because of the reduced availability of large undisturbed upland surfaces with poor drainage. On Kurungnakh Island in the central Lena River Delta, the area of Yedoma uplands available for future thermokarst development amounts to only 33.7 %. The increasing proximity of newly developing thermokarst lakes on Yedoma uplands to existing degradational features and other topographic lows decreases the possibility for thermokarst lakes to reach large sizes before drainage occurs. Drainage of thermokarst lakes due to thermal erosion is common in the study region, but thermo-erosional valleys also provide water to thermokarst lakes and alasses. Besides these direct hydrological interactions between thermokarst and thermal erosion on the local scale, an interdependence between both processes exists on the regional scale. A regional analysis of extensive networks of thermo-erosional valleys in three lowland regions of the Laptev Sea with a total study area of 5,800 km² found that these features are more common in areas with higher slopes and relief gradients, whereas thermokarst development is more pronounced in flat lowlands with lower relief gradients. The combined results of this thesis highlight the need for comprehensive analyses of both, thermokarst and thermal erosion, in order to assess past and future impacts and feedbacks of the degradation of ice-rich permafrost on hydrology and climate of a certain region. / Die gegenwärtige Klimaerwärmung wirkt sich auf arktische Regionen stärker aus als auf andere Gebiete der Erde. Das hat weitreichende Konsequenzen für Permafrost, der weite Teile der terrestrischen Arktis unterlagert. Das Tauen von Permafrost kann zur Freisetzung erheblicher Mengen an Treibhausgasen sowie zu gravierenden Änderungen in der Geomorphologie, Hydrologie und Ökologie betroffener Landschaften führen, was wiederum als positive Rückkopplung auf das Klimasystem wirken kann. Ausgedehnte Gebiete der ostsibirischen Tiefländer, die mit Permafrost des Yedoma Eiskomplex unterlagert sind, gelten aufgrund des hohen Eisgehalts dieser Permafrostablagerungen als besonders empfindlich gegenüber Klimaerwärmungen. Thermokarst und Thermoerosion sind zwei Hauptformen der Permafrostdegradation in periglazialen Landschaften. Die zugehörigen Landschaftsformen sind auf der regionalen Skala bedeutende Indikatoren klimainduzierter Umweltvariationen. Thermokarstseen und senken (Alasse) sowie Thermoerosionstäler sind in den Küstentiefländern der Laptewsee weit verbreitet. Die vorliegende Dissertation untersucht die räumliche Verbreitung und die morphometrischen Eigenschaften dieser Degradationsformen mit dem Ziel, ihre Entwicklungsbedingungen während des Holozäns zu rekonstruieren und Hinweise auf potenzielle Auswirkungen zukünftiger Permafrostdegradation im Zuge der erwarteten Klimaerwärmung abzuleiten. Der methodische Ansatz ist eine Kombination aus Fernerkundungs-, Geoinformations- und Geländeuntersuchungen, die Analysen auf lokalen bis regionalen räumlichen Skalen integriert. Thermokarst und Thermoerosion haben die Untersuchungsregion tiefgreifend geprägt. Im Eiskomplexgebiet des Lena-Deltas nehmen Thermokarstsenken eine weitaus größere Fläche ein als Thermokarstseen auf Yedoma-Hochflächen (20,0 bzw. 2,2 %), was darauf hin deutet, dass die Bedingungen für die Entwicklung von großflächigem Thermokarst in der Vergangenheit wesentlich günstiger waren als heute. Die Rekonstruktion der Entwicklung eines einzelnen Alas im Lena-Delta belegt eine andauernde Phase hoher Thermokarstaktivität seit dem Übergang vom Pleistozän zum Holozän, die zur Entstehung einer großen und tiefen Senke führte. Nach der Drainage des primären Thermokarstsees im mittleren Holozän erfolgten Permafrostaggradation und degradation parallel und in kürzeren abwechselnden Etappen innerhalb des Alas und führten zu einer komplexen Thermokarstlandschaft. Trotzdem die spätholozäne Thermokarstentwicklung im Alas dynamischer ablief als die erste Entwicklungsphase, resultierte sie nicht in der Degradation großer Teile pleistozäner Eiskomplexablagerungen und einer wesentlichen Veränderung des Yedoma-Reliefs. Weitere Thermokarstentwicklung in bestehenden Alassen ist begrenzt auf geringmächtige Lagen holozäner eisreicher Alas-Sedimente, da die Eiskomplexablagerungen unter den großen primären Thermokarstseen vollständig getaut waren und die unterlagernden Sedimente aus eisarmen, fluvialen Sanden bestehen. Thermokarstprozesse auf ungestörten Yedoma-Hochflächen wirken am stärksten verändernd auf Eiskomplexablagerungen, werden aber in Zukunft auf geringere Ausmaße begrenzt sein, da die Verfügbarkeit großer ungestörter, schwach drainierter Yedoma-Hochflächen abnimmt. Auf der Insel Kurungnakh im zentralen Lena-Delta beträgt der für zukünftige Thermokarstentwicklung verfügbare Anteil an Yedoma-Hochflächen nur 33,7 %. Die zunehmende Nähe von sich entwickelnden Thermokarstseen auf Yedoma-Hochflächen zu bestehenden Degradationsstrukturen und anderen negativen Reliefformen verringert die Möglichkeit der Thermokarstseen, große Ausmaße zu erreichen bevor sie drainieren. Die Drainage von Thermokarstseen durch Thermoerosion ist in der Untersuchungsregion weit verbreitet, aber Thermoerosionstäler versorgen Thermokarstseen und –senken auch mit Wasser. Neben diesen direkten hydrologischen Wechselwirkungen zwischen Thermokarst und Thermoerosion auf der lokalen Ebene existiert auch eine Interdependenz zwischen beiden Prozessen auf der regionalen Ebene. Eine regionale Analyse weitreichender Netze von Thermoerosionstälern in drei Tieflandgebieten der Laptewsee mit einer Fläche von insgesamt 5800 km² zeigte, dass diese Formen häufiger in Gebieten mit höheren Geländeneigungen und Reliefgradienten auftreten, während Thermokarstentwicklung stärker in flachen Tiefländern mit geringeren Reliefgradienten ausgeprägt ist. Die kombinierten Ergebnisse dieser Dissertation zeigen die Notwendigkeit von umfassenden Analysen beider Prozesse und Landschaftsformen, Thermokarst und Thermoerosion, im Hinblick auf die Abschätzung vergangener und zukünftiger Auswirkungen der Degradation eisreichen Permafrosts auf Hydrologie und Klima der betrachteten Region und deren Rückkopplungen.

Die künstlerische Entwicklung des Dresdner Malers Oskar Zwintscher (1870–1916) ist eng mit seinem frei gewählten ,Exil‘ in Meißen verknüpft. Ausgebildet an der Dresdner Kunstakademie zog sich der junge Maler 1892 nach seinem Studium in die nahegelegene kleine Stadt zurück, wo er bis zu seiner Berufung an die Akademie im Jahr 1903 lebte. Trotz dieses Rückzugs hat Zwintscher aber, anders als in der älteren Literatur angenommen, nicht abgewandt von den Entwicklungen seiner Zeit gearbeitet, sondern sich mit modernen Fragestellungen und Maltechniken auseinandergesetzt. Seine Schaffensphase in Meißen war eine äußerst produktive Zeit. Neben Porträts und ersten vielfigurigen Kompositionen entstanden in den 1890er Jahren auch eine Reihe von Landschaften. Die charakteristische Architektur der Stadt taucht in verschiedenen seiner Gemälde auf, wie in den Werken Rote Dächer, Der alte Turm, Mondnacht, Familie und Selbstbildnis mit Tod.

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.

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 191

No description available.