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 ix

Identifiers play a key role in code quality and comprehension, as poorly named identifiers hinder the developers’ ability to understand, debug, and maintain programs. To address these issues, several studies have proposed methods to automatically rename low-quality or inconsistent identifiers. Recently, machine learning has been used to predict potential renaming opportunities for identifiers. However, there is none or little work done that reviews the key machine learning-based methods used to rename identifiers. To that end, this project aims to conduct a systematic literature review that will answer: a) what key machine learning-based approaches exist for recommeding renamings of identifiers; b) how accurate are the different approaches; and c) what datasets are used for their evaluation. As a result of the literature review, we selected 14 learning-based identifier renaming approaches published between 2014-2021. From the extracted data, we identified a total of 19 machine learning techniques, which we categorized into a taxonomy of "deep" and "shallow" learning. In this process, we found that a majority of studies since 2019 have used deep learning techniques. Specifically, two context-based approaches achieved the best performance in detecting and renaming inconsistent identifiers. As a result, we discussed how the use of different techniques might have influenced the performance, evaluation methods, and research practices in the area of rename refactoring.

[pt] Code smells são estruturas pobres que prejudicam a manutenção do sistema. Sendo assim, code smells devem ser detectados e removidos, através de refatoração, no começo do ciclo de vida do software. Refatoração consiste em modificações no código que visam melhorar a manutenção do software, removendo ou mitigando estruturas pobres. Contudo, as estratégias de detecção e refatoração de smells são subjetivas. Isto é, desenvolvedores trabalhando no mesmo sistema podem divergir acerca da existência de um smell. Essa divergência é influenciada pelo conhecimento do desenvolvedor, incluindo o design do sistema e o código analisado. Como consequência, essa divergência afeta também a aplicação das refatorações. Assim, é preciso customizar a detecção de smell e refatoração a partir do conhecimento dos desenvolvedores. Afinal, o desenvolvedor é quem confirma a nocividade de um smell e define como refatorá-lo. Para isso, decompomos nossa pesquisa em 3 passos: (i) como customizar estratégias de detecção de smells?, (ii) se e com que frequência os desenvolvedores customizam suas refatorações? e (iii) como dar suporte a customização de refatoração?. No primeiro passo avaliamos as técnicas de aprendizagem de máquina quanto a capacidade de customizar sua detecção para cada desenvolvedor. Segundo, nós investigamos como desenvolvedores customizam refatorações, analisando suas modificações de código enquanto aplicam certos tipos de refatoração. Além disso, nós também discutimos como essas customizações estão relacionadas com a inserção, remoção ou mitigação de smells e se são apoiados pelo Eclipse. Terceiro, nós propusemos uma abordagem que permite a aplicação de refatorações customizadas. Nossos resultados indicaram que as técnicas de aprendizagem de máquina são capazes de capturar o conhecimento do desenvolvedor e obter alta acurácia detectando smells. Além disso, desenvolvedores frequentemente customizam refatorações que não são totalmente suportadas pelo Eclipse. Para piorar, customizações complexas, geralmente manuais, tendem a reduzir o efeito positivo da refatoração. Portanto, nossos resultados servem como base para melhorar o suporte de ferramentas: a (i) detecção customizada de smells, levando em consideração o conhecimento do desenvolvedor e (ii) a aplicação de refatoração customizada. / [en] Code smells are poor structures that harm software maintenance. Therefore, code smells should be detected and removed, through refactoring, early in the software lifecycle. Refactoring consists of a sequence of code modifications that aim to improve software maintenance by removing or mitigating poor code structures. However, the strategies for detecting and refactoring smells are subjective. Even developers working on the same software may diverge on their opinions about the existence of a smell. In fact, this divergence is mostly influenced by the developer s knowledge, including the system s design and the analyzed source code. As a consequence, the same divergence affects the application of the corresponding refactorings. Therefore, there is a need to support the customization of smell detection and refactoring based on the developer s knowledge. The developer is who, after all, becomes the decision maker on confirming the harmfulness of a smelly structure and how to refactor it out. In order to address this issue, we split our research in 3 steps: (i) how to customize smell detection strategies? (ii) whether and how often developers customize their refactorings? and (iii) how to support refactoring customization? In the first step, we evaluated the use of machine learning techniques for properly customizing smell detection for each developer. Second, we investigated how developers customize refactorings by analyzing their code modifications while applying certain refactoring types. Besides, we also discussed how these customizations are related to the introduction, removal or mitigation of smells, and whether they are currently supported by Eclipse, a popular IDE. Third, we proposed an approach that allows the application of custom refactoring. Our results indicated that machine learning techniques are able to efficiently capture the developer s knowledge and achieve high smell detection accuracy. Also, even though developers frequently customize refactorings, their customizations are often not supported by Eclipse. To make it worse, complex customizations, which are manually performed, tend to reduce the positive effect of the refactoring. Therefore, our contributions serve as a basis for improving tool support for: (i) customized detection of smells considering the developer s knowledge, and (ii) application of customized refactoring.

