HTW Berlin · FB 1 Energie und Information · Modul Softwaretechnik

Erweiterung einerDjango-To-do-Liste

Meilenstein MS_02 — Überarbeitung der Modelle, Architekturentscheidungen und Implementierung. Vom Konzept zur lauffähigen, öffentlich erreichbaren Anwendung.

LIVE · htwtodo.de

Team

Fabrizio Rampino
Kyryl Dukhota
Markus Bischoff

Betreuung

Prof. Dr. Thomas Baar

Meilenstein

MS_02 (aufbauend auf MS_01)

Datum

Juni 2026

scrollen

Überblick · Ausgangslage

Ein bestehendes Projekt — übernommen und erweitert

VORHER · BASIS-PROJEKT (OPEN SOURCE)

Original von Nneji123 (MIT) — Login & einfache Aufgaben

NACHHER · UNSER HTW ORGANIZER

Neues Design, Rollen, Kurse, Dashboard, Live-Deployment

Von MS_01 zu MS_02

Alles Geplante umgesetzt — und deutlich mehr

GEPLANT IN MS_01 — UMGESETZT

✓
Priorität (low / medium / high)
✓
Fälligkeitsdatum + Überfällig-Markierung
✓
Design-Upgrade
✓
Dozent-Bereich

ZUSÄTZLICH IN MS_02

+
Kurse, Kursaufgaben & Datei-Abgaben
+
Fortschritts-Dashboard & kombinierte Suche
+
Deployment: Docker + Cloudflare Tunnel

ARCHITEKTUR-ÄNDERUNG

⟳
User-Vererbung ersetzt durch ein Profil-Modell

Iterativ entwickelt in versionierten Ständen v5 → v8, damit jede Änderung nachvollziehbar bleibt.

Korrekturen aus dem MS_01-Feedback

Drei Hinweise — drei klare Reaktionen

Hinweis

„Systemkonfiguration" ist keine Verbphrase

Reaktion

Alle Anwendungsfälle als Verb + Objekt formuliert — z. B. „System konfigurieren", „Kurs anlegen", „Aufgabe veröffentlichen".

Hinweis

User — eine abstrakte Klasse?

Reaktion

Vererbung aufgelöst und durch eine 1:1-Komposition mit einem Profile-Modell ersetzt. Die Abstraktheits-Frage entfällt.

Hinweis

Aktoren unklar abgegrenzt

Reaktion

Aktoren präzisiert: Gast, Student, Dozent, Administrator. Administration läuft über die Django-Admin.

Designentscheidung

Profil-Modell statt Vererbung

Abb.: Klassenhierarchie → 1:1-Komposition

Django liefert mit auth.User bereits eine konkrete, vom Framework verwaltete Benutzerklasse. Davon abzuleiten ist unüblich.

Jeder Benutzer erhält über eine OneToOne-Beziehung ein Profile.
Das Profil trägt die Rolle (student / lecturer) und optional die Matrikelnummer.
Die Rolle wird zum Attribut statt zu einer Klassenhierarchie — das Authentifizierungssystem bleibt unangetastet.

Rollen & Zugang

Wer darf was — und wie kommt man rein?

Abb.: Registrierung, Rollenvergabe und Login-Weiterleitung

Gäste registrieren sich selbst — dabei wird automatisch ein Profil mit Rolle student angelegt.
Dozenten schaltet die Admin frei: in der Django-Admin wird bei einem Profil die Rolle auf lecturer gesetzt.
Beim Login entscheidet die Rolle über das Ziel — serverseitig, nicht über die URL umgehbar.

Login zum HTW Organizer

Dozierende · Kurse & Aufgaben

Der Dozent legt Kurse an und veröffentlicht Aufgaben

Dozenten-Dashboard — Kurse und Kursaufgaben verwalten

Kurse anlegen (z. B. Mathe 2, English) — sie stehen danach allen Studierenden zur Auswahl.
Aufgaben veröffentlichen mit Titel, Kurs, Priorität, Fälligkeit und Beschreibung.
Eine Aufgabe erscheint nur bei Studierenden, die den Kurs gewählt haben.
Kurse lassen sich löschen — persönliche Aufgaben bleiben erhalten.

Studierende · Kurse & Überblick

Studierende wählen ihre Kurse — Aufgaben kommen automatisch

Kurse auswählen — belegte Kurse markieren

Persönliches Dashboard mit Fortschritt und Suche

Die belegten Kurse werden am Profil gespeichert (courses, n:m-Beziehung). Auf dem Dashboard erscheinen dann die eigenen Aufgaben und die Kursaufgaben der gewählten Kurse.

Weitere Funktionen

Kleine Details mit großer Wirkung

01 · FINDEN

Suche, Filter & Sortierung

Titel-Suche und Kursfilter wirken gleichzeitig; Aufgaben werden nach Priorität sortiert — hoch → mittel → niedrig.

02 · SEHEN

Priorität & Überfällig

Prioritäten sind farblich gekennzeichnet, überfällige Aufgaben werden optisch hervorgehoben.

03 · ABGEBEN

Datei-Abgaben

Zu Kursaufgaben können Studierende Dateien hochladen — erlaubt sind PDF, PNG, JPG, DOCX und ZIP.

Ein Blick in den Code · Objektorientierung

Django ist durch und durch objektorientiert

models.py — ein Model ist eine Klasse

class Task(models.Model):
    user     = models.ForeignKey(User, ...)
    title    = models.CharField(max_length=200)
    complete = models.BooleanField(default=False)
    priority = models.CharField(choices=PRIORITY_CHOICES)
    due_date = models.DateField(null=True)

    def __str__(self):
        return self.title

views.py — Vererbung + Mixin

class TaskCreate(LoginRequiredMixin, CreateView):
    model  = Task
    fields = ['title', 'category',
              'priority', 'due_date']

    def form_valid(self, form):
        form.instance.user = self.request.user
        return super().form_valid(form)

KLASSEN & OBJEKTE

Jedes Model ist eine Klasse, jede Datenbankzeile ein Objekt, jedes Feld ein Attribut.

VERERBUNG & MIXINS

Views erben von Djangos generischen Views und kombinieren Mixins — Mehrfachvererbung.

METHODEN ÜBERSCHREIBEN

Eigenes Verhalten durch Überschreiben von form_valid(), get_success_url(), __str__().

Datenmodell im Detail

Die zentralen Modelle

Profile 1:1 zu User

userOneToOne(User)

roleChar(choices)

matriculation_numberChar(optional)

coursesM2M(Category)

Category = Kurs

nameCharField

Task erweitert

userFK(User)

titleCharField

completeBoolean

created_atDateTime

due_dateDate · neu

priorityChar · neu

categoryFK · neu

Für den Kurs-Workflow kommen zwei Modelle hinzu: CourseTask (vom Dozenten veröffentlichte Aufgabe) und Submission (Datei-Abgabe eines Studierenden). Umgesetzt über Django-Migrationen.

Zustandsmodell einer Aufgabe

Lebenszyklus — und ein abgeleiteter Zustand

Abb.: Zustandsmodell der Task

DIE POINTE

„Überfällig" wird nicht gespeichert

Es gibt kein eigenes Status-Feld. Eine offene Aufgabe gilt als überfällig, sobald due_date < heute — die Markierung entsteht erst bei der Anzeige.

Das trennt berechnete von gespeicherten Zuständen und vermeidet Redundanz im Datenmodell.

Systemarchitektur & Bereitstellung

Wir haben es wirklich deployed

Abb.: Browser → Cloudflare → Tunnel → Raspberry Pi

Aus dem Dockerfile (Python 3.8-slim) wird ein Image gebaut; beim Build läuft collectstatic, Auslieferung über WhiteNoise.
Django läuft im Container über Gunicorn auf 0.0.0.0:8000.
cloudflared baut einen Cloudflare Tunnel — öffentlich per HTTPS, ohne Portfreigabe im Router.
Läuft auf einem Raspberry Pi unter htwtodo.de.
ALLOWED_HOSTS und CSRF_TRUSTED_ORIGINS für die Domain gesetzt.

Validierung & Test

10 Akzeptanztests — alle bestanden

ID	Testfall	Status
T2/T3	Login leitet rollengerecht weiter	✓ bestanden
T4	Student wird vom Dozenten-Dashboard abgewiesen	✓ bestanden
T5	Aufgabe mit Priorität & Fälligkeit, überfällig markiert	✓ bestanden
T6/T7	Dashboard-Kennzahlen · Suche + Filter kombiniert	✓ bestanden
T9/T10	Login & Zugriff über die HTTPS-Domain	✓ nach Fix

0 / 10

Testfälle bestanden

Unterwegs behobene Probleme

Fehlerhafter Gunicorn-Start (Port als Modul interpretiert)
TemplateDoesNotExist (login.html)
CSRF- und DisallowedHost-Fehler über die Domain
IPv6-Problem: Tunnel von ::1 auf 127.0.0.1 umgestellt

Risiken & Ausblick

Ehrlich über Grenzen & nächste Schritte

RISIKEN

SQLite begrenzt die Parallelität → bei Bedarf PostgreSQL
Einzelner Raspberry Pi = Single Point of Failure → Backups, Monitoring
Abhängigkeit vom Cloudflare Tunnel
DEBUG=True ist für den Produktivbetrieb noch abzuschalten

OFFENE PUNKTE & AUSBLICK

Automatisierte Tests (Unit / Integration) fehlen bislang
Bewertung / Feedback zu Abgaben noch nicht umgesetzt
UI zur Pflege der Matrikelnummer noch offen
Nächster Schritt: Enddokumentation mit Tests & vollständigem Quellcode

Lessons Learned & Fazit

Vom Konzept zur laufenden Anwendung

01

Frühe Modelle sind vorläufig. Die Vererbung wich dem idiomatischen Profil-Modell — Modelle dürfen sich begründet ändern.

02

Framework-Konventionen nutzen. Klassenbasierte Views, Mixins und Migrationen haben uns viel Arbeit abgenommen.

03

Berechnet vs. gespeichert trennen. „Überfällig" wird abgeleitet — das vermeidet Redundanz.

04

Deployment ist eigene Arbeit. Container, HTTPS und Tunnel brachten Host-, CSRF- und IPv6-Hürden mit sich.

Danke — Fragen?

LIVE · htwtodo.de