Planung und Umsetzung einer erweiterten, relationalen Mehrkampfdatenbank mit Mehrbenutzerunterstützung unter Verwendung des Laravel-PHP-Frameworks und MariaDB

Das Praxisprojekt ist eine Fortführung des bereits umgesetzten Informatikprojektes. Daher wird in den nachfolgenden Kapiteln ausschließlich auf die maßgeblichen Änderungen und Erweiterungen Bezug genommen. Der Schwerpunkt ist die Konzeption und Umsetzung eines relationalen Datenbanksystems zur Erfassung, Verwaltung und Bearbeitung von leichtathletischen Mehrkampfwettbewerben. Die Bedienung erfolgt über eine Weboberfläche, die Mithilfe des PHP-Frameworks Laravel an das Datenbanksystem MariaDB angekoppelt ist. Die wichtigsten Themen im Projekt sind: • Die Umsetzung und Koordinierung des Mehrbenutzerbetriebs • Die Umsetzung und Kontrolle der Rechteverwaltung der Benutzer • Die Möglichkeit zur Erfassung eigener Wettkämpfe bestehend aus beliebig vielen Disziplinen inklusive individueller Formeln zur Punkteberechnung Die ersten beiden Punkte werden in dieser Ausarbeitung auf einer allgemeinen Ebene behandelt

REALISTIC CORRECT SYSTEMS IMPLEMENTATION

The present article and the forthcoming second part on Trusted Compiler Implementation\ud address correct construction and functioning of large computer based systems. In view\ud of so many annoying and dangerous system misbehaviors we ask: Can informaticians\ud righteously be accounted for incorrectness of systems, will they be able to justify systems\ud to work correctly as intended? We understand the word justification in the sense: design\ud of computer based systems, formulation of mathematical models of information flows, and\ud construction of controlling software are to be such that the expected system effects, the\ud absence of internal failures, and the robustness towards misuses and malicious external attacks\ud are foreseeable as logical consequences of the models.\ud Since more than 40 years, theoretical informatics, software engineering and compiler\ud construction have made important contributions to correct specification and also to correct\ud high-level implementation of compilers. But the third step, translation - bootstrapping - of\ud high level compiler programs to host machine code by existing host compilers, is as important.\ud So far there are no realistic recipes to close this correctness gap, although it is known\ud for some years that trust in executable code can dangerously be compromised by Trojan\ud Horses in compiler executables, even if they pass strongest tests.\ud In the present first article we will give a comprehensive motivation and develop\ud a mathematical theory in order to conscientiously prove the correctness of an initial fully\ud trusted compiler executable. The task will be modularized in three steps. The third step of\ud machine level compiler implementation verification is the topic of the forthcoming second\ud part on Trusted Compiler Implementation. It closes the implementation gap, not only for\ud compilers but also for correct software-based systems in general. Thus, the two articles together\ud give a rather confident answer to the question raised in the title

Realistic correct systems implementation

Подана перша частина статті і наступна її друга частина присвячені методам коректної побудови і функціонування великих комп'ютерних систем. У центрі уваги – проблема обґрунтування, що подається в сенсі формулювання математичної моделі інформаційних потоків у комп'ютерній системі і побудови керуючого програмного забезпечення, що контролює слушність поводження, відсутність внутрішніх помилок і усталеність стосовно зовнішніх атак як логічні наслідки, що одержуються з моделі. У першій частині статті викладена математична теорія доказової побудови компіляторівПредставленная первая часть статьи и последующая ее вторая часть посвящены методам корректного построения и функционирования больших компьютерных систем. В центре внимания – проблема обоснования, понимаемая в смысле формулирования математической модели информационных потоков в компьютерной системе и построения управляющего программного обеспечения, контролирующего правильность поведения, отсутствие внутренних ошибок и устойчивость по отношению к внешним атакам как логические следствия, получаемые из модели. В первой части статьи изложена математическая теория доказательного построения компиляторов

Entwurf und Implementierung einer visuellen Programmiersprache für den Einsatz in Schulen

In der vorliegenden Arbeit wurde, nach einer vorherigen Erhebung von Anforderungen, eine visuelle Programmiersprache für den Einsatz in Schulen entwickelt. Hierfür wurde ein Prototyp implementiert, auf dessen Basis ein Produkt geschaffen wurde, das sich an den Wünschen der befragten Lehrer orientiert

