You are here: Wiki>SE Web>ThesesHome>ThesesDPP (14 Jun 2018, FranzZieris)Edit

Offene Abschlussarbeiten im Softwareprojekt Saros ...

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 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.
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.
Falls Ihr Lieblingsthema wieder dort 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 Kelvin Glaß oder 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.

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:

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.

Die grafische Bedienschnittstelle von Saros wird dafür ebenfalls IDE-unabhängig mit Webtechnologien (HTML, JavaScript und CSS) entwickelt. Am Übergang zwischen Java und JavaScript müssen derzeit Model-Klassen und Funktionsrümpfe doppelt implementiert werden und es gibt keine statische Prüfung der Korrektheit. Es gibt Werkzeuge wie etwa Scala.js, die es erlauben, einmal geschriebenen Quellcode (hier: in Scala) in Java-Bytecode einerseits und JavaScript-Code andererseits zu übersetzen, wodurch eine saubere Integration von Modulen in beiden Programmiersprachen möglich wird.

Offene Abschlussarbeiten:
  • B - Überbrückung der Sprachgrenze zwischen Java und JavaScript mit Scala.js in der GUI des Saros-Plugins

Laufende Abschlussarbeiten:
  • B - Weiterentwicklung der HTML-GUI von Saros (Gobie Nanthakumar)

Abgeschlossene Abschlussarbeiten:

Google Summer of Code:

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:

  1. 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.
  2. 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).
  3. 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.

Special requirements:

  • Profound knowledge of Git concepts; experienced Git user.




... im Rahmen des Entwicklungsprozesses von Saros

Derzeit keine offenen Arbeiten.




... im Rahmen des Einsatzes von Saros

Derzeit keine offenen Arbeiten.
Topic revision: r61 - 14 Jun 2018, FranzZieris
 
  • Printable version of this topic (p) Printable version of this topic (p)