TP3.6: Technische Plattform-Architektur

Teilprojektleitung
Prof. Dr. Dr. h.c. Manfred Broy
Teilprojektleitung
Dr. habil. Christian Prehofer
Bearbeiter
Dr. Ilias Gerostathopoulos


Unter Connected Mobility Systems (CMS) versteht man die Instrumentierung von Geräten und Diensten, um damit auf dem Mobilitätsmarkt Mehrwertfunktionen anbieten zu können. Ein Beispiel für ein CMS ist ein intelligentes Parksystem, bei dem externe Webdienste einen homogenen Überblick über die Verfügbarkeit von Parkplätzen in einer Stadt zu ermöglich, basierend auf Straßenrand-Sensoren und Fahrzeugen die in einer Stadt fahren.

CMS sind schwer zu entwickeln, da sie komplexe Systeme mit vielen Stakeholdern und verteilten Geräten und Daten sind.

Abbildung 1: Überblick über Continuous Architecture Engineering
Sie haben meist Anforderungen, die oft widersprüchlich sind:
  • Notwendigkeit für die Nutzung offener Plattformen (im Bezug auf das Management), um aus Ökosystemeffekte zu proliferieren.
  • Müssen immer aktiv sein und schnell reagieren, um Endbenutzer zufrieden zu stellen.
  • Müssen erweiterbar sein im Bezug auf neue Funktionen und sich ändernde Anforderungen um der Geschwindigkeit heutiger Innovationen mitzuhalten.
  • Müssen große Mengen an Daten analysieren und an diesen Daten lernen, um sich selbst zu verbessert.
Um diese Herausforderung anzugehen, konzentrieren wir uns in dieser WP auf folgende (breite) Forschungsfragen:
  • Wie können wir die Qualität und Leistungsfähigkeit einer CMS-Plattform gewährleisten, insbesondere in Bezug auf die Analyse und die Zusammenarbeit mit der Plattform?
  • Wie können wir eine integrierte Entwicklungsumgebung bereitstellen, die Continuous Delivery von neuen Funktionalitäten über alle Geräte und Plattformteile hinweg ermöglicht?
  • Wie können wir die Anpassungsfähigkeit und Weiterentwicklung einer CMS-Plattform gewährleisten?
Wir nennen unseren Ansatz Data-Driven Continuous Engineering. Dementsprechend sollten Daten, die sowohl die Laufzeitphase eines CMS als auch den Entwicklungslebenszyklus betreffen, erfasst und analysiert werden, um Korrelationen zwischen Entwicklungsmethoden und Endprodukten zu identifizieren sowie Experimente durchgeführt werden um das Endbenutzerverhalten zu messen und damit den Wert neuer Entwicklungen zu bemessen. Die Analysenergebnisse sollten dann zur Verbesserung der Entwicklungsmethoden, zur Genehmigung oder zur Ablehnung von Funktionen, zur Priorisierung von Testaktivitäten usw. führen. Eine grafische Übersicht über die Vorgehensweise ist in Abbildung 1 dargestellt. Der vorgeschlagene Ansatz bezieht sich auf evidenzbasierte Software-Engineering [2] und Techniken, die in der Industrie als A/B-Tests [3] verwendet werden.

Unsere bisherige Forschung beinhaltet folgende Fragestellungen:
  1. Wie man schnelle und qualitativ hochwertige Entwicklung durch schnelles Feedback ermöglichen kann. Dafür untersuchen wir Continuous Integration Modellierungen und Best Practices.
  2. Wie man eine CMS-Architektur und einen Entwicklungsprozess anhand von realen Daten auswertet kann. Dafür untersuchen wir in Big Data Analytics für die Analyse der Qualität eines Systems auf der Grundlage von Betriebsdaten aus dem System.

Abbildung 3: Werkzeug-agnostische Continuous Integration Modellierung [4]



Abbildung 2: Continuous Integration: Schnelle Iterationen

Forschung zur Continuous Integration Modellierung und Best Practices

Continuous Integrationn (Abbildung 3) als Softwarepraxis bietet ein großes Potential zur Verbesserung der Produktivität in der Entwicklung und der generellen Kostensenkung. Allerdings ist sehr schwer, es für eine bestimmte Umgebung (Domain / Unternehmen / Projekt) so anzupassen, dass die meisten der damit verbundenen Vorteile auch gewonnen werden können. Insbesondere können sich Continuous Integration Systeme unterscheiden in folgenden Bereichen:
  • Build Dauer: Minuten, Stunden, …
  • Build Häufigkeit: Täglich, Wöchentlich, …
  • Build Auslöser: Änderungen am Programmcode, …
  • Tragweite: Kompilierung, Unit-Tests, Integrations-Tests, Code Analyse
  • Definition von Fehlern: Build-Fehler, Fehler in einzelnen Tests, …
  • Fehler Handhabung: vom Entwickler selbst, seperates Team, …
Die Frage lautet dann „Wie wählen man eine Option aus allen Varianten, so dass die Vorteile der Verwendung von CI in einer Domäne / Firma / Projekt maximiert werden?“

Zurzeit experimentieren wir mit der Anwendung eines Modellierungsansatzes für die Dokumentation von Continuous Integration Systemen (Abbildung 2) als ersten Schritt zur Verbesserung dieser.

Abbildung 4: Architektur des RTX Tools

Forschung im Bezug auf Big Data Analytics zur Analyse der Systemqualität basierend auf Betriebsdaten aus dem System

We have created an open-source tool called RTX for simplifying the experimentation with (self-)adaptation [5] based on Big Data analytics. Wir haben ein Open-Source-Tool namens RTX erstellt, um das durchführen von Experimenten mit (Selbst-)Anpassung [5] basierend auf Big Data Analytics zu vereinfachen. In the tool’s architecture (Abbildung 4), a Kafka broker facilitates the communication with any data-intensive system that can be adapted based on the results of Big Data analysis. In der Tool-Architektur (Abbildung 4) erleichtert ein Kafka-Broker die Kommunikation mit datenintensiven Systemen. Dieses System kann dann auf der Basis der Ergebnisse der Big Data-Analyse angepasst werden. Für die Datenanalyse können einfache Python-Skripte oder anspruchsvollere Spark-Jobs verwendet werden.

Kurz gesagt, jedes „Experiment“ in RTX:
  • Setzt einen Parameterwert in einem laufenden System
  • Sammelt für einiger Zeit Daten aus dem System
  • Analysiert sie, um daraus die System-Effizienz zu berechnen
Das Github-Projekt für RTX findet sich unter https://github.com/Starofall/RTX.

Kontakt

Bitte wenden Sie sich an Dr. Ilias Gerostathopoulos und Dr. habil. Christian Prehofer für den Fall, dass Sie sich für mehr Details oder eine Zusammenarbeit im Themenbereich Plattformarchitektur für Mobilitätssysteme oder verwandte BS- oder MS-Projekte bzw. geführte Forschungsthemen interessieren.

Referenzen

[1] Roland Berger Strategy Consultants. Connected Mobility 2025 (January 2013). https://www.rolandberger.com/de/Publications/pub_connected_mobility_2025.html
[2] Bosch, J. and Holmstrom Olsson, H. Data-driven continuous evolution of smart systems. pages 28-34. ACM Press, 2016.
[3] Kohavi, R., Crook, T., and Longbotham, R. Online Experimentation at Microsoft. In Third Workshop on Data Mining Case Studies and Practice, 2009.
[4] Stahl, D., and Bosch, J. Automated Software Integration Flows in Industry: A Multiple-case Study. Companion Proceedings of ICSE’14, 54-63, 2014.
[5] De Lemos, et al. Software Engineering for Self-Adaptive Systems: A Second Research Roadmap. In: Software Engineering for Self-Adaptive Systems II. pp. 1-32. Springer Berlin Heidelberg, 2013.