In der vorliegenden Arbeit wird ein Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme erarbeitet. Ontologiegetriebene Softwaresysteme sind Softwaresysteme, bei denen Ontologien als zentrale Designdokumente zum Einsatz kommen. Ontologien sind gleichzeitig zentrale Bestandteile des ausführbaren Systems und dienen zur Strukturbeschreibung und Datenhaltung. Dabei werden Teile des Softwaresystems automatisch aus den Strukturbeschreibungen der Ontologie abgeleitet. Diese Arbeit konzentriert sich auf die Weiterentwicklung solcher Systeme und stellt dafür einen Katalog von Ontologie-Refactorings auf. Es werden mehrere Werkzeuge, gemeinsam als OntoMore bezeichnet, implementiert, um die Umsetzbarkeit des aufgestellten Konzepts zu zeigen. OntoMore kann Ontologien in Metamodelle und Modelle des EMF umwandeln und somit in Softwaresysteme integrieren. Außerdem ist es in der Lage, Refactorings auf beiden Strukturen synchron auszuführen. Dieser Prozess wird als Co-Refactoring bezeichnet. Damit wird die konsistente Evolution von Ontologien und Modellen sichergestellt. Die Implementierung wird anhand einer Beispiel-Ontologie zum Freelancer-Management evaluiert. / In this thesis an approach is elaborated for the development and evolution of ontology-driven software systems. Ontology-driven software systems are software systems for which ontologies serve as main design documents. Ontologies are furthermore central parts of the running system. They describe the structure of the system and hold data. Parts of the software system are automatically derived from the structure descriptions of the ontology. This work concentrates on the evolution of those systems, thereby defining a catalogue of ontology refactorings. A tool suite called OntoMore is implemented to show the feasibility of the elaborated approach. OntoMore can transform ontologies in metamodels and models of EMF to integrate them in software systems. It can furthermore execute refactorings synchronously on both structures, which is called Co-Refactoring. Hence the consistent evolution of ontologies and models is ensured. The implementation is evaluated with an example ontology about the freelancer domain.

