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.

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