Generisches Modellrefactoring für EMFText

Code-Refactorings sind gut erforscht und die meisten Entwicklungsumgebungen unterstützen diese. Mit dem Auftrieb der modellgetriebenen Software-Entwicklung (MDSD) stellt sich jedoch eine neue Herausforderung. Zahlreiche neue domänenspezifische Sprachen (DSL) werden entwickelt, wodurch sich die Frage stellt, wie man diesen Werkzeuge an die Hand gibt, die Modell-Refactorings ermöglichen. In dieser Diplomarbeit wird ein Ansatz zum generischen Modell-Refactoring entwickelt, mit dem der Kern eines Refactorings, bestehend aus den teilnehmenden Elementen und den Transformationsschritten, einmalig definiert und anschließend durch ein einfaches Mapping für beliebige DSLs zur Verfügung gestellt wird.:1 Einleitung 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Überblick über die Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Grundlagen und Begriffsklärung 5 2.1 Code-Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Model Driven Software Development (MDSD) . . . . . . . . . . . . . . . . 6 2.2.1 Meta Object Facility . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2 DSLs und Modell-Repräsentationen . . . . . . . . . . . . . . . . . 9 2.3 Code als Modell und Modell-Refactoring . . . . . . . . . . . . . . . . . . . 11 2.4 Textuelle Modelle und EMFText . . . . . . . . . . . . . . . . . . . . . . . 13 3 Analyse von Refactoring-Katalogen 17 3.1 Ein Querschnitt vorhandener Code-Refactorings . . . . . . . . . . . . . . . 17 3.1.1 Extract Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.2 Remove Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.3 Rename Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.4 Pull Up Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.5 Encapsulate Field . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.6 Move Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.7 Form Template Method . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1.8 Consolidate Conditional Expression . . . . . . . . . . . . . . . . . 21 3.2 Auswertung und Übertragung auf Modell-Refactorings . . . . . . . . . . . 21 3.2.1 Erzeugung eines Containers . . . . . . . . . . . . . . . . . . . . . . 22 3.2.2 Erzeugung eines Kind-Elementes . . . . . . . . . . . . . . . . . . . 23 3.2.3 Verschieben eines Elementes . . . . . . . . . . . . . . . . . . . . . . 23 3.2.4 Änderung eines Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.5 Entfernen eines Elementes . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Anforderungsanalyse für generisches Modell-Refactoring 29 4.1 Konzeptionelle Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.2 Nichtfunktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 31 5 Analyse existierender Modell-Refactoring-Ansätze 33 5.1 M3-Spezifikation am Beispiel von GenericMT . . . . . . . . . . . . . . . . 33 VIIInhaltsverzeichnis 5.2 M2-Spezifikation am Beispiel von EMF Refactor . . . . . . . . . . . . . . 40 5.3 M1-Spezifikation am Beispiel des Object Recorders . . . . . . . . . . . . . 46 5.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6 Konzept des generischen Modell-Refactorings 53 6.1 Modellierung mit Rollen nach Reenskaug, Riehle und Gross . . . . . . . . 54 6.2 Modellierung generischer Modell-Refactorings mit Rollen . . . . . . . . . . 56 6.2.1 Metamodell zur Definition von Kollaborationen zwischen Rollen . 57 6.2.2 Metamodell zur Spezifikation der Schritte eines Modell-Refactorings 60 6.2.3 Metamodell zur Abbildung von Rollen auf ein Ziel-Metamodell . . 69 6.3 Vor- und Nachbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.4 Bewahrung der Semantik . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.5 Horizontale und vertikale Konsistenz . . . . . . . . . . . . . . . . . . . . . 76 6.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7 Implementierung und Evaluation 81 7.1 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.2 Role Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 7.3 Refactoring Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.4 Role Mapping Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.5 Durchführung eines Modell-Refactorings durch Interpretation . . . . . . . 98 7.6 Index-Mechanismus zur Wahrung der Konsistenz . . . . . . . . . . . . . . 99 7.7 Kopplung an die UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 7.8 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.9 Evaluation anhand von mehreren Metamodellen . . . . . . . . . . . . . . . 105 8 Zusammenfassung und Ausblick 113 8.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 8.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Abbildungsverzeichnis i Tabellenverzeichnis iii Listings v Abkürzungsverzeichnis vii Literaturverzeichnis i

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