Offene Abschlussarbeiten im Softwareprojekt Saros …

09 Aug 2023 - 17:03 | Version 69 | UnknownUser

Saros ist ein Plugin für die IDEs Eclipse und IntelliJ, das verteilte, kollaborative Softwareentwicklung ermöglicht. Es wird seit 2006 hauptsächlich in der Arbeitsgruppe Software Engineering, aber auch von Freiwilligen aus der Open-Source-Community 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 1% aller Repositories.

Allgemeines

B: Bachelorarbeit, M: Masterarbeit

Saros-Server: Realisierung Nutzer-unabhängiger Sitzungen (B, M)
Portierung von Saros auf andere Entwicklungsumgebungen (B, M)
Git-Support für Saros (B, M)

Diese Arbeiten können noch gemacht werden, eignen sich aber inzwischen nur für extrem kompetente Softwareentwickler_innen, weil es in der Gruppe aktuell niemanden mehr gibt, der sich in der Codebasis von Saros gut auskennt und man deshalb auf technischer Ebene nur wenig Unterstützung bei der Durchführung bekommt. Saros ist durch seinen verteilt-nebenläufig-interaktiven Charakter und die Verzahnung mit mehreren hoch komplexen IDEs nicht einfach zu verstehen.

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.
Auch andere Ausrichtungen sind möglich.

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.

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.

Offene Abschlussarbeiten:

Derzeit keine

Laufende Abschlussarbeiten:

D - Entwicklung eines Saros Super Servers (Mehmet Cetinkaya)

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 (dem "Kern") verborgen werden.

Aktuell findet die Portierung von Saros auf die folgenden Plattformen statt:

IntelliJ IDEA (Status: Erste Alpha Releases verfügbar)
VSCode (Status: Früher Prototyp)

Offene Abschlussarbeiten:

Derzeit keine

Laufende Abschlussarbeiten:

Abgeschlossene Abschlussarbeiten:

Google Summer of Code:

Features for Saros for IntelliJ IDEA (Kasun Gunasekara)

Git-Support für Saros (B, M)

Background: In principle, Saros works orthogonal to traditional version control systems: It keeps the respective files in sync, regardless of whether they are part SVN or Git working copies -- or just plain folders and files. This also means that, by default, any VCS actions (such as svn/git commit, svn checkout, git pull) need to be performed by both Saros session participants to achieve consistency of the meta-data.

There are multiple possible implementations for Git support in Saros:

The easy case: Both developers have access to a shared Git repo. For this centralized scenario, the Git implementation is (almost) straight-forward and consists of coordinated sequences of git push, git pull, and git checkout.
The Git-way (1): Given that one of the developer's repository can already be accessed by the other developer through one of the standard "Git ways" (e.g. SSH). Then, a session start can be achieved by a git pull; git commit should be followed by a git reset + git pull (or git reset on one side/=git push= on the other, respectively).
The Git-way (2): If none of the standard protocols between the two developers is possible, Saros could provide a bridge, e.g. if Alice and Bob are in a Saros session, Bob pulls from a "remote" repository at localhost: which is a proxy for Alice's Git repo -- the actual communication is done via Saros.