You are here: Wiki>SE Web>ThesesHome>ThesesDPP (16 Nov 2017, FranzZieris)Edit

Offene Abschlussarbeiten im Softwareprojekt Saros ...

Saros ist ein Eclipse-Plugin für verteilte, kollaborative Softwareentwicklung. Es wird seit 2006 hauptsächlich in der Arbeitsgruppe Software Engineering entwickelt und hat mittlerweile Industriereife erreicht. Es wird weltweit von kommerziellen Softwareentwicklern und Hobbyisten eingesetzt.

Saros ist Open Source, war eines von 137 Projekten des Google Summer of Code 2015, und gehört auf GitHub zu den populärsten 0,2% aller Repositories.

Allgemeines

B: Bachelorarbeit, M: Masterarbeit

In allen Fällen sind solide Kenntnisse in Java und ein Interesse daran, sich in ein Team von Student/inn/en, wissenschaftlichen Mitarbeiter/inn/en und Open-Source-Entwickler/inn/en zu integrieren, von großem Vorteil.

Alle Arbeiten können wahlweise auf Deutsch oder Englisch geschrieben werden.

Wie diese Seite zu lesen ist

Dies sind keine "zu vergebenen Abschlussarbeiten", sondern mögliche Stoßrichtungen.
Damit sind die Themen tendenziell umfangreicher, als es der Rahmen einer einzigen Abschlussarbeit vorsehen würde. Einige Themen listen bereits mögliche Abschlussarbeiten auf, bei anderen hingegen müssen diese erst noch herausgeschält werden. Der Umfang vieler Themen lässt sich demnach sowohl auf Bachelor- als auch Master-Niveau anpassen, wobei bei Master-Arbeiten naturgemäß der konzeptionelle und methodische Anspruch höher ist.

Diese Liste ist nicht vollständig.
Einerseits ist Saros ein Open-Source-Projekt, d.h. informieren Sie sich auch auf der Projekt-Webseite über aktuell laufende Aktivitäten, z.B. hier: http://www.saros-project.org/ongoing-work.
Andererseits geht Denken neuer Gedanken oftmals viel schneller als das textuelle Ausformulieren. Falls also Ihr Lieblingsthema wieder da noch hier dabei ist, kein Problem: Prinzipiell findet sich die gesamte Softwaretechnik auch im Saros-Projekt wieder.

Bitte melden Sie sich bei Interesse direkt bei Franz Zieris, um konkrete Ideen – gerne auch eigene – zu besprechen.




... im Rahmen technischer Weiterentwicklung

Saros-Server: Realisierung Nutzer-unabhängiger Sitzungen (B, M)

Allgemeine Beschreibung. Die derzeitige Konzeption von Saros sieht es vor, dass sich eine Sitzung nur aus menschlichen Teilnehmern konstituiert, von denen einer (der "Host") die Sitzung leitet und für die Konsolidierung aller Sitzungsaktivitäten (z.B. Editor- und Navigationsvorgänge aller Teilnehmer) zuständig ist. Das hat u.a. zur Folge dass die Sitzung mit eben jenem Host steht und fällt: Verlässt er die Sitzung (geht z.B. offline), ist diese damit beendet und eine nahtlose gemeinsame Weiterarbeit der verbleibenden Teilnehmer ist nicht möglich.

Ein alternatives Sitzungskonzept kommt ohne einen menschlichen Host aus. Ein "Saros-Server" hält dabei eine laufende Saros-Sitzung vorrätig (oder startet sie bei Bedarf neu), in die sich interessierte Entwickler/innen einklinken könnten. Eine so gehostete Sitzung ist nicht nur unabhängig vom Zu- oder Abgang Einzelner, sondern hat darüber hinaus das Potenzial, die generelle Arbeitsweise in einem Team zu verändern: Zwei Entwickler könnten sich so auch ohne vorherige Absprache bei Gelegenheit in die immer gleiche Sitzung einklinken und am jeweiligen Stand weiterarbeiten; entweder kollaborativ, falls beide verfügbar sind -- oder eben ganz traditionell in Solo.

Mögliche Abschlussarbeiten. Für ein erstes lauffähiges Setup, das den oben beschrieben Anwendungsfall implementiert, müssten an der bestehenden Code-Basis nur vergleichsweise schmale Änderungen vorgenommen werden. Inhalt einer Arbeit kann also ein "Proof of Concept" (ein Machbarkeitsnachweis) sein. In dieser prototypischen Umsetzung würden z.B. die kritischen Anforderungen an eine technisch saubere Umsetzung erhoben werden.

Einige Herausforderungen:
  • Derzeit wird ein laufendes Saros-Exemplar immer von einem menschlichen Nutzer verwendet und somit auch "überwacht": Treten Fehlverhalten auf, haben die Teilnehmer zumindest die Möglichkeit zu reagieren (z.B. die Sitzung neu aufbauen). Wird die Sitzung nicht in diesem Sinne "geleitet", muss die entsprechende Software etwaige Versagen abfangen und korrigieren.
  • Derzeit wird für eine Saros-Sitzung -- außer laufenden Eclipse-Installationen samt Saros-Plugin bei allen Teilnehmern -- nur ein XMPP-Server für die Kommunikation benötigt. Soll ein Server nun ein (passiver) Sitzungsteilnehmer werden, so verändern sich damit die Ansprüche an die Infrastruktur, da die Serverkomponente schließlich auch einen Computer für die Ausführung benötigt.
  • Soll der Zustand einer Sitzung persistiert werden, auch wenn vorübergehend kein menschlicher Nutzer teilnimmt, muss dieser Knoten zwangsläufig auch den Quellcode bzw. sonstigen Session-Inhalt zwischenspeichern. Für den industriellen Einsatz mag das Abstellen eines weiteren Servers denkbar sein, für die Allgemeinheit sollte Saros aber auch weiterhin den Server-losen Modus unterstützen.

Laufende Abschlussarbeiten:

Abgeschlossene Abschlussarbeiten:


Portierung von Saros auf andere Entwicklungsumgebungen (B, M)

Allgemeine Beschreibung. Saros wurde von Anfang an als ein Eclipse-Plugin entwickelt. In der Landschaft der Entwicklungsumgebungen steht Eclipse nun aber nicht allein da; in vielen Unternehmen werden auch andere IDEs wie etwa IntelliJ IDEA oder Netbeans eingesetzt. Während die Entwicklung von Plugins auch für diese Plattformen prinzipiell möglich ist, ist ein Plattform-übergreifender Austausch von Plugins nicht direkt möglich.

Technisch müssen also Eclipse-Spezifika aus der Saros-Codebasis in einem Modul versteckt und so vor dem Plattform-unabhängigen Teil von Saros verborgen werden. Analog zu diesem Saros-Eclipse-Modul lassen sich dann Implementierungen für andere IDEs ergänzen, wie wir es bereits für IntelliJ vor einiger Zeit begonnen haben.

Einige Herausforderungen. Parallel zu den technischen Änderungen am Quellcode, bei denen nach Eclipse-spezifischen und -unspezifischen Aspekten getrennt wird, muss auch die Entwicklungs-Infrastruktur von Saros angepasst werden. So muss die neu hinzukommende Variation (verschiedene IDEs) z.B. im Build-, Test- und Release-Prozess abgebildet werden.

Laufende Abschlussarbeiten:
  • ...

Abgeschlossene Abschlussarbeiten:

Google Summer of Code:


Reintegration des neuen Saros-Whiteboards (B)

Allgemeine Beschreibung. Das Saros-Whiteboard ist ein weiteres Eclipse-Plugin, das mit Saros ausgeliefert wird. So wie Saros gleichzeitiges Editieren von Quellcode ermöglicht, bietet das Whiteboard diese Funktionalität für schematische Zeichnungen an.

Die aktuelle Fassung des Whiteboards ist wenig benutzerfreundlich, sodass es bereits vor einiger Zeit einer Frischzellenkur unterzogen wurde. Allerdings war der resultierende Patch viel zu groß um durchgesehen zu werden. Mittlerweile wurde dieser Patch schon zerlegt und es wurde damit begonnen, diese Stücke der Saros-Codebasis zurückzuführen.

Vergleich des aktuellen, alten (links) mit dem neuen, praktisch-schon-fertigen Whiteboard (rechts):

Mögliche Abschlussarbeiten.
  • Vollständige Reintegration des neueren Whiteboards in die Saros-Code-Basis.
  • Neuimplementierung der Oberfläche mit HTML5-Technologien. Aktuell baut das Whiteboard auf dem Eclipse Graphical Editing Framework (GEF) auf. Im Zuge der Portierung von Saros (s.o.) sollte auch das Whiteboard IDE-unabhängig werden.




... im Rahmen des Entwicklungsprozesses von Saros

Konfigurationsmanagement der Saros-Entwicklungsinfrastruktur (B)

Allgemeine Beschreibung. Dreh- und Angelpunkt für die technische Weiterentwicklung von Saros ist der Server "saros-build", der v.a. Dienste für Code-Reviews (Gerrit) und Continuous Integration (Jenkins) bereitstellt. In diesem Umfeld gibt es zwei Ebenen auf denen eine Komplexitätsreduktion nötig ist:
  1. Die Build-Prozesse der Saros-Teil- und -Nebenprojekte (insbesondere mit der Unterstützung mehrerer IDEs, s.o.) und
  2. die Systemadministration der beteiligten Server (neben "saros-build" gibt es noch zwei weitere Systeme, z.B. zur Durchführung von nächtlichen Testläufen).

Einige Herausforderungen.
  • Eine sorgfältige Anforderungserhebung: Berücksichtigung konfligierender Anforderungen der "Anwender" (Saros-Entwickler) und des Rechnerbetriebs (etwa Abwägungen zwischen Bequemlichkeit und Sicherheit). Das erforderte eine enge Zusammenarbeit mit beiden Interessengruppen.
  • Eine gründliche und vollständige Bestandsaufnahme: Die bestehenden Strukturen sind über Jahre gewachsen -- im wesentlichen funktional, aber umständlich zu warten.
  • Planung- und Organisation: Geringe Störung des Regelbetriebs, d.h. wenig Ausfallzeiten der im Saros-Entwicklungsprozess benötigten Systeme

Abgeschlossene Arbeiten:


Teilautomatisierung des Wissensmanagements beim Code-Review-Prozess (B)

Allgemeine Beschreibung. Ein verbesserter Code-Review-Prozess für das Saros-Projekt könnte so aussehen (Neuerungen im Vergleich zum Status Quo sind hervorgehoben)
  • Autor erstellt einen Patch und lädt ihn zur Durchsicht auf Gerrit
  • Gutachter sieht ein (mehr oder weniger grundlegendes) Prinzip verletzt oder ein wiederkehrendes Problem auftauchen, wie etwa das Nicht-Freigeben von Farbwerten.
  • Gutachter erklärt das Problem und fügt davor einen Präfix in Wiki-Syntax, also z.B. "MustReleaseColors".
  • Ein Programm durchsucht die Kommentare nach solchen Vorkommnissen und extrahiert die Erklärung, sodasssie über eine URL erreichbar wird, also z.B. http://www.saros-project.org/kb/MustReleaseColors
  • Bei einer späteren Durchsicht können sich die Gutachter daran erinnern, dass es einen solchen "Eintrag" schon gibt und ihn verlinken, oder sie erstellen einen neuen, der dann später geparst und in die Knowledge Base übernommen wird.

Folgende Teilaspekte wären zu beachten:
  • Die Sinnhaftigkeit dieses Unterfangens sollte durch eine kleine Vorstudie geklärt werden.
  • Ein gemeinsames Vokabular für die Wiki-Schlüsselwörter (feste Struktur, wenige Verben) muss etabliert werden.
  • Mehrfach-Erklärungen sind erlaubt (wenn z.B. zweimal "MustReleaseColors" erklärt wurde); Möglichkeit zur Konsolidierung von existierenden Einträgen sollte aber dennoch gegeben sein.
  • Vielleicht sind auch Backlinks aus der Knowledge-Base heraus hilfreich: "Wo, in welchem Kontext wurde diese Regel erstmals erklärt?"

Laufende Abschlussarbeiten:


Teilautomatisierung des Managements der Entwickler-Doku (B)

Allgemeine Beschreibung. Die Entwickler-Dokumentation von Saros teilt sich grob in Produkt- und Prozessaspekte. In den ersten Bereich fallen Architektur- und Modul-Beschreibungen. Der zweite Bereich zerfällt in Anleitungen (etwa Einrichten der Entwicklungsumgebung, Umgang mit typischen Problemen, Release-Prozess) sowie Regeln (etwa Coding-Conventions, Code-Review-Regeln).

Regeln und Konventionen sind genau wie die Anleitungen einem steten Wandel unterworfen, sei es durch Prozessverbesserungen oder geänderte technische Rahmenbedingungen, sodass die entsprechenden Drupal-Seiten von Zeit zu Zeit geändert werden müssen. Die in der Regel hoch strukturierte Natur dieser Informationen (z.B. viele listenhafte Aufzählungen) würde sich allerdings auch mit einen rein text-basierten Ansatz vertragen. Dieser hätte außerdem den Charme, dass Änderungen an allen Teilen der Dokumentation durch das ohnehin genutzte Review-System kanalisiert und dort viel konkreter als bisher diskutiert werden könnten.

Für die Einstiegsdokumentation existierte bereits ein auf dem DocBook-Format basierendes Git-Repository, das als separate HTML-Seite und PDF-Datei gebaut wurde. Bisher gelang die Einbettung dieser Information in die Drupal-Seite nicht, sodass Änderungen an der Dokumentation nur noch direkt in die Drupal-Seiten eingepflegt wurden.

Aufgabe:
  • Einen Mechanismus zur nahtlosen Integration in die Drupal-Installation implementieren.
  • Die bestehenden Dokumentationsinhalte in ein text-basiertes Format überführen.
  • Einen Begutachtungs- und Ausrollprozess für Dokumentationsanpassungen aufsetzen.

Weitere Hinweise:
  • DocBook ist nur ein mögliches Format. Auf der Saros-Mailingliste bereits erwähnt wurde auch Jekyll.
  • Entscheidend für den praktischen Einsatz ist das Zusammenspiel der Inhalte aus dem Git-Repo und der weiterhin über Drupal gepflegten Inhalte. Auch hier scheint es bereits Erfahrungen zu geben: Link.




... im Rahmen des Einsatzes von Saros

Innovationseinführung von Saros zur verteilten kollaborativen Softwareentwicklung in Unternehmen (B, M)

Allgemeine Beschreibung. Jede Organisation, die verteilte Softwareentwicklung betreibt, kann Saros potentiell gut gebrauchen. Das gilt insbesondere wenn die Beteiligten nicht im selben Büro oder Gebäude arbeiten.

Verwenden kann man Saros für verschiedene Zwecke bei der kommerziellen Softwareentwicklung:
  • Gemeinsames Ansehen von Code, um jemandem was zu erklären, jemandem um Rat zu fragen oder gemeinsam Mängel zu suchen (Reviews, Walkthroughs).
  • Verteilte Paarprogrammierung, d.h. die eng gekoppelte gemeinsame Arbeit an einer gemeinsamen Aufgabe.
  • Verteilte Side-by-Side-Programmierung, d.h. die lose gekoppelte Zusammenarbeit, bei der man die meiste Zeit an verschiedenen Aspekten und nur gelegentlich direkt zusammen arbeitet, auch mit mehr als zwei Personen.

Mögliche Abschlussarbeiten. Unternehmen finden, die Saros einsetzen könnten. Dabei kann man sich einerseits auf die Kontaktaufnahme mit möglichst vielen Firmen konzentrieren und einen Leitfaden entwickeln, der die Strategie einer Innovationseinführung einer Open-Source-Software zur verteilten kollaborativen Softwareentwicklung beschreibt. Andererseits besteht die Möglichkeit, sich ein Unternehmen auszuwählen und in diesem den Innovationsprozess mit Saros zu begleiten.

Einige Herausforderungen. Eine Herausforderung dieser Arbeit besteht darin, geeignete Unternehmen zu finden, diese zu kontaktieren und als Kooperationspartner zu gewinnen. Einerseits hat sich der initiale Aufbau solcher Kontakte als schwerer erwiesen als man vielleicht denken könnte (siehe hier), andererseits mehren sich durch den immer häufigeren industriellen Einsatz von Saros die Kontaktaufnahmen von Firmen an uns.


Einführung von Saros in Open-Source-Projekten (B, M)

Allgemeine Beschreibung. Saros wurde als Werkzeug explizit konzipiert, um in Open-Source-Projekten eingesetzt zu werden, bei denen die Entwickler nur selten die Möglichkeit haben, direkt zusammenzuarbeiten (wenn man von Hackathons und ein paar Konferenzen wie Fosdem, Akademy etc. mal absieht).

Mögliche Abschlussarbeiten. Dieses Konzept in der freien Wildbahn umsetzen und Open-Source-Projekten die Nutzung von Saros näher bringen. Dies hört sich jetzt erst mal nach Werbung an, wird sich aber wohl eher in harter technischer Arbeit und qualitativer Forschung niederschlagen.

Einige Herausforderungen. Mitbringen sollte man auf jeden Fall die gewisse Affinität zu Open-Source-Projekten und Spaß an der Arbeit und Kommunikation mit anderen. Die beste Voraussetzung für die Einführung von Saros in ein Open-Source-Project ist es, wenn man bereits selbst Mitglied des Projekts ist und dann andere Projektmitglieder animieren kann an Saros-Sitzungen teilzuhaben.
Topic revision: r59 - 16 Nov 2017, FranzZieris
 
  • Printable version of this topic (p) Printable version of this topic (p)