Hier finden Sie eine Übersicht über Themen möglicher Abschlussarbeiten für Bachelor und Master sowie eine Liste bereits durchgeführter Arbeiten. Über die hier vorgestellen Themen hinaus sind weitere Themen und eine begleitende Betreuung mit Firmen auf Anfrage möglich, sofern diese in das Forschungsprofil der Arbeitsgruppe passen. Weiterhin haben wir selber guten Kontakt zu renommierten Firmen und können Arbeiten dort hin vermitteln.

Themenübersicht:

Kontext: Aktuellen Trends in der Digitalisierung und Virtualisierung führen dazu, dass der Energiebedarf von IT-Systemen stetig steigt. Verschiedene Prognosen schätzen, dass sich der Energieverbrauch bin 2030 verdoppeln wird. Im Hinblick auf die Erderwärmung und die Klimaziele der Bundesrepublik ist es notwendig, diesem Energiebedarf entgegen zu wirken.

Probleme&Motivation: Ein Weg, um den Energieverbrauch von IT-Systemen zu reduzieren, ist Quelltext-Optimierung. Für Entwickler ist allerdings gerade bei großen Projekten nicht ersichtlich, wo Energie eingespart werden kann. Für Ausführzeit-Optimierungen gibt es bereits Profiler, die Zeit messen und damit langsame Funktionen ermitteln; für Energieverbrauch-Optimierung bietet sich ein ähnlicher Ansatz an, doch lösen aktuell verfügbare Messgeräte zeitlich viel zu grob auf um Rückschlüsse auf einzelne Methoden zuzulassen.
Ziel der Arbeit: Um Energieverbrauch auf Methodenebene zu messen, wird ein Messsystem benötigt, welches im Nanosekunden-Bereich Energie messen kann. Es kann auf ein bestehendes System mit Energie-Messpunkten (INA226), einem Mikrocontroller-DevBoard (Teensy 4.0) und Raspberry Pi zurückgegriffen werden. Eine Besondere Herausforderung stellt die Verabrietung der Daten in Echtzeit dar.
Das resultierende System soll von anderen Forschenden leicht reimplementiert werden können um weitere Forschung an Energieverbrauchs-Optimierung zu begünstigen. Dementsprechen sollten verfügbare und erschwingliche Materialien verwendet und entwickelter Quelltext dokumentiert und veröffentlicht werden.
Quellen: 

Kontext: Viele Unternehmen entwickeln Softwaresysteme mit KI- oder ML-Komponenten. Dabei unterscheidet sich der Entwicklungsprozess deutlich von herkömmlicher Software. KI-Modelle müssen erneut trainiert werden, benötigen Feedback und liefern nicht immer das korrekte Ergebnisse. Hinzu kommen große Datenmenge, Modellupdates und Versionierungsherausforderungen, die in herkömmlichen Systemen nicht gegebene sind.

Probleme&Motivation: Das Wissen über die unterschiedlichen Ansätze zu den oben beschriebenen Problemen und Herausforderungen wird geteilt, wurde aber nie zusammen gefasst. Es gibt dutzende bis hunderte von Erfahrungsberichten in Blocks, Videos, Tutorials oder Publikationen. Allerdings fehlt ein Überblick über sich wiederholende Best Practices oder Widersprüche oder gar überhaupt wichtige Aufgaben die gelöst werden müssen.

Ziel der Arbeit: Eine Analyse von Industrieberichten jeglicher Form hinsichtlich der Besonderheiten, Aufgaben und Lösungen der Softwareentwicklung von KI-Systemen. Dabei soll eine Klassifikation über die Prozesse erstellt werden, wie auch eine Übersicht über offene Probleme, typische Schwierigkeiten und Best Practices.

Quellen: Das große, weite Internet. 🙂

  • Industriekonferenzen (PyCon, JavaLand, +100 weitere)
  • Blogs und Berichte von Unternehmen und Entwicklern
  • Forschungskonferenzen mit Industrie-Tracks oder Industriepapern

Kontext: Moderne Softwaresysteme haben oft eine Vielzahl an Optionen, die nichtfunktionale Attribute des Systems, wie den Energieverbrauch, beeinflussen. In vielen Anwendungsfällen werden Konfigurationen gesucht, die bspw. den Energieverbrauch minimieren.

Probleme&Motivation: Verschiedene Performance-Influence-Modelling-Ansätze versuchen bereits, den Einfluss von Optionen und deren Interaktionen zu beschreiben. Allerdings wächst die Zahl der möglichen Interaktionen mit der Anzahl an Optionen exponentiell, weshalb muss man sich auf einen kleinen Teil derer beschränken muss. Für diese Auswahl gibt es viele mit Unsicherheiten verbundene Möglichkeiten. Aktuelle Ansätze treffen eine Auswahl und betrachten die Möglichkeit für andere einflussreiche Optionen und Interaktionen nicht.

Ziel der Arbeit: Mit dieser Arbeit soll Proabilistic Programming genutzt werden, um Performance-Influence-Modelling-Ansatz zu entwickeln, der Unsicherheiten in der Modellstruktur berücksichtigt. Für Probabilistic Programming gibt es diverse Frameworks, welche die Abschätzung der Ungewissheit übernehmen und Symbolic Regression ist dafür bekannt, Modellstrukturen lernen zu könenn. Ziel ist es, die Konzepte beider Paradigmen zu kombinieren. Dabei sollten zur Verfügung stehende Frameworks verglichen und Ergebnisse des Ansatzes evaluiert werden.

Quellen:

  •  Symbolic Regression Frameworks
    • https://github.com/ambrosys/glyph
    • https://deap.readthedocs.io/
  • Probabilistic Programming
    • https://pyro.ai/
    • https://www.tensorflow.org/probability/
    • https://docs.pymc.io/
  • https://towardsdatascience.com/symbolic-regression-and-genetic-programming-8aed39e7f030

Kontext: Active Learning beschreibt ein Machine Learning Szenario, bei dem das Modell Stück für Stück selbst entscheidet, welche Daten es für das Training benötigt. Da die Zahl der möglichen Konfigurationen exponentiell mit der Anzahl der Optionen eines konfigurierbaren Softwaresystems wächst, ist Active Learning in diesem Feld besonders vielversprechnd um bspw. den Energieverbrauch bei relativ wenig Messungen gut vorhersagen zu können.

Probleme&Motivation: Aktuelle Ansätze wählen oft Pool-Based-Active-Learning, welches dem Modell einen alle Konfigurationen umfassenden Pool zur Auswahl für die nächst Messung gibt. Für größere Systeme ist das nicht machbar, da es zu viele Konfigurationen gibt.

Ziel der Arbeit: Als Alternative zum Pool-Based-Sampling soll ein Active-Learning-Ansatz entwickelt werden, der anhand der Modell-Parameter und die damit verbundenen Unsicherheiten entscheidet, welche Konfigurationen als nächstes gemessen werden sollen. Hierfür können bestehende Probabilistic-Programming-Ansätze als Grundlage für Modelle, die eine Unsicherheitsinschätzung bieten, genutzt werden, Ziel ist es somit auch, sich Kenntnisse zu Probabilistic Programming anzueignen.

Quellen:

  • Burr Settles. “Active Learning Literature Survey.” Computer Sciences Technical Report. University of Wisconsin-Madison, 2009.
  • TBA

Kontext: Die Optionen von konfigurierbaren Softwaresystemen und deren Nebenbedingungen werden mit Variabilitätsmodellen (VM) erfasst. Sie definieren, welche Kombination von Optionen eine valide Konfiguration darstellen, und welche nicht. Attributierte Variabiliätsmodelle (AVM) fügen jeder Option einen Wert hinzu, der ihre Einfluss auf eine nicht-funktionale Eigenschaft des Systems, z.B. den Energieverbrauch, hat. Basierend auf AVMs wurden Ansätze entwickelt, die eine opimale Konfiguration bezüglich eines NFP finden.

Probleme&Motivation: Optimierungsansätze für AVMs müssen untereinander vergleichbar sein. Hierfür benötigt man VM in verschiedenen Größen, möglichst mit einer bliebigen Anzahl an Optionen. Gleichzeitig müssen VMs für den Vergleich realistisch sein, doch gibt es nicht genügend reale Systeme.

Ziel der Arbeit: Ziel ist es, ein gegebenes reales VM auf eine beliebige Optionenzahl zu vergrößern oder zu verkleinern. Dabei sollen VMs generiert werden, die hinsichtlich ihrer Struktur und ihrer Nebenbedingungen realistisch sind. Um diese Kriterien zu erfüllen, ist es weiterhin Ziel, sich mit Genetischen Algorithmen vertraut zu machen.

Quellen:

  • Siegmund, Norbert, Stefan Sobernig, and Sven Apel. “Attributed Variability Models: Outside the Comfort Zone.” In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, 268–78. ESEC/FSE 2017. New York, NY, USA: ACM, 2017. https://doi.org/10.1145/3106237.3106251.
  • Dorn, Johannes, Sven Apel, and Norbert Siegmund. “Generating Attributed Variability Models for Transfer Learning.” In Proceedings of the 14th International Working Conference on Variability Modelling of Software-Intensive Systems, 1–8. Magdeburg Germany: ACM, 2020. https://doi.org/10.1145/3377024.3377040.

Kontext: Ein wesentlicher Bestandteil der Softwareentwicklung und Wartung besteht in der Bereinigung von Programmfehlern (kurz Bugs). Dabei gibt es domänenspezifische Bugs, die abhängig von der Logik des Programmes sind, und domänenunabhängige Bugs, wie NullPointer Exceptions, Teilung durch Null, fehlerhafte Nutzung von Resourcen, usw. Solche domänenunabhängigen Bugs tauchen immer wieder in unterschiedlichen Softwareprojekten auf. Um diese Fehler zu finden und zu beheben wird oftmals die Community befragt. StackOverflow ist das bekannteste Portal für Programmierfragen, die sich auch zum großen Teil um Fehler und deren Behebung dreht.

Probleme&Motivation: StackOverflow bietet einen reichen Schatz von Programmierproblemen und deren Lösungen in Form von Fragen und Antworten. Gleichzeitig schlummern zahlreiche Softwarefehler im Source Code vieler Projekte, die mit Hilfe dieser Fragen und Antworten gefunden und behoben werden könnten.

Ziel der Arbeit: Ziel der Arbeit ist es, den Schatz zu bergen und automatisiert anzuwenden. Im Speziellen sollen Techniken angewendet werden, um StackOverflow nach typischen Fragen zu Programmierfehlern zu durchsuchen und den entsprechenden Code in den Fragen und Antworten zu encodieren (z.B. als Vektor). Die encodierten Fragen stellen dabei ein Muster dar, welches zur Detektion von Bugs in Open Source Softwaresystemen angewendet werden soll, um dort ähnliche Fehler zu finden. Falls diese detektiert sind, soll automatisiert ein Fix erstellt werden mit Hilfe der Antworten. Auf diese Weise können großen Menge an Source Code automatisiert nach typischen Programmierfehlern durchsucht und gefixt werden.

Vorwissen: Machine Learning,Natural Language Processing und Deep Learning sind hilfreich. Ansonsten sollte man sich etwas Einarbeitungszeit einplanen.

Quellen:

– https://stackoverflow.blog/2019/08/14/crokage-a-new-way-to-search-stack-overflow/

– TBA

Kontext: Software Testing ist eines der wichtigsten Disziplinen im Software Engineering und in der Softwareentwicklung generell. Aufgrund der hohen Kosten zum Finden und Beheben von Fehlern im Code werden ständig neue Ansätze entwickelt, um schneller, genauer und automatisiert Softwarefehlern zu finden und zu fixen.

Probleme&Motivation: Die große und ständig wachsende Anzahl von Tools und Papern im Bereich des Software Testing macht es schwer zu ermitteln, welcher Ansatz überlegen oder überhaupt einsetzbar ist in der Praxis. Weiterhin ist unklar, welche Systeme getestet werden und ob die Resultate vergleichbar oder reproduzierbar sind.

Ziel der Arbeit: Das Ziel der Arbeit ist durch eine tiefgreifende Analyse der Literatur zum Thema Software Testing festzustellen, ob die Forschung an der Praxis vorbei geht und die Resultate überhaupt reproduzierbar sind. Dabei sollen wissenschaftliche Artikel bzgl. der vorgebrachten Ansätze auf ihrer Vergleichbarkeit und Reproduzierbarkeit hin untersucht werden. Ein Augenmerk liegt dabei, ob Vergleich selbst gemacht werden mit anderen Ansätzen, ob es gemeinsame Standards gibt, um Software Testing Ansätze zu evaluieren und zu bewerten und wie dabei die wissenschaftlichen Artikel sich referenzieren und verlinken.

Quellen: TBA

Kontext: Software Engineering ist ein breites Feld mit vielen Themenschwerpunkten. Obwohl das Feld sehr Praxis-orientiert ausgerichtet ist, werden in der Forschung und Industrie unterschiedliche Themenschwerpunkte gesetzt. Dies ist verständlich, da die Forschung möglichst frühzeitig Lösungen zu Problemen anbieten muss, die eventuell noch nicht relevant sind, oder Grundlagenforschung betreiben soll, um Fern ab vom Alltagsgeschäft neuartige Ansätze zur Softwareentwicklung zu bieten. Im Gegensatz dazu muss die Industrie darauf bedacht sein Lösungen zu erarbeiten, die einen ökonomischen Vorteil bieten und derzeitige aktuelle Probleme lösen. Dabei ist es erstaunlich, dass sowohl die Akademie als auch Industrie große Konferenzen und Tagungen hat, um Wissen zu verbreiten, es jedoch kaum Schnittstellen hierfür gibt.

Probleme&Motivation: Warum gibt es keine oder nur kaum gemeinsame Konferenzen und Meetings zwischen Wissenschaft und Praxis? Gibt es unterschiedliche Interessen beider Gruppen? Sind die Ausgangslagen so unterschiedlich, dass es schwierig ist für Forscher an relevanten Themen zu arbeiten oder bleibt einfach keine Zeit in der Praxis, um relevante Forschungsansätze umzusetzen? Was sind die Themen in beiden Bereichen? Gibt es Überlappungen oder Zeitverzögerungen? Gibt es Hypes, die einander beeinflussen?

Ziel der Arbeit: Die Arbeit soll sich genau im Spannungsfeld zwischen Wissenschaft und Praxis im Software Engineering bewegen und obige Fragen durch Interviews, Analysen von Vortragsthemen auf Konferenzen, in Meetups, und Veranstaltungen, und Surveys beantworten. Dabei sollen thematische Schwerpunkte und deren zeitlicher Verlauf in beiden Bereichen erkannt und modelliert sowie mögliche Brücken identifiziert werden. So können vielleicht einzelne Personen, die die Bereiche überqueren, Firmen, die sowohl Forschen als auch Entwicklen, oder relevante Themengebiete für einen Austausch und eine Zusammenarbeit der Disziplinen erkannt werden. Ein Ziel der Arbeit wäre dann möglichst solche Potentiale aufzuzeigen und Vorschläge für eine bessere Zusammenarbeit treffen zu können. Was kann die Wissenschaft von der Praxis lernen und wie können die Firmen das Wissen in der Forschung nutzbar machen?

Quellen: TBA

Kontext: Heutige IDEs haben eine sehr gute Unterstützung von Code Suggestions — vorgeschlagene Code snippets oder API Aufrufe. Gleichzeitig wird intensiv daran geforscht, diese Vorschläge intelligenter und weitreichender zu machen, um eventuell nicht nur einzelne Statements, sondern ganze Code Blöcke vorzuschlagen.

Probleme&Motivation: Wir wollen die Produktivität heutiger IDEs steigern, indem wir die Intention des Programmierers erkennen und entsprechend Vorschläge zur Vervollständigung des Codes anbieten.

Ziel der Arbeit: Ziel der Arbeit ist es, Code Suggestions basierten auf einem gelernten Modell (Deep Learning Language Model) mit Hilfe zusätzlicher Kontextinformationen zu verbessern. Dabei soll auf die Informationen in IntellJ Idea zurück gegriffen und hierfür ein Plug-In entwickelt werden, um eine vollständige Lösung zu präsentieren. Fragen in der Arbeit sind dabei: Was sind hilfreiche Kontextinformationen zur Code Generierung? Welches Language Model bietet die beste Akkuratheit? Ist das Tool praxistauglich? Welche Vorverarbeitungsschritte sind notwendig? Ist eventuell ein Retrieval-Ansatz (statt Generierung von Code, Suche nach ähnlichem Code in Repositories oder StackOverflow) besser geeignet?

Quellen: TBA

Kontext: KI-basierte Softwaresysteme durchdringen immer mehr unser tägliches Leben. Es werden weitreichende Entscheidungen getätigt, die teilweise hochgradig ethisch sind. So werden z.B. automatisiert Bewerbungen gefiltert, Kreditwürdigkeiten bewertet, Chat Systeme ausgeliefert oder sogar Rückfallwahrscheinlichkeiten von Kriminellen berechnet. All diese Entscheidungen sind hochgradig anfällig für Bias (systematische Fehler, Befangenheit, etc.).

Probleme&Motivation: Die Forschung und Industrie hat zahlreiche Ansätze und Vorschläge unterbreitet, um dem Problem des Bias oder der Fairness zu begegnen. Jedoch ist es unklar, wie diese Ansätze systematisch eingeordnet und in einen Zusammenhang gebracht werden können. Was ist kombinierbar oder welcher Ansatz ersetzt welche Handlungsanweisung? Was ist überhaupt vergleichbar oder sogar besser? Welche Fallstudien gibt es, um Ansätze zu testen? Gibt es Unterschiede von Ansätzen in der Industrie und Forschung?

Ziel der Arbeit: Das Ziel der Arbeit ist ein ganzheitliches Bild zum derzeitigen Stand von Fairness Testing in der Forschung und Praxis zu erstellen, um dadurch Lücken und Schwachpunkte zu identifizieren, Alternativen für bestimmte Anwendungsfelder aufzuzeigen und eine generelle Bewertung zu schaffen. So kann ein Resultat der Arbeit ein klarer Anweisungsleitfaden sein inkl. von Werkzeugen und Techniken, um faire, unbefangende Softwaresysteme realisieren zu können.

Quellen: TBA

Kontext: KI-basierte Softwaresysteme durchdringen immer mehr unser tägliches Leben. Es werden weitreichende Entscheidungen getätigt, die teilweise hochgradig ethisch sind. So werden z.B. automatisiert Bewerbungen gefiltert, Kreditwürdigkeiten bewertet, Chat Systeme ausgeliefert oder sogar Rückfallwahrscheinlichkeiten von Kriminellen berechnet. All diese Entscheidungen sind hochgradig anfällig für Bias (systematische Fehler, Befangenheit, etc.).

Probleme&Motivation: Wie kann ein Ansatz aussehen, der nicht nur den KI-Algorithmus und statistische Wahrscheinlichkeiten berechnet, um Fairness Probleme zu identifizieren oder zu verhindern, sondern der maßgeschneidert auf unterschiedliche Moralvorgaben reagiert werden kann.

Ziel der Arbeit: Das Ziel ist es ein Tool zu entwickeln, welches in der Lage ist, alle Eingaben und Verarbeitungen, die zu ethisch relevanten Entscheidungen oder Ausgaben in einem Softwaresystem führen zu identifizieren und (optional) konfigurierbar zu machen. Dabei sollen Techniken der statischen Programmanalyse (z.B. Taint-Analyse, Program Slicing) angewendet werden.

Quellen: TBA

Kontext: Performance von konfigurierbaren Softwaresystemen hängt von Konfigurationen ab. Konfigurationsoptionen entsprechen dabei oft unterschiedlicher Funktionalität. Inkrementelle Änderungen (Commits) an Softwaresystemen können die Performance verbessern oder veschlechtern.

Probleme&Motivation: Retrospektiv lassen sich Commits, welche die Performance ändern, gut erklären, z.B. wenn performance-relevante Code-Abschnitte geändert werden oder Commits/Branches entsprechend gekennzeichnet sind.

Ziel der Arbeit: In einer qualitativen Studie sollen Entwickler dazu befragt werden, welche Indikatoren in der Praxis ihrer Erfahrung nach auf performance-relevante Änderungen hinweisen und nach welchen Regeln sie selbst Performance-Änderungen kennzeichnen.

Die Ergebnisse der Umfrage sollen mit Performance-Messungen von realen Softwaresystemen verglichen und diskutiert werden.

Quellen:

Olaf Leßenich, Janet Siegmund, Sven Apel, Christian Kästner, and Claus Hunsen. 2018. Indicators for merge conflicts in the wild: survey and empirical study. Automated Software Eng. 25, 2 (June 2018), 279–313.

Stol, Paul Ralph, and Brian Fitzgerald. 2016. Grounded theory in software engineering research: a critical review and guidelines. In Proceedings of the 38th International Conference on Software Engineering (ICSE ’16). Association for Computing Machinery, New York, NY, USA, 120–131.

Kontext: Performance von konfigurierbaren Softwaresystemen wird durch Konfigurationen bestimmt. Konfigurationsoptionen entsprechen dabei oft unterschiedlicher Funktionalität. Der Einfluss einzelner Optionen auf die Performance eines Softwaresystemen kann sich über die Zeit, zum Beispiel mit einem neuen Commit ändern und die Performance einer Teilmenge von Konfigurationen ändern.

Probleme&Motivation: Die Performance eines (nicht-konfigurierbaren) SWS über die Zeit lässt sich effizient Gauß-Prozessen modellieren. In dieser Arbeit soll ein bestehendes Verfahren auf reale Softwaresysteme angewendet werden. Gauß-Prozesse lassen sich durch die Wahl einer Kernel-Funktion auf verschiedene Arten von Daten anpassen.

Ziel der Arbeit: Ziel dieser Arbeit ist es, einen bestehenden Ansatz zur Modellierung von Performance-Historien auf reale Softwaresysteme anzuwenden sowie den Ansatz zu erweitern. Hauptaugenmerk liegt dabei auf der Erweiterung für konfigurierbare Softwaresysteme sowie der Evaluation verschiedener Kernel-Funktionen.

 Quellen:

Roberts S, Osborne M,Ebden M, Reece S, Gibson N, Aigrain S. 2013. Gaussian processes for time-series modelling. Philosophical Transactions of the Royal Society A 371: 20110550

Stefan Mühlbauer, Sven Apel, and Norbert Siegmund. 2019. Accurate modeling of performance histories for evolving software systems. In Proceedings of the 34th IEEE/ACM International Conference on Automated Software Engineering (ASE’19). IEEE Press, 640–652.

Thema derzeit vergeben

Kontext: Aktuellen Trends in der Digitalisierung und Virtualisierung führen dazu, dass der Energiebedarf von IT-Systemen stetig steigt. Verschiedene Prognosen schätzen, dass sich der Energieverbrauch bin 2030 verdoppeln wird. Im Hinblick auf die Erderwärmung und die Klimaziele der Bundesrepublik ist es notwendig, diesem Energiebedarf entgegen zu wirken.

Die Analyse des Energieverbrauchs von IT-Systemen ist ein nicht triviales Feld in der Forschung. Sowohl Hardawre als auch Software hat einen Einfluss auf den Energirverbrauch. Die große Anzahl an verschiedenen Kombinationsmöglichkeiten (unterschiedliche Hardware und Software) macht es schwer eine optimale Konfiguration zu finden.

Probleme&Motivation: Um dieses Problem anzugehen haben wir ein Energiemesssystem für Office PCs entwickelt, mit dem wir sowohl den Energieverbrauch wie auch die Performance aller aktiven Anwendungen messen können. Wir haben im Rahmen von einer 2-monatigen Studie Daten alle Daten erhoben [1]. Dieser Datensatz soll die Grundlage für die Arbeit sein.

Ziel der Arbeit: Ziel der Arbeit ist es, die gesammelten Daten auszuwerten und den Einfluss von Hardware und Softwarekonfigurationen auf Performance und Energieverbrauch zu modellieren und zu vergleichen. Anschließend können konkrete Handlungsweisen abgeleitet und geteste werden.

Quellen:

Kontext: Aktuellen Trends in der Digitalisierung und Virtualisierung führen dazu, dass der Energiebedarf von IT-Systemen stetig steigt. Verschiedene Prognosen schätzen, dass sich der Energieverbrauch bin 2030 verdoppeln wird. Im Hinblick auf die Erderwärmung und die Klimaziele der Bundesrepublik ist es notwendig, diesem Energiebedarf entgegen zu wirken.

Probleme&Motivation: In der Literatur befassen sich einige Arbeiten mit der Sicht der Developer, andere beleuchten die Einstellung von Unternehmen im Generellen zum Energieverbrauch von Soft- und Hardware. Es ist jedoch vor allem auf Seiten der Entscheidungsträger (Hardare- und Softwarebeschaffung, Verwaltung und Administration, …) nicht klar, welche akuten Probleme existieren.

Ziel der Arbeit: Durch eine Literaturanalyse soll der ‚Ist-Zustand‘ in der Forschung erfasst werden. Daraus resultierend sollen dann, mithilfe von Fragebögen, Interviews, Surveys, u.s.w., Perspektiven verschiedener Akteure (Entscheidungsträger, Developer, Forscher, Anwender, …) erfasst und gegenüber gestellt werden um aktuelle Probleme und Aufgaben zu identifizieren.

Quellen:

  • Pang, Candy, et al. „What do programmers know about software energy consumption?.“ IEEE Software 33.3 (2015): 83-89.
  • Jagroep, Erik, et al. „Energy efficiency on the product roadmap: An empirical study across releases of a software product.“ Journal of Software: Evolution and process 29.2 (2017): e1852.

Kontext: Die Komplexität aktueller Softwaresysteme ist groß. Durch eine Vielzahl von Konfigurationsoptionen sollen die Systeme an die verschiedene Bedürfnisse der Nutzer angepasst werden. Verschiedene Eigenschaften von Sorftwaresystemen wie Performance und Energieverbrauch müssen otimiert werden.

Probleme&Motivation: Die Konfigurationsbedingte Komplexität der Systeme erschwert Analysen mit herkömmlichen Hilfsmittel. Um Softwaresysteme besser verstehen zu können wurden eine Vielzahl von Tools entwickelt [1, 2, 3]. Diese Tools betrachten jeweils einzelne wichtige Aspekte der Systeme, wie Performance, Energieverbrauch, Konfigurierbarkeit, Feature Influence Tracing, u.s.w., sind aber immer auf den 2D-Raum von PC monitoren beschränkt. Dadurch wird es schwer Zusammenhänge innerhalb der Systeme zu erkennen. Wir wollen die ein Tool entwickeln, welches die Möglichkeiten der existierendne Tool vereinigt und in der Virtuellen Umgebung mehr Raum und natülichere Interaktionsmöglichkeiten bietet.

Ziel der Arbeit: Ziel der Arbeit soll es sein, das bestehende Framework zu erweitern um das Verstehen von Zusammenhängen zischen Features, Softwareeigenschaften und Source Code zu ermöglichen.

Quellen:

[1] FeatureIDE: https://featureide.github.io/
[2] Flame Graphs: http://www.brendangregg.com/flamegraphs.html
[3] Code City: https://wettel.github.io/codecity.html

Sie können Themenvorschläge machen oder basierend auf Vorlesungen von uns heran treten, falls eines der obigen Themen nicht passend ist. Weiterhin stehen wir offen für eine Betreuung von Themen in Firmen, sofern es thematisch passt. Eine NDA wird aber ausgeschlossen! Wir haben ebenfalls Kontakt zu renommierten Firmen und können dabei helfen Abschlussarbeiten zu vermitteln.

Laufende Arbeiten:

Thema derzeit vergeben

Kontext: Performance von konfigurierbaren SWS hängt von Konfigurationen bestimmt. Konfigurationsoptionen entsprechen dabei oft unterschiedlicher Funktionalität.

Probleme&Motivation: Benchmarks sind in der Regel nicht konfigurierbar und können für verschiedene Konfigurationen unterschiedlich gut geeignet sein, da Funktionalität durch Workloads nicht abgedeckt wird.

Ziel der Arbeit: Existierende konfigurierbare Systeme sollen auf folgende Fragestellungen untersucht werden:

– Zu welchem Grad sind Benchmarks (nicht) konfigurierbar?

– Wird durch fehlende Konfigurierbarkeit Funktionalität nicht abgedeckt?

– Lassen sich Benchmarks konfigurierbar umgestalten?

– Welche Anforderungen sollten an konfigurierbare Benchmarks gestellt werden?

Quellen:

Sven Apel, Don Batory, Christian Kästner, and Gunter Saake. 2016. Feature-Oriented Software Product Lines: Concepts and Implementation (1st. ed.). Springer Publishing Company, Incorporated. (Kapitel 1 bis 4)

Norbert Siegmund, Alexander Grebhahn, Sven Apel, and Christian Kästner. Performance-Influence Models for Highly Configurable Systems. In Proceedings of the European Software Engineering Conference and the ACM SIGSOFT International Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 284–294. ACM Press, August 2015.

Norbert Siegmund, Sergiy Kolesnikov, Christian Kästner, Sven Apel, Don Batory, Marko Rosenmüller, and Gunter Saake. Predicting Performance via Automated Feature-Interaction Detection. In Proceedings of the IEEE/ACM International Conference on Software Engineering (ICSE), pages 167–177. IEEE Computer Society, June 2012

Thema derzeit vergeben

Kontext: In moderner Softwareentwicklung werden Technologien wie Containerisierung, Continuous Integration und Delivery, Microservices und Cloudentwicklung immer wichtiger. Diese Technologien erfordern es, dass Entwickler zusätzlich zu ihren Programmieraufgaben entsprechende Tools und Softwareumgebungen konfigurieren müssen.

Motivation und Problem: All diese Tools können nicht unabhängig voneinander konfiguriert werden. Oft hängt die Konfiguration eines Tools von der eines anderen ab. Diese Abhängigkeiten können kompliziert werden dadurch, dass zum Beispiel manchmal ein bestimmtes Verhalten an mehreren Stellen im Software-Stack eingestellt werden kann. Fehler in diesen Konfigurationen kann zu falschem Verhalten, Instabilität oder Sicherheitsproblemen führen.

Um dieses Problem anzugehen, haben wir angefangen ein graphbasiertes Tool zu entwickeln, dass Konfigurationsoptionen von Technologies als Knoten und ihre Abhängigkeiten als Kanten darstellt um potenzielle Fehler zu erkennen und Lösungen vorzuschlagen. Verschiedenen Tools, die in einem Projekt verwendet werden können, werden als Plugins integriert.

Ziel der Arbeit: Ziel der Arbeit ist es, unser in Python implementiertes Tool zu verbessern und zu evaluieren. Bisher sind nur eine kleine Anzahl an Technologien als Plugins integriert und Standardkonfigurationen (zum Beispiel durch Convention over Configuration) werden nicht beachtet. Auch die Erkennung von Abhängigkeiten muss noch überarbeitet werden. Weiterhin kann ein Plugin für eine IDE entwickelt werden, dass unser Tool benutzt. Am Ende soll das Tool/IDE-Plugin evaluiert werden.

Literatur und Quellen:

Thema derzeit vergeben

Kontext: In moderner Softwareentwicklung werden Technologien wie Containerisierung, Continuous Integration und Delivery, Microservices und Cloudentwicklung immer wichtiger. Diese Technologien erfordern es, dass Entwickler zusätzlich zu ihren Programmieraufgaben entsprechende Tools und Softwareumgebungen konfigurieren müssen.

Motivation und Problem: All diese Tools können nicht unabhängig voneinander konfiguriert werden. Oft hängt die Konfiguration eines Tools von der eines anderen ab. Diese Abhängigkeiten können kompliziert werden dadurch, dass zum Beispiel manchmal ein bestimmtes Verhalten an mehreren Stellen im Software-Stack eingestellt werden kann. Fehler in diesen Konfigurationen kann zu falschem Verhalten, Instabilität oder Sicherheitsproblemen führen. Um diese Probleme anzugehen, brauchen wir einen besseren Überblick auf welche Probleme Entwickler beim Konfigurieren von Software stoßen.

Ziel der Arbeit: Ziel der Arbeit ist es, Stack Overflow und GitHub nach verschiedenen Arten von Konfigurationsfehlern und -problemen, deren Auswirkungen und Lösungen zu analysieren. Dadurch soll ein Überblick über die verschiedenen Arten von Problemen geschaffen werden um herauszufinden in welche Richtung weitere Forschung gehen sollte.

Literatur und Quellen:

Abgeschlossene Arbeiten