In der vorliegenden Arbeit wird ein Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme erarbeitet. Ontologiegetriebene Softwaresysteme sind Softwaresysteme, bei denen Ontologien als zentrale Designdokumente zum Einsatz kommen. Ontologien sind gleichzeitig zentrale Bestandteile des ausführbaren Systems und dienen zur Strukturbeschreibung und Datenhaltung. Dabei werden Teile des Softwaresystems automatisch aus den Strukturbeschreibungen der Ontologie abgeleitet. Diese Arbeit konzentriert sich auf die Weiterentwicklung solcher Systeme und stellt dafür einen Katalog von Ontologie-Refactorings auf. Es werden mehrere Werkzeuge, gemeinsam als OntoMore bezeichnet, implementiert, um die Umsetzbarkeit des aufgestellten Konzepts zu zeigen. OntoMore kann Ontologien in Metamodelle und Modelle des EMF umwandeln und somit in Softwaresysteme integrieren. Außerdem ist es in der Lage, Refactorings auf beiden Strukturen synchron auszuführen. Dieser Prozess wird als Co-Refactoring bezeichnet. Damit wird die konsistente Evolution von Ontologien und Modellen sichergestellt. Die Implementierung wird anhand einer Beispiel-Ontologie zum Freelancer-Management evaluiert.:1 Einleitung 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Grundlagen 5 2.1 Modellgetriebene Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 Ontologien und semantische Techniken 11 3.1 Grundlagen semantischer Techniken . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1 Definition und Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2 Die Web Ontology Language (OWL) . . . . . . . . . . . . . . . . . . . 14 3.2.3 Ontologie-Syntaxen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4 Beschreibungslogiken, Teilsprachen und Profile . . . . . . . . . . . . . 18 3.2.5 Abfragen mit SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.6 Beispiele für Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3 Ontologie-Evolution und Versionierung . . . . . . . . . . . . . . . . . . . . . . 21 3.4 Unterschiede zwischen Ontologie-Evolution und Refactoring . . . . . . . . . . . 23 3.5 Zukünftige Entwicklungen – Linked Data . . . . . . . . . . . . . . . . . . . . . 24 3.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Eingesetzte Werkzeuge 27 4.1 Verbindung von Ontologien und Modellen mit OntoMoPP . . . . . . . . . . . 27 4.2 Generisches Modell-Refactoring mit Refactory . . . . . . . . . . . . . . . . . . 28 5 Stand der Forschung 31 5.1 Abbildung von Ontologien auf Domänenmodelle . . . . . . . . . . . . . . . . . 31 5.1.1 Einsatz von Ontologien in der Modellierung . . . . . . . . . . . . . . . 31 5.1.2 Abbildungen zwischen Ontologien und Datenbanken . . . . . . . . . . . 35 5.2 Ontologie-Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.1 Anforderungen an Ontologie-Evolution . . . . . . . . . . . . . . . . . . 37 5.2.2 Elementare und komplexe Änderungsoperationen . . . . . . . . . . . . 38 5.2.3 KAON – Das Karlsruhe Ontology and Semantic Web Framework . . . . 38 5.2.4 Das NeOn-Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.5 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.6 Bewertung vorhandener Systeme zur Ontologie-Evolution . . . . . . . . 47 5.3 Co-Evolution von Metamodellen und Modellen . . . . . . . . . . . . . . . . . . 48 5.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6 Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme 51 6.1 Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2 OWL-Ecore-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.3 Refactorings für OWL und Ecore . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.3.1 Definition und Katalog von Ontologie-Refactorings . . . . . . . . . . . 62 6.3.2 Schema eines Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . 63 6.3.3 Beispiel eines Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . 66 6.4 Co-Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4.1 Definition und Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4.2 Herleitung und Architekturvergleich . . . . . . . . . . . . . . . . . . . 70 6.4.3 Der CoRefactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7 Praktische Umsetzung 75 7.1 Architektur und eingesetzte Techniken . . . . . . . . . . . . . . . . . . . . . . 75 7.2 Testgetriebene Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.3 OWL-Ecore-Transformator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.4 Refactoring mit Refactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.5 CoRefactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 8 Evaluation 91 8.1 Die Beispiel-Ontologie: FrOnto . . . . . . . . . . . . . . . . . . . . . . . . . . 91 8.2 Bewertung der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.3 Grenzen der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.4 Grenzen der Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 8.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 9 Zusammenfassung 101 9.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1.1 Das Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1.2 Beziehung zwischen Ontologien und Domänenmodellen . . . . . . . . . 101 9.1.3 Konzeption von Refactorings und Co-Refactorings . . . . . . . . . . . . 102 9.1.4 Implementierung von OntoMore . . . . . . . . . . . . . . . . . . . . . 103 9.1.5 Evaluation anhand einer Beispiel-Ontologie . . . . . . . . . . . . . . . 103 9.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Anhang i A Weitere Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . . . . i B Auswirkungen von Ontologie-Refactorings bezüglich der Datenmigration . . . . . . i C Die MiniFrOnto vor und nach dem Refactoring . . . . . . . . . . . . . . . . . . . iii D Refactoring mit der OWL-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . v Abbildungsverzeichnis vii Tabellenverzeichnis ix Listings xi Abkürzungsverzeichnis xiii Literaturverzeichnis xv / In this thesis an approach is elaborated for the development and evolution of ontology-driven software systems. Ontology-driven software systems are software systems for which ontologies serve as main design documents. Ontologies are furthermore central parts of the running system. They describe the structure of the system and hold data. Parts of the software system are automatically derived from the structure descriptions of the ontology. This work concentrates on the evolution of those systems, thereby defining a catalogue of ontology refactorings. A tool suite called OntoMore is implemented to show the feasibility of the elaborated approach. OntoMore can transform ontologies in metamodels and models of EMF to integrate them in software systems. It can furthermore execute refactorings synchronously on both structures, which is called Co-Refactoring. Hence the consistent evolution of ontologies and models is ensured. The implementation is evaluated with an example ontology about the freelancer domain.:1 Einleitung 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Grundlagen 5 2.1 Modellgetriebene Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 Ontologien und semantische Techniken 11 3.1 Grundlagen semantischer Techniken . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1 Definition und Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2.2 Die Web Ontology Language (OWL) . . . . . . . . . . . . . . . . . . . 14 3.2.3 Ontologie-Syntaxen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.4 Beschreibungslogiken, Teilsprachen und Profile . . . . . . . . . . . . . 18 3.2.5 Abfragen mit SPARQL . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2.6 Beispiele für Ontologien . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.3 Ontologie-Evolution und Versionierung . . . . . . . . . . . . . . . . . . . . . . 21 3.4 Unterschiede zwischen Ontologie-Evolution und Refactoring . . . . . . . . . . . 23 3.5 Zukünftige Entwicklungen – Linked Data . . . . . . . . . . . . . . . . . . . . . 24 3.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Eingesetzte Werkzeuge 27 4.1 Verbindung von Ontologien und Modellen mit OntoMoPP . . . . . . . . . . . 27 4.2 Generisches Modell-Refactoring mit Refactory . . . . . . . . . . . . . . . . . . 28 5 Stand der Forschung 31 5.1 Abbildung von Ontologien auf Domänenmodelle . . . . . . . . . . . . . . . . . 31 5.1.1 Einsatz von Ontologien in der Modellierung . . . . . . . . . . . . . . . 31 5.1.2 Abbildungen zwischen Ontologien und Datenbanken . . . . . . . . . . . 35 5.2 Ontologie-Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.1 Anforderungen an Ontologie-Evolution . . . . . . . . . . . . . . . . . . 37 5.2.2 Elementare und komplexe Änderungsoperationen . . . . . . . . . . . . 38 5.2.3 KAON – Das Karlsruhe Ontology and Semantic Web Framework . . . . 38 5.2.4 Das NeOn-Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2.5 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.6 Bewertung vorhandener Systeme zur Ontologie-Evolution . . . . . . . . 47 5.3 Co-Evolution von Metamodellen und Modellen . . . . . . . . . . . . . . . . . . 48 5.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6 Konzept zur Entwicklung und Evolution ontologiegetriebener Softwaresysteme 51 6.1 Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.2 OWL-Ecore-Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.3 Refactorings für OWL und Ecore . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.3.1 Definition und Katalog von Ontologie-Refactorings . . . . . . . . . . . 62 6.3.2 Schema eines Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . 63 6.3.3 Beispiel eines Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . 66 6.4 Co-Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4.1 Definition und Ansätze . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.4.2 Herleitung und Architekturvergleich . . . . . . . . . . . . . . . . . . . 70 6.4.3 Der CoRefactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7 Praktische Umsetzung 75 7.1 Architektur und eingesetzte Techniken . . . . . . . . . . . . . . . . . . . . . . 75 7.2 Testgetriebene Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.3 OWL-Ecore-Transformator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 7.4 Refactoring mit Refactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 7.5 CoRefactorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 8 Evaluation 91 8.1 Die Beispiel-Ontologie: FrOnto . . . . . . . . . . . . . . . . . . . . . . . . . . 91 8.2 Bewertung der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.3 Grenzen der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.4 Grenzen der Konzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 8.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 9 Zusammenfassung 101 9.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1.1 Das Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.1.2 Beziehung zwischen Ontologien und Domänenmodellen . . . . . . . . . 101 9.1.3 Konzeption von Refactorings und Co-Refactorings . . . . . . . . . . . . 102 9.1.4 Implementierung von OntoMore . . . . . . . . . . . . . . . . . . . . . 103 9.1.5 Evaluation anhand einer Beispiel-Ontologie . . . . . . . . . . . . . . . 103 9.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Anhang i A Weitere Ontologie-Refactorings . . . . . . . . . . . . . . . . . . . . . . . . . . . . i B Auswirkungen von Ontologie-Refactorings bezüglich der Datenmigration . . . . . . i C Die MiniFrOnto vor und nach dem Refactoring . . . . . . . . . . . . . . . . . . . iii D Refactoring mit der OWL-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . v Abbildungsverzeichnis vii Tabellenverzeichnis ix Listings xi Abkürzungsverzeichnis xiii Literaturverzeichnis xv

Excessive coupling between object-oriented classes in systems is generally acknowledged as harmful and is recognised as a maintenance problem that can result in a higher propensity for faults in systems and a „stored up‟ future problem. Characterisation and understanding coupling at different levels of abstraction is therefore important for both the project manager and developer both of whom have a vested interest in software quality. In this Thesis, coupling trends are empirically investigated over multiple versions of seven Java open-source systems (OSS). The first investigation explores the trends in longitudinal changes to open-source systems given by six coupling metrics. Coupling trends are then explored from the perspective of: the relationship between removed classes and their coupling with other classes in the same package; the relationships between coupling and 'warnings’ in packages and the time interval between versions in Java OSS; the relationship between some of these coupling metrics are also explored. Finally, the existence of an 80/20 rule for the coupling metrics is inspected. Results suggest that developer activity comprises a set of high and low periods (peak and trough‟ effect) evident as a system evolves. Findings also demonstrate that addition of coupling may have beneficial effects on a system, particularly if they are added as new functionality through the package Java feature. The fan-in and fan-out coupling metrics reveal particular features and exhibited a wide range of traits in the classes depending on their high or low values; finally, we revealed that one metric (fan-in) is the only metric that appears consistently to exhibit an 80/20 (Pareto) relationship.

Object-oriented systems that undergo repeated modifications commonly endure a loss of quality and design decay. This problem is often remedied by applying refactorings. Refactoring is one of the most important and commonly used techniques to improve the quality of the code by eliminating redundancy and reducing complexity; frequently refactored code is believed to be easier to understand, maintain and test. Object-oriented metrics provide an easy means to extract useful and measurable information about the structure of a software system. Metrics have been used to identify refactoring opportunities, detect refactorings that have previously been applied and gauge quality improvements after the application of refactorings. This thesis provides an in-depth analytical study of the relationship between metrics and refactorings. For this purpose we analyzed 136 versions of 4 different open source projects. We used RefactoringCrawler, an automatic refactoring detection tool to identify refactorings and then analyzed various metrics to study whether metrics can be used to (1) reliably identify refactoring opportunities, (2) detect refactorings that were previously applied, and (3) estimate the impact of refactoring on software quality. In conclusion, our study showed that metrics cannot be reliably used to either identify refactoring opportunities or detect refactorings. It is very difficult to use metrics to estimate the impact of refactoring, however studying the evolution of metrics at a system level indicates that refactoring does improve software quality and reduce complexity. / text

Keeping a consistent coding style is an important part of having a maintainable code base. In times when software solutions become increasingly complicated this requirement is more important than ever. However, most commercially available coding productivity tools put a much bigger focus on refactoring and support of additional technologies than on maintaining consistent code style. We decided to remedy this situation by implementing a plugin-extensible toolset for Visual Studio focused on diagnosing and correcting code style violations in C# code bases. By completing our intent we created a tool that integrates seamlessly with Visual Studio and provides the user with effective and intuitive tools to improve the overall maintainability of their code base. Powered by TCPDF (www.tcpdf.org)

Title: Refactoring tree editor TrEd Author: Peter Fabian Department: Institute of Formal and Applied Linguistics Supervisor: doc. Ing. Zdenek Zabokrtsky, Ph.D., Institute of Formal and Applied Linguistics Abstract: The main goal of the thesis was to refactor tree editor TrEd, improve its modularity, maintainability and make its further development less difficult. Static and dynamic analysis of TrEd have been performed in order to help us find acrid spots in the source code. More than 230 subroutines and data structures have been moved between packages, 50 new packages and a test suite with more than 1,300 tests have been created. A new coding style have been chosen for further development and most severe violations of this standard have been fixed. After the changes done on the source code, it have been analyzed again and the results have been compared with the previous state. Keywords: Tree Editor TrEd, Perl, code refactoring, code analysis

This diploma thesis is focused on agile management of relational databases. The gole is to provide detail analysis of changes which are performed on daily bases by DBA or software developers and describe how these changes can hugely affect performance of database system and its data. The principles of best known development methodics are described in part one (chapter 2 and 3). Following second part (chapter 4) contains descriptions of basics steps of agile strategies which have been often used in application solutions. Finally the third part (chapter 5 and following) contains detail information about usual performed database tasks.