Übungsaufgaben zu Schichtenarchitektur, MVC und Data Binding

Die drei Schichten (je 1 Punkt):

• Präsentationsschicht: zeigt Daten an und nimmt Eingaben entgegen, hier die Barcamp-Web-App im Browser des Smartphones (Sessionplan, Buchungsformular).

• Logikschicht (Fach- bzw. Anwendungslogik): setzt die Regeln des Barcamps um, prüft Anfragen und steuert die Abläufe, z. B. „höchstens eine Buchung je Slot und Person“ oder die Berechnung der freien Plätze. Sie läuft im Backend auf bc-app.

• Datenhaltungsschicht: speichert, liest, ändert und löscht die Daten dauerhaft und kapselt den Zugriff auf die Datenbank barcamp (SQL-Befehle, Datenbankserver bc-db).

Zusammenwirken (3 Punkte für eine schlüssige Kette in beide Richtungen):

1. Die Web-App schickt eine HTTPS-Anfrage an die REST-API auf bc-app, z. B. „Sessions in Raum A.104“.

2. Das Backend prüft die Anfrage (gültiger Raum, nur angenommene und geplante Sessions) und beauftragt die Datenhaltungsschicht.

3. Die Datenhaltungsschicht stellt eine SQL-Abfrage an die Datenbank auf bc-db (Sessions, Slots, Raum, Buchungen) und erhält die Datensätze zurück.

4. Die Logikschicht bereitet das Ergebnis auf (z. B. nach Slot sortiert, freie Plätze berechnet) und sendet es als JSON an die Web-App.

5. Die Web-App stellt die Sessions auf dem Smartphone dar.

Wichtig für volle Punktzahl: Die Präsentationsschicht greift nicht direkt auf die Datenbank zu, jede Schicht nutzt nur die darunterliegende.

Je Zeile 0,5 Punkte, wenn Schicht und Frontend/Backend stimmen.

Hinweis zu Zeile 2 und 5: Auch wenn die Web-App die freien Plätze zusätzlich anzeigt oder eine Doppelbuchung schon im Formular verhindert, muss die Regel im Backend stehen. Nur dort gilt sie für alle Programme, und nur dort lässt sie sich nicht umgehen.

Je Grund 2 Punkte (Grund nennen und Folge erläutern), z. B.:

• Sicherheit: Die Zugangsdaten der Datenbank müssten im JavaScript-Code der Web-App stehen und wären für alle lesbar. Jede Person könnte beliebige SQL-Befehle schicken, also z. B. fremde Anmeldungen lesen oder löschen. Außerdem müsste die Datenbank aus dem Internet bzw. dem Gäste-WLAN erreichbar sein, was die Schul-IT nicht zulassen wird.

• Regeln nur an einer Stelle: Web-App, Check-in-App und Infomonitore bräuchten jeweils eine eigene Kopie der Regeln (Buchungsgrenzen, Barrierefreiheit). Weichen die Kopien voneinander ab, entstehen Fehler wie Überbuchungen, und jede Änderung muss dreimal programmiert werden.

• Wartbarkeit und Austauschbarkeit: Ändert sich die Tabellenstruktur, müssen alle Programme angepasst werden. Mit Logikschicht bleibt die Schnittstelle (REST-API) gleich, und nur die Datenhaltungsschicht ändert sich.

• Testbarkeit: Die Regeln lassen sich nicht unabhängig von Oberfläche und Datenbank testen.

Je Nachteil 1 Punkt, z. B.:

• mehr Programmieraufwand, weil Daten durch mehrere Schichten durchgereicht werden,

• längere Antwortzeiten durch zusätzliche Aufrufe und Netzwerkverbindungen,

• ein neues Datenfeld muss in allen Schichten nachgezogen werden,

• für sehr kleine Programme unnötig komplex.

Eine Schicht ist eine logische Gliederung des Programmcodes nach Aufgaben (Präsentation, Logik, Datenhaltung). Eine Ebene (tier) beschreibt die physische Verteilung auf Rechner oder Prozesse (1 Punkt).

Hannahs Aussage stimmt deshalb nicht allgemein: Drei Schichten können auch auf einem einzigen Rechner laufen oder auf zwei (z. B. Programm mit Oberfläche und Logik plus Datenbankserver). Bei der Barcamp-Software sind es tatsächlich drei Ebenen: Smartphone bzw. Tablet, bc-app und bc-db (1 Punkt).

Je Feld 1 Punkt:

• 1. Barcamp-Web-App im Browser (HTML, CSS, JavaScript), also die Präsentationsschicht bzw. das Frontend.

• (2) Webserver und Backend mit REST-API, Fachlogik und Datenzugriff (Logik- und Datenhaltungsschicht).

• (3) MariaDB-Datenbankmanagementsystem mit der Datenbank barcamp.

• (4) HTTPS-Anfragen an die REST-API, Daten im JSON-Format.

• (5) SQL-Befehle über TCP (MariaDB-Standardport 3306); als Antwort Ergebnistabellen.

Je Klasse 0,75 Punkte:

• Die Teilnahmeliste kennt ihre Anzeigen nur über eine Beobachter-Schnittstelle (z. B. update()), nicht über deren Klassen. Model und View sind dadurch lose gekoppelt (1 Punkt).

