Interaktive Mediensysteme: Architektur beginnt beim Fehlerfall
Wie aus Upload, Transkription und Videosuche eine wartbare Anwendung wird: Anforderungen, Zustandsmodelle, Modulgrenzen und Tests für interaktive Mediensysteme.
Der Upload ist fertig. Das Video lässt sich abspielen. Nur die Suche findet nichts, weil die Transkription im Hintergrund abgebrochen ist. Für das Backend sind das drei unterschiedliche Zustände. Für die Person vor dem Bildschirm ist die Anwendung kaputt.
Genau hier beginnt Software Engineering für interaktive Mediensysteme. Es verbindet Anforderungen, Architektur und Qualitätssicherung so, dass einzelne Komponenten einen verständlichen Gesamtablauf ergeben. Als Beispiel dient eine geplante Mediathek für Lehrvideos: hochladen, verarbeiten, eine Erklärung suchen und direkt an der passenden Stelle abspielen.
Anforderungen müssen beobachtbar werden
Eine funktionale Anforderung beschreibt, was das System tun soll. Eine Qualitätsanforderung legt fest, unter welchen Bedingungen und wie gut es das tun soll. „Das System bietet eine Videosuche“ lässt wichtige Fragen offen: Wird im Titel oder im gesprochenen Inhalt gesucht? Führt ein Treffer zum Videoanfang oder zur konkreten Aussage? Was passiert, solange das Transkript fehlt?
Anforderungsanalyse, Architektur, Tests und Betrieb gehören deshalb zu einem gemeinsamen Entwicklungsprozess. Der SWEBOK Guide der IEEE Computer Society ordnet diese Bereiche systematisch ein. Washizaki, Hrsg., 2024: Guide to the Software Engineering Body of Knowledge, Version 4
Für unsere Mediathek lässt sich eine überprüfbare Anforderung formulieren: Nach Auswahl eines Transkripttreffers öffnet sich das richtige Video an der gespeicherten Zeitmarke. Dazu gehören Akzeptanzfälle für fehlende Medien, unzulässige Zeitmarken und entzogene Zugriffsrechte. Erst dann kann das Team beurteilen, ob die Funktion vollständig ist.
Eine Zeitvorgabe wäre ebenfalls präzise zu definieren: Welche Hardware, welcher Datenbestand und welche Netzbedingungen gelten? Eine beliebige Millisekundenangabe ohne Messbedingungen hilft weder der Entwicklung noch der späteren Abnahme.
Zustände modellieren, bevor sich Sonderfälle verteilen
Ein einzelnes Feld ready wäre für die Beispielmediathek zu grob. Wiedergabe und Suche können zu unterschiedlichen Zeitpunkten verfügbar sein. Ein möglicher Entwurf trennt deshalb Medienzustand und Analysezustand:
| Bereich | Beispielzustände | Bedeutung für die Oberfläche |
|---|---|---|
| Mediendatei | Empfangen, geprüft, abspielbar, fehlgeschlagen | Ist das Video bereits nutzbar? |
| Transkript | Ausstehend, in Arbeit, verfügbar, fehlgeschlagen | Kann im gesprochenen Inhalt gesucht werden? |
| Suchindex | Ausstehend, aktuell, veraltet | Welche Transkriptversion ist erschlossen? |
Diese Zustände sind ein Entwurfsvorschlag. Entscheidend ist, erlaubte Übergänge festzulegen. Ein erneuter Transkriptionsversuch darf beispielsweise die bereits funktionierende Wiedergabe nicht zurücksetzen. Ein fehlgeschlagener Suchindexaufbau darf das vorhandene Transkript nicht verschwinden lassen.
Die Oberfläche benötigt daraus abgeleitete, verständliche Meldungen: „Video verfügbar, Transkript wird erstellt“ sagt mehr als ein endloser Ladeindikator. Wie solche Rückmeldungen geprüft werden, behandelt Teil 3 zur Mensch-Computer-Interaktion.
Modulgrenzen entlang der Verantwortung
Eine mögliche Architektur enthält Medienverwaltung, Verarbeitung, Suche und Benutzeroberfläche. Die Medienverwaltung kennt Dateien und Berechtigungen. Die Verarbeitung erzeugt Transkripte und Vorschauen. Die Suche erschließt diese Ergebnisse. Die Oberfläche setzt den Nutzungsvorgang zusammen.
Diese Trennung erfordert zunächst keine eigenständigen Netzwerkdienste. Für ein kleines Team können klar getrennte Module innerhalb einer Anwendung ausreichend sein. Eine spätere Auslagerung der Verarbeitung lässt sich begründen, wenn beispielsweise andere Hardware oder eine unabhängige Skalierung nötig wird. Der betriebliche Wert einfacher, verständlicher Systeme wird auch im SRE-Fachbuch von Google behandelt. Google: Site Reliability Engineering, „Simplicity“
Im Beispiel sollte die Suchkomponente nicht wissen müssen, welches Transkriptionsmodell verwendet wurde. Sie braucht einen stabilen Vertrag: Text, Zeitbereich, Medienversion und Herkunft. Diese Schnittstelle schafft Austauschbarkeit, ohne die Qualitätsunterschiede der Modelle zu verstecken. Teil 4 zum Datenmodell führt diesen Vertrag weiter.
Tests folgen den wichtigen Fehlerbildern
Ein Komponententest kann ungültige Zeitmarken abweisen. Ein Integrationstest kann prüfen, ob ein gespeichertes Transkript im Suchindex landet. Ein durchgängiger Test verfolgt einen Upload bis zur Wiedergabe eines Suchtreffers. Zusätzlich braucht das System Prüfungen für Ausfälle und Wiederholungen. Die Zuverlässigkeit einer Anwendung hängt auch davon ab, ob erwartbare Fehlverhalten gezielt untersucht werden. Google: Site Reliability Engineering, „Testing for Reliability“
Für die Mediathek wären besonders diese Situationen relevant: Der Browser verliert nach einem erfolgreichen Upload die Verbindung. Ein Auftrag wird zweimal zugestellt. Ein Video wird gelöscht, während sein Transkript noch verarbeitet wird. Eine Berechtigung ändert sich, nachdem der Suchindex erstellt wurde.
Die erwarteten Ergebnisse sollten vor der Implementierung feststehen. Beim letzten Fall dürfte ein älterer Suchtreffer jedenfalls keinen Zugriff auf ein inzwischen gesperrtes Video ermöglichen. Die technische Behandlung solcher verteilten Abläufe folgt in Teil 2 zum Web-Engineering.
Ein vollständiger Ablauf als erster Meilenstein
Für das Beispielprojekt wäre die erste Lieferung klein: ein Video importieren, Metadaten speichern und das Video abspielen. Danach kommt ein gespeichertes Transkript hinzu, anschließend die Suche. Jede Erweiterung ergänzt einen bereits benutzbaren Ablauf.
So werden fehlerhafte Annahmen an den Übergängen früh sichtbar. Ob eine intelligentere Suche den Aufwand rechtfertigt, kann später gegen diesen funktionierenden Ausgangspunkt geprüft werden. Der Projektartikel am Ende der Serie übersetzt diese Reihenfolge in konkrete Abnahmen.