Hasso-Plattner-Institut25 Jahre HPI
Hasso-Plattner-Institut25 Jahre HPI
 

Reactive Programming (Wintersemester 2019/2020)

Lecturer: Prof. Dr. Robert Hirschfeld (Software-Architekturen) , Stefan Ramson (Software-Architekturen) , Marcel Taeumel (Software-Architekturen)

General Information

  • Weekly Hours: 4
  • Credits: 6
  • Graded: yes
  • Enrolment Deadline: 01.10.-30.10.2019
  • Teaching Form: Project seminar
  • Enrolment Type: Compulsory Elective Module
  • Course Language: German
  • Maximum number of participants: 15

Programs, Module Groups & Modules

IT-Systems Engineering MA
  • OSIS: Operating Systems & Information Systems Technology
    • HPI-OSIS-K Konzepte und Methoden
  • OSIS: Operating Systems & Information Systems Technology
    • HPI-OSIS-S Spezialisierung
  • OSIS: Operating Systems & Information Systems Technology
    • HPI-OSIS-T Techniken und Werkzeuge
  • SAMT: Software Architecture & Modeling Technology
    • HPI-SAMT-K Konzepte und Methoden
  • SAMT: Software Architecture & Modeling Technology
    • HPI-SAMT-S Spezialisierung
  • SAMT: Software Architecture & Modeling Technology
    • HPI-SAMT-T Techniken und Werkzeuge
Data Engineering MA

Description

Komplexe Softwaresysteme beinhalten eine Vielzahl von Abhängigkeiten. So hängt zum Beispiel die grafische Benutzeroberfläche einer Anwendung von den darunterliegenden Daten ab und muss aktualisiert werden, sollten sich diese Daten ändern. Eine traditionelle Lösungsstrategie für solche Abhängigkeiten innerhalb der Objekt-orienteirten Programmierung stellt das Observer-Entwurfsmuster dar. Diese Lösung besitzt jedoch einige Nachteile. So muss beispielsweise der Programmierer manuell Änderungen an den Daten signalisieren, was äußerst fehleranfällig im Falle von Codeänderungen ist. Weiterhin werden die gewünschten Abhängigkeiten lediglich implicit im Code mit Hilfe von Objekt-orientierten Konzepten ausgedrückt. Dies verschleiert den eigentlichen Zweck der Anwendung.

Die reaktive Programmierung bietet verschiedene Möglichkeiten Abhängigkeiten in einer Anwendung explizit zu machen. Somit lässt sich überschüssiger Architekturcode vermeiden. Die reaktive Programmierung bietet hierbei eine Vielzahl an Vorteilen. So zum Beispiel handelt es sich bei der reaktiven Programmierung ein deklaratives Paradigma und sie offenbart die Absichten des Codes indem spezifiziert wird, was passieren soll, anstatt wie dieses konkrete Verhalten umgesetzt wird. Weiterhin ist eine reaktive Ausführungsumgebung selbst dafür verantwortlich, Änderungen konsistent durch das gesamte System zu propagieren. Als Ergebnis ist eine reaktive Lösung robuster im Falle von Codeänderungen.

Aus der Grundidee der reaktiven Programmierung haben sich eine Vielzahl verschiedener Mechanismen herausgebildet. Die Implementierung dieser Konzepte stellt eine große Herausforderung für Systementwickler dar und beinhaltet häufig Meta-Programmierkonzepte oder das Verändern einer virtuellen Maschine. Im Verlauf des Seminars erarbeiten die Teilnehmer Anwendungsfälle, Mechanismen, Designs, Implementierungen, und Werkzeuge im Kontext der reaktiver Programmierkonzepte.

Requirements

  • Vertiefte Kenntnisse in JavaScript oder der gewählten Host-Programmiersprache/-umgebung
  • Themenspezifische Empfehlungen werden bei der Themenvorstellung bekanntgegebenen

Literature

  • Stefan Ramson and Robert Hirschfeld. Active Expressions: Basic Building Blocks for Reactive Programming. In Journal on The Art, Science, and Engineering of Programming, vol. 1, no. 2, art. 12, 49 pages, 2017. (pdf)
  • Tim Felgentreff, Alan Borning, Jens Lincke, Robert Hirschfeld, Yoshiki Ohshima, Bert Freudenberg, and Robert Krahn. Babelsberg/JS - A Browser-based Implementation of an Object Constraint Language. In Proceedings of the European Conference on Object-oriented Programming (ECOOP), Uppsala, Sweden, July 28-August 1, 2014, Springer. (pdf)

Weiterführende Literatur wird spezifisch für die jeweiligen Themen im Seminar bekanntgegeben.

Learning

Seminar

Examination

Vorträge, Diskussionen, Implementierung, Dokumentation und Mitarbeit in den Seminar- und Konsultationsterminen werden mit sechs benoteten Leistungspunkten angerechnet.

Jeder Seminarteilnehmer bzw. jede Seminargruppe bearbeitet selbstständig das gestellte Seminarthema vertiefend.

Die Bewertung ergibt sich wie folgt:

Vorträge (50%)

Das bearbeitete Thema wird in zwei Vorträgen zu je 15 - 30 Minuten Dauer präsentiert, an die sich jeweils eine Diskussion anschließt. Der erste Vortrag (20%) soll einen Zwischenstand präsentieren und dabei Kontext, Problemstellung, in Betracht gezogene Werkzeuge/Datenquellen, sowie Designoptionen und Literatur einführen. Der zweite Vortrag (30%) soll Design- und Implementierungsentscheidungen sowie abschließende Ergebnisse vorstellen und eine Vorführung entwickelter Softwareartefakte (Demo) enthalten.

Spätestens eine Woche vor dem jeweiligen Vortragstermin bespricht jede Gruppe eine Vorversion ihrer Vortragsunterlagen mit ihrem Betreuer. Um einen Termin für diese Vorbesprechung kümmern sich die Teilnehmer selbstständig. Die Vortragsunterlagen sind einen Tag vor dem Vortrag per E-Mail einzureichen. Sie bestehen für beide Vorträge aus

    den Dokumentquellen der im Vortrag verwendeten Folien,
    einer PDF-Version derselben
    dem in der Demo verwendeten Quelltext/Prototypen,
    ein Videoclip der Demo,
    einer Installationsbeschreibung, und
    einem Demo-Script.

  • den Dokumentquellen der im Vortrag verwendeten Präsentationsunterlagen,
  • einer PDF-Version derselben und
  • für den zweiten Vortrag zusätzlich aus
    • Quelltexten und Installationsanleitung der präsentierten Softwareartefakte
    • Demo-Videos/Screencasts

Artefakt (40%)

Die endgültigen Versionen von Implementierung und Ergebnissen sind spätestens zum Ende des Vorlesungzeitraums per E-Mail einzureichen oder, falls angebracht, auf dem bereitgestellten Server zu hinterlegen. Diese bestehen aus:

  • Quelltexten mit Installationsanleitung
  • Dokumentation, in der folgende Aspekte kurz dargelegt werden
    • Annahmen,
    • Vorgehensweise,
    • verwendete Literatur,
    • eine Diskussion des Artefaktes
    • und Einschränkungen/Grenzen des gewählten Ansatzes

Alle im Rahmen des Seminars erstellten Dokumente und Quelltexte sollten unter der MIT-Lizenz und, falls notwendig, mit einer den verwendeten Systemen kompatiblen Lizenz bereitgestellt werden. Wird das Einreichen verlangter Dokumente bis zum jeweils angegebenen Datum versäumt, so gelten diese als nicht eingereicht, was zur Abwertung der Gesamtleistung führt.

Wöchentliche Treffen (10%)

Die Teilnehmer treffen sich wöchentlich mit ihrem Betreuer zur Besprechung des Seminarfortschritts. Um einen Termin für diese Vorbesprechung kümmern sich die Teilnehmer selbstständig. Die wöchentlichen Treffen fließen anhand der folgenden Kriterien in die Bewertung mit ein:

  • Qualität der Zwischenergebnisse
  • Kontinuierlicher Fortschritt
  • Einbeziehen des erhaltenen Feedbacks

Dates

  • Einführung und Themenvorstellung, 15.10.2019, 15:15 Uhr, H E.52
  • Themenvergabe, 22.10.2019
  • Zwischenvorträge, 26.11.2019, 15:15 Uhr, 27.11.2019, 11:00 Uhr
  • Endvorträge, 04.02.2020, 15:15 Uhr, 05.02.2020, 11:00 Uhr
  • Abgabe Artefakt, 01.03.2020

Zurück