• Für die neue Begruessungsanzeige musste die Teilnahmeliste deshalb nicht geändert werden: Die neue View meldet sich als Beobachter an und wird ab dann automatisch benachrichtigt (1 Punkt).

• Beide Views zeigen immer denselben Stand, weil sie durch dieselbe Benachrichtigung aktualisiert werden. Außerdem lässt sich die Teilnahmeliste ohne Oberfläche testen und in einer anderen Oberfläche wiederverwenden (1 Punkt).

Ablauf:

1. Die CheckinMaske (View) meldet den gescannten Code an die CheckinSteuerung (Controller), z. B. badgeGescannt(code).

2. Die CheckinSteuerung fordert die Teilnahmeliste (Model) zur Zustandsänderung auf: checkIn(code) setzt die Check-in-Zeit.

3. Die Teilnahmeliste benachrichtigt alle registrierten Views über die Änderung: update() an CheckinMaske (3a) und Begruessungsanzeige (3b).

4. Beide Views holen sich die geänderten Daten beim Model ab, z. B. getLetzterCheckIn() und getAnzahlEingecheckt() (4a, 4b), und zeigen sie an.

Bewertung: vier Elemente mit Rollen (1 Punkt), Pfeile in der richtigen Richtung (2 Punkte, je fehlendem oder falsch gerichtetem Pfeil 0,5 Punkte Abzug), richtige Reihenfolge der Nummern (1 Punkt), sinnvolle Beschriftungen (2 Punkte). Eigene Methodennamen sind in Ordnung. Ein UML-Sequenzdiagramm oder Kommunikationsdiagramm mit derselben Nachrichtenfolge ist ebenfalls richtig. Gibt das Model die Daten gleich mit der Benachrichtigung weiter (push, z. B. update(anzahl, name)), entfallen die Nachrichten 4a/4b; das ist bei passender Beschriftung ebenfalls richtig.

Die Aussage ist so nicht richtig (1 Punkt für eine klare Stellungnahme), denn:

• MVC ist ein Muster für die Benutzeroberfläche und gliedert vor allem die Präsentationsschicht. View und Controller gehören beide zur Präsentation (1 Punkt).

• Der Controller steuert nur, was nach einer Eingabe passiert. Die Geschäftsregeln (z. B. „bereits eingecheckt“, Ticketart) gehören in die Logikschicht (1 Punkt).

• Das Model ist nicht die Datenbank, sondern ein Objekt, das den Zustand der angezeigten Daten hält und die Views benachrichtigt; dahinter liegen Logik- und Datenhaltungsschicht. Außerdem ist MVC nicht linear wie ein Schichtenmodell: Das Model benachrichtigt die View (1 Punkt).

Richtig an Hannahs Aussage ist nur, dass beide Konzepte die Software in drei Teile mit getrennten Zuständigkeiten aufteilen (Separation of Concerns).

Bei der Datenbindung wird eine Eigenschaft eines Steuerelements der Oberfläche (z. B. der Text eines Labels oder Eingabefelds) mit einer Eigenschaft eines Datenobjekts verknüpft (1 Punkt). Das Framework überträgt Änderungen automatisch, je nach Art der Bindung vom Datenobjekt zur Oberfläche oder in beide Richtungen; man muss dafür keinen eigenen Code zum Benachrichtigen und Aktualisieren schreiben (1 Punkt).

• 1. Zähler: einseitige Bindung (Datenobjekt → Oberfläche). Der Zähler wird nur angezeigt; niemand soll ihn in der Maske ändern, er ergibt sich aus den Check-ins (1,5 Punkte).
• (2) Name auf dem Badge: zweiseitige Bindung. Der Name wird aus der Anmeldung angezeigt, und eine Korrektur im Feld muss zurück in das Datenobjekt fließen, damit das Badge mit dem korrigierten Namen gedruckt wird (1,5 Punkte).

So könnte das in JavaFX aussehen (nicht verlangt):

labelZaehler.textProperty().bind(teilnahmeliste.zaehlerTextProperty());
feldBadgeName.textProperty().bindBidirectional(anmeldung.badgeNameProperty());

Je 1 Punkt, z. B.:

• Vorteil: weniger Code zum Anmelden, Benachrichtigen und Aktualisieren; keine vergessenen Aktualisierungen; die Verknüpfung ist deklarativ und übersichtlich.

• Nachteil: Abhängigkeit vom Framework; Fehler sind schwerer zu finden, weil die Aktualisierung „unsichtbar“ abläuft; bei zweiseitiger Bindung muss die Prüfung der Eingaben bewusst eingeplant werden.

• Das ViewModel hält den Zustand der View (z. B. Text des Zählers, ob der Druckknopf aktiv ist) und enthält die Präsentationslogik. Es nutzt das Model für Daten und Fachlogik (1 Punkt).

• Die View ist per (meist zweiseitigem) Data Binding an Eigenschaften des ViewModels gebunden; Eingaben und Anzeigen werden automatisch abgeglichen (1 Punkt).

• Das ViewModel kennt die Steuerelemente der View nicht. Dadurch lässt es sich ohne laufende Oberfläche mit Unit-Tests prüfen, und die View kann z. B. deklarativ in FXML beschrieben werden (1 Punkt).