Cette thèse présente une application de la théorie du contrôle pour les systèmes informatiques. Un algorithme de contrôle peut gérer des systèmes plus grands et plus complexes, même lorsqu'ils sont particulièrement sensibles aux variations de leur environnement. Cependant, l'application du contrôle aux systèmes informatiques soulève plusieurs défis, par exemple dû au fait qu'aucune physique ne les régisse. D'une part, le cadre mathématique fourni par la théorie du contrôle peut être utilisé pour améliorer l'automatisation, la robustesse et la fiabilité des systèmes informatiques. D'autre part, les défis spécifiques de ces cas d'étude permettent d'élargir la théorie du contrôle elle-même. L'approche adoptée dans ce travail consiste à utiliser deux systèmes informatiques d'application: la protection de vie privée liée à la mobilité et les performances des services clouds. Ces deux cas d'utilisation sont complémentaires par la nature de leurs technologies, par leur échelle et par leurs utilisateurs finaux.La popularité des appareils mobiles a favorisé la diffusion et la collecte des données de localisation, que ce soit pour que l'utilisateur bénéficie d'un service personnalisé (e.g. une planification d'itinéraire) ou pour que le prestataire de services tire des informations utiles des bases de données de mobilité (e.g. la popularité de lieux). En effet, de nombreuses informations peuvent être extraites de données de localisation, y compris des données personnelles très sensibles. Pour remédier à cette atteinte à la vie privée, des mécanismes de protection spécifiques aux données de mobilité (LPPM) ont été élaborés. Ce sont des algorithmes qui modifient les données de localisation de l'utilisateur, dans le but de cacher des informations sensibles. Cependant, ces outils ne sont pas facilement configurables par des non experts et sont des processus statiques qui ne s'adaptent pas à la mobilité de l'utilisateur. Dans cette thèse, nous développons deux outils, l'un pour les bases de données déjà collectées et l'autre pour l'utilisation en ligne, qui garantissent aux utilisateurs des niveaux de protection de la vie privée et de préservation de la qualité des services en configurant les LPPMs. Nous présentons la première formulation du problème en termes de théorie du contrôle (système et contrôleur, signaux d’entrée et de sortie), et un contrôleur PI pour servir de démonstration d’applicabilité. Dans les deux cas, la conception, la mise en œuvre et la validation ont été effectuées par le biais d'expériences utilisant des données d'utilisateurs réels recueillies sur le terrain.L'essor récent des bigdata a conduit au développement de programmes capables de les analyser, tel que MapReduce. Les progrès des pratiques informatiques ont également permis d'établir le modèle du cloud (où il est possible de louer des ressources de bas niveau pour permettre le développement d'applications de niveau supérieur sans se préoccuper d'investissement ou de maintenance) comme une solution incontournable pour tous types d'utilisateurs. Garantir les performances des tâches MapReduce exécutées sur les clouds est donc une préoccupation majeure pour les grandes entreprises informatiques et leurs clients. Dans ce travail, nous développons des techniques avancées de contrôle du temps d'exécution des tâches et de la disponibilité de la plate-forme en ajustant la taille du cluster de ressources et en réalisant un contrôle d'admission, fonctionnant quelle que soit la charge des clients. Afin de traiter les non linéarités de MapReduce, un contrôleur adaptatif a été conçu. Pour réduire l'utilisation du cluster (qui entraîne des coûts financiers et énergétiques considérables), nous présentons une nouvelle formulation du mécanisme de déclenchement du contrôle événementiel, combiné à un contrôleur prédictif optimal. L'évaluation est effectuée sur un benchmark s'exécutant en temps réel sur un cluster, et en utilisant des charges de travail industrielles. / This thesis presents an application of Control Theory for Computing Systems. It aims at investigating techniques to build and control efficient, dependable and privacy-preserving computing systems. Ad-hoc service configuration require a high level of expertise which could benefit from automation in many ways. A control algorithm can handle bigger and more complex systems, even when they are extremely sensitive to variations in their environment. However, applying control to computing systems raises several challenges, e.g. no physics governs the applications. On one hand, the mathematical framework provided by control theory can be used to improve automation and robustness of computing systems. Moreover, the control theory provides by definition mathematical guarantees that its objectives will be fulfilled. On the other hand, the specific challenges of such use cases enable to expand the control theory itself. The approach taken in this work is to use two application computing systems: location privacy and cloud control. Those two use-cases are complementary in the nature of their technologies and softwares, their scale and in their end-users.The widespread of mobile devices has fostered the broadcasting and collection of users’ location data. It could be for the user to benefit from a personalized service (e.g. weather forecast or route planning) or for the service provider or any other third party to derive useful information from the mobility databases (e.g. road usage frequency or popularity of places). Indeed, many information can be retrieved from location data, including highly sensitive personal data. To overcome this privacy breach, Location Privacy Protection Mechanisms (LPPMs) have been developed. They are algorithm that modify the user’s mobility data, hopefully to hide some sensitive information. However, those tools are not easily configurable by non experts and are static processes that do not adapt to the user’s mobility. We develop two tools, one for already collected databases and one for online usage, that, by tuning the LPPMs, guarantee to the users objective-driven levels of privacy protection and of service utility preservation. First, we present an automated tool able to choose and configure LPPMs to protect already collected databases while ensuring a trade-off between privacy protection and database processing quality. Second, we present the first formulation of the location privacy challenge in control theory terms (plant and control, disturbance and performance signals), and a feedback controller to serve as a proof of concept. In both cases, design, implementation and validation has been done through experiments using data of real users collected on the field.The surge in data generation of the last decades, the so-called bigdata, has lead to the development of frameworks able to analyze them, such as the well known MapReduce. Advances in computing practices has also settled the cloud paradigms (where low-level resources can be rented to allow the development of higher level application without dealing with consideration such as investment in hardware or maintenance) as premium solution for all kind of users. Ensuring the performances of MapReduce jobs running on clouds is thus a major concern for the big IT companies and their clients. In this work, we develop advanced monitoring techniques of the jobs execution time and the platform availability by tuning the resource cluster size and realizing admission control, in spite of the unpredictable client workload. In order to deal with the non linearities of the MapReduce system, a robust adaptive feedback controller has been designed. To reduce the cluster utilization (leading to massive financial and energetic costs), we present a new event-based triggering mechanism formulation combined with an optimal predictive controller. Evaluation is done on a MapReduce benchmark suite running on a large-scale cluster, and using real jobs workloads.

Visualization of software systems is mainly used for understanding and modeling software architecture. Examples of what can be visualized are source code, systems during execution together with manipulated data or system architecture on either a detailed or a general level. The connection between all of these types of visualization is that they help computer engineers maintain or develop software systems. The largest challenge with visualizing software systems is when the systems in question are exceedingly large and containing an abundance of relations. A problem of this kind arise at the company DGC, where this study is performed. The company manages at present more than a couple hundred systems with over ten thousand relations between each other. The problem with the company’s existing visualization is that they are very difficult to follow and understand, since they mainly present raw data in the form of tables that do not show all relations optimally, and which can also easily distract the company stakeholders from their intended task. The aim of this study is to find a visualization method where a system and its underlying parts are shown together with their relations to other systems. The created visualization will be able to be used by several different stakeholders and will as clearly as possible present relevant information to them. Furthermore, it should also aim to contribute to a better understanding of the complex software systems and their relations. After the implementation of the chosen visualization method, a time-based study is performed to determine whether it poses an improvement of perception among the stakeholders or not. An interview is also conducted where these stakeholders provide their opinion on the created visualization and if they think it presents the necessary information in a pedagogical way. Analysis of the result of the timekeeping and the interview answers indicate that the aim of the study is met. The majority of the resulting times show that the created visualization is more efficient than the original ones, and the interview answers furthermore show how different stakeholders all together agree that the visualization can be used in both future development and maintenance. / Visualisering av mjukvarusystem används i stor utsträckning för att förstå och modellera mjukvaruarkitektur. Ett par exempel på vad som kan visualiseras är: källkod, system under exekvering tillsammans med manipulerat data eller systemarkitektur på detaljerad eller övergripande nivå. Sambandet mellan alla dessa typer av visualiseringar är att de hjälper dataingenjörer att underhålla och utveckla mjukvarusystem. Den största utmaningen i att visualisera mjukvarusystem är när systemen i fråga är väldigt stora och har många beroenden. Ett sådant problem uppstår på företaget DGC där denna undersökning utförs. Företaget hanterar i dagsläge mer än hundratals mjukvarusystem med över tiotusentals beroenden sinsemellan. Problemet med företagets befintliga visualiseringar är att dessa är väldigt svåra att följa eftersom de oftast presenterar rådata i form av tabeller som inte visar alla relationer på ett optimalt sätt och distraherar lätt intressenter på företaget från sin avsedda uppgift. Undersökningen syftar på att finna en visualiseringsmetod där ett system och dess underliggande systemdelar visas tillsammans med deras beroenden till andra. Den framtagna visualiseringen skall kunna användas av flera olika intressenter, och i högsta möjliga mån presentera relevant information för dem på ett tydligt sätt. Vidare ska den skapade visualiseringen också bidra till bättre förståelse för komplexa mjukvarusystem och deras beroenden. Efter framtagandet av visualiseringen utförs en tidsundersökning, för att avgöra huruvida den skapade visualiseringen stimulerar förståelse hos de olika intressenterna på företaget. Det utförs även en intervju där intressenterna på företaget lämnar sina synpunkter angående den skapade visualiseringen och om den kan presentera nödvändig information på ett pedagogiskt sätt. Analys av resultaten av tidtagningarna och svaren på intervjuerna visar tydligt att undersökningens syften nåtts. Majoriteten av tidtagningarna visade att den skapade visualiseringen är effektivare än de ursprungliga och intervjusvaren uppvisar hur olika intressenter ser att den kan användas vid vidareutvecklingen eller underhåll, vilket alla intressenter höll med om.

Modern software systems offer numerous configuration options to optimize performance, often using machine learning-based models. However, these models frequently overlook external factors such as software versions, usage scenarios, and hardware setups, raising concerns about their real-world applicability. This research expands performance modeling to include system variability from both software evolution and workload variations. It empirically analyzes how these factors influence performance and develops methods to adapt models accordingly. Experiments reveal that software performance evolves with abrupt changes linked to code revisions or merges. An active learning strategy efficiently detects performance change points, aiding in identifying significant shifts. Additionally, large-scale empirical analysis shows how varying configurations and workloads affect performance, identifying significant data shifts that question the accuracy of traditional models. Correlating performance data with code coverage information reveals that code coverage testing can identify workload-sensitive configuration options. Based on these comprehensive empirical results, this thesis proposes integrating environmental factors into performance modeling. A combined coarse-grain screening strategy and stepwise feature selection enhance data extraction. Compared to a Lasso baseline, this method more accurately identifies performance-relevant factors, particularly in feature-rich scenarios. This research provides a foundational understanding of multi-factor system variability in performance modeling, offering efficient strategies for managing software evolution and workload variability. / Moderne Software-Systeme bieten oft Anpassungsmöglichkeiten, um Funktionalität und Leistung an spezifische Anforderungen anzupassen. Performance-Modelle verwenden maschinelles Lernen, um die Leistung eines Systems basierend auf seiner Konfiguration abzuschätzen. Allerdings beeinflussen nicht nur Konfigurationseinstellungen, sondern auch externe Faktoren wie Softwareversion, Arbeitslast und Hardwarekonfiguration die Leistung. Angesichts möglicher Verzerrungen durch sekundäre Faktoren und der Tatsache, dass viele Modellierungsansätze hauptsächlich die Konfigurierbarkeit eines Systems berücksichtigen, ist die Frage, wie gut bestehende Ansätze in der Praxis anwendbar sind. Diese Dissertation erweitert die Modellierung der Software-Leistung um zwei zusätzliche sekundäre Dimensionen: die Evolution eines Softwaresystems und den Einfluss der spezifischen Arbeitslast. Die Arbeit kombiniert empirische Leistungsmessungen, um die Leistungsmerkmale unter Variation dieser Faktoren zu beschreiben, mit dem Ziel, Leistungsmodelle entsprechend anzupassen. Die Veränderung der Software-Leistung über die Entwicklungsgeschichte ist durch plötzliche Änderungen (Change Points) gekennzeichnet, die oft mit spezifischen Code-Revisionen oder Merge-Ereignissen zusammenhängen. Auf Basis dieser Beobachtungen präsentiert die Arbeit eine Active-Learning-Strategie, die es ermöglicht, mit wenigen Messungen die gesamte Leistungshistorie eines Softwaresystems abzuschätzen und spezifische Änderungen zu lokalisieren. Eine Erweiterung dieses Ansatzes zur Kontextualisierung von Leistungsänderungen ordnet erkannten Änderungen einer oder mehreren Konfigurationsoptionen zu, um die betroffenen Konfigurationen einzugrenzen. In Bezug auf die Dimension der Arbeitslast präsentiert diese Dissertation eine umfassende empirische Studie, die die kombinierten Auswirkungen von Konfigurierbarkeit und Arbeitslastvariation auf die Software-Leistung untersucht. Es zeigt sich, dass die Arbeitslast den Einfluss der einzelnen Konfigurationsoptionen signifikant beeinflusst, was die Zuverlässigkeit vieler Ansätze weiter einschränkt. Eine Verknüpfung von Code-Coverage-Daten mit Leistungsmessungen zeigt, wie Abdeckungstests (als kostengünstige Alternative zu Leistungsmessungen) dazu beitragen können, Interaktionen zwischen der Arbeitslast und den einzelnen Optionen zu finden. Die Berücksichtigung weiterer sekundärer Faktoren in Modellierungsansätzen für Software-Leistung stellt eine Herausforderung dar, die durch die kombinatorische Komplexität des Gesamtproblems bedingt ist. Angesichts der hohen Kosten von Leistungsmessungen und der oft begrenzten Datenverfügbarkeit präsentiert der letzte Teil der Dissertation einen Ansatz zur Identifizierung relevanter Faktoren (Feature Selection). Durch die gleichzeitige Betrachtung mehrerer Faktoren (Group Sampling) und eine schrittweise Auswahl von Faktoren erhöht die Screening-Strategie die aus einer Stichprobe an Messungen gewonnene Informationsmenge im Vergleich zu einem Lasso-Basismodell. Zusammenfassend bietet diese Dissertation eine empirische Beschreibung der Software-Leistung, abhängig von der Konfiguration sowie zwei weiteren Faktoren: der Software-Evolution und der Arbeitslast. Darüber hinaus stellt diese Arbeit einen Katalog an Methoden bereit, um beide Dimensionen bei der Modellierung von Software-Leistung zu berücksichtigen und die Herausforderungen der Skalierbarkeit eines kombinierten Ansatzes zu bewältigen.

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

The increasing number of smart systems inevitably leads to a huge number of systems that potentially provide independently designed, autonomously operating services. In near-future smart computing systems, such as smart cities, smart grids or smart mobility, independently developed and heterogeneous services need to be dynamically interconnected in order to develop their full potential in a rather complex collaboration with others. Since the services are developed independently, it is challenging to integrate them on-the-fly at run time. Due to the increasing degree of distribution, such systems operate in a decentralized and volatile environment, where central management is infeasible. Conversely, the increasing computational power of such systems also supersedes the need for central management. The four identified key problems of adaptable, collaborative Smart Service Systems are on-demand composition of complex service structures in decentralized environments, the absence of a comprehensive, serendipity-aware specification, a discontinuity from design-time specification to run-time execution, and the lack of a development methodology that separates the development of a service from that of its role essential to a collaboration. This approach utilizes role-based models, which have a collaborative nature, for automated, on-demand service composition. A rigorous two-phase development methodology is proposed in order to demarcate the development of the services from that of their role essential to a collaboration. Therein, a collaboration designer specifies the collaboration including its abstract functionality using the proposed role-based collaboration specification for Smart Service Systems. Thereof, a partial implementation is derived, which is complemented by services developed in the second phase. The proposed middleware architecture provides run-time support and bridges the gap between design and run time. It implements a protocol for coordinated, role-based composition and adaptation of Smart Service Systems. The approach is quantitatively and qualitatively evaluated by means of a case study and a performance evaluation in order to identify limitations of complex service structures and the trade-off of employing the concept of roles for composition and adaptation of Smart Service Systems.:1 Introduction 1.1 Motivation 1.2 Terminology 1.3 Problem Statement 1.4 Requirements Analysis 1.5 Research Questions and Hypothesis 1.6 Focus and Limitations 1.7 Outline 2 The Role Concept in Computer Science 2.1 What is a Role in Computer Science? 2.2 Roles in RoleDiSCo 3 State of the Art & Related Work 3.1 Role-based Modeling Abstractions for Software Systems 3.1.1 Classification 3.1.2 Approaches 3.1.3 Summary 3.2 Role-based Run-Time Systems 3.2.1 Classification 3.2.2 Approaches 3.2.3 Summary 3.3 Spontaneously Collaborating Run-Time Systems 3.3.1 Classification 3.3.2 Approaches 3.3.3 Summary 3.4 Summary 4 On-Demand Composition and Adaptation of Smart Service Systems 4.1 RoleDiSCo Development Methodology 4.1.1 Role-based Collaboration Specification for Smart Service Systems 4.1.2 Derived Partial Implementation 4.1.3 Player & Context Provision 4.2 RoleDiSCo Middleware Architecture for Smart Service Systems 4.2.1 Infrastructure Abstraction Layer 4.2.2 Context Management 4.2.3 Local Repositories & Knowledge 4.2.4 Discovery 4.2.5 Dispatcher 4.3 Coordinated Composition and Subsequent Adaptation 4.3.1 Initialization and Planning 4.3.2 Composition: Coordinating Subsystem 4.3.3 Composition: Non-Coordinating Subsystem 4.3.4 Competing Collaborations & Negotiation 4.3.5 Subsequent Adaptation 4.3.6 Terminating a Pervasive Collaboration 4.4 Summary 5 Implementing RoleDiSCo 5.1 RoleDiSCo Development Support 5.2 RoleDiSCo Middleware 5.2.1 Infrastructure Abstraction Layer 5.2.2 Knowledge Repositories and Local Class Discovery 5.2.3 Planner 6 Evaluation 6.1 Case Study: Distributed Slideshow 6.1.1 Scenario 6.1.2 Phase 1: Collaboration Design 6.1.3 Phase 2: Player Complementation 6.1.4 Coordinated Composition and Adaptation at Run Time 6.2 Runtime Evaluation 6.2.1 General Testbed Setup and Scenarios 6.2.2 Discovery Time 6.2.3 Composition Time 6.2.4 Discussion 6.3 The ›Role‹ of Roles 6.4 Summary 7 Conclusion 7.1 Summary 7.2 Research Results 7.3 Future Work