Block 11 · Entwicklungsumgebung & Werkzeuge – Lösungen

a) Zentral vs. verteilt (2 P)

Bei einer zentralen Versionsverwaltung (z. B. Subversion) gibt es nur ein Repository mit der gesamten Historie auf einem Server. Die Entwickler haben lediglich eine Arbeitskopie; Commits, Historie und Vergleiche erfordern eine Verbindung zum Server. Bei einer verteilten Versionsverwaltung (z. B. Git) besitzt jeder Entwickler einen vollständigen Klon des Repositorys einschließlich Historie. Commits erfolgen lokal (auch offline); Änderungen werden per push/pull mit anderen Repositories, meist einem gemeinsamen Remote-Repository, ausgetauscht.

b) Begriffe (3 P)

a) Commit-Graph nach Befehl (10) (4 P)

Die Reihenfolge von N gegenüber F1/F2 auf der Zeitachse ist beliebig (N entstand parallel). origin/main steht nach Befehl (9) ebenfalls auf M; die Angabe ist optional.

b) Fast-Forward? (2 P)

• Befehl (6) git pull: ja, Fast-Forward. Der lokale main hat seit C keine eigenen Commits; auf origin/main folgt nur N auf C. Git schiebt den Zeiger main einfach von C auf N vor – es entsteht kein neuer Commit.
• Befehl (7) git merge: kein Fast-Forward. Seit C haben sich beide Zweige weiterentwickelt: main um N, der Feature-Branch um F1 und F2. Git muss die Änderungen zusammenführen und erzeugt den Merge-Commit M mit den zwei Vorgängern N und F2.

c) Merge-Konflikt (3 P)

Ursache: Seit der Abzweigung von feature/MP-131-anfahrt wurde dieselbe Zeile in anfahrtspauschale() auf beiden Seiten unterschiedlich geändert: auf main (HEAD) wurden die Pauschalen auf 89/39 € erhöht, im Feature-Branch wurde die Berechnung um einen Entfernungsanteil (0,50 €/km) erweitert. Git kann nicht entscheiden, welche Fassung gelten soll, und bricht den automatischen Merge ab.

Auflösen:

1. Mit git status die betroffene Datei ermitteln und im Editor/IDE-Merge-Werkzeug öffnen.
2. Fachlich klären, welcher Inhalt richtig ist (Tickets MP-131 und Preisänderung, ggf. Rücksprache mit dem Kollegen bzw. Fachbereich). Hier ist vermutlich eine Kombination gewünscht:
   return a.isNotdienst() ? 89.00 : 39.00 + 0.50 * a.getEntfernungKm();
3. Konfliktmarker <<<<<<<, =======, >>>>>>> entfernen.
4. Kompilieren und Tests ausführen.
5. Datei mit git add als gelöst markieren, Merge mit git commit abschließen, danach git push. (Alternative bei Unklarheit: git merge --abort und erst klären.)

d) fetch (1 P)

git fetch (z. B. danach git log main..origin/main): lädt die neuen Commits vom Remote und aktualisiert nur den Remote-Zeiger origin/main; lokaler Branch und Arbeitsverzeichnis bleiben unverändert. git pull führt zusätzlich einen Merge (bzw. Rebase) in den aktuellen Branch aus und verändert ihn.

Erklärung / typische Fehler: Häufig wird bei (6) ein Merge-Commit gezeichnet – ohne eigene lokale Commits ist ein Pull aber immer ein Fast-Forward. Ebenso falsch: M nur mit einer Linie zu F2 verbinden; ein Merge-Commit hat immer zwei Vorgänger. Den Konflikt einfach durch „eine Seite übernehmen“ zu lösen, ohne die Fachlichkeit zu klären, verliert eine der beiden Änderungen.

a) Stellungnahme zu Punkt 1 (4 P)

Ich stimme der Umstellung auf Git zu. Begründung (zwei der folgenden Argumente):

• Paralleles Arbeiten ohne Datenverlust: Jeder arbeitet in seinem eigenen Repository bzw. Branch; Änderungen werden per Merge zusammengeführt, und wenn zwei Personen dieselbe Stelle ändern, meldet Git einen Konflikt, statt still zu überschreiben. Der Vorfall aus Anlage 2 (Lukas überschreibt Sarahs Änderungen am AuftragService) wäre so nicht passiert. Tagesordner auf dem Netzlaufwerk verhindern das nicht, sie erzeugen nur weitere Kopien.
• Nachvollziehbarkeit: Jede Änderung ist mit Autor, Zeitpunkt, Beschreibung und Ticketnummer gespeichert; Fehler lassen sich auf eine konkrete Änderung zurückführen (Vergleich, git blame). Bei Tagesordnern ist nicht erkennbar, wer was warum geändert hat.
• Wiederherstellbarkeit: Jeder frühere Stand ist abrufbar, einzelne fehlerhafte Änderungen können gezielt rückgängig gemacht werden (git revert), statt einen ganzen Ordner zurückzukopieren und dabei andere Änderungen zu verlieren.
• Grundlage für Qualitätssicherung und Automatisierung: Branches, Merge Requests mit Code-Review und die CI/CD-Pipeline (Anlage 5) setzen eine Versionsverwaltung voraus.

b) Punkte 2–4 (6 P)

c) Branching-Strategie (4 P)

Feature-Branch-Workflow mit Merge Requests (GitLab-Flow). Ablauf für ein Ticket, z. B. MP-142:

1. Aktuellen Stand holen: git switch main, git pull.
2. Branch anlegen: git switch -c feature/MP-142-materialliste.
3. In kleinen Schritten committen (aussagekräftige Nachrichten mit Ticketnummer) und den Branch regelmäßig pushen.
4. Merge Request nach main öffnen → Pipeline läuft automatisch (Build, Tests, Analyse).
5. Code-Review durch eine Kollegin/einen Kollegen, Anmerkungen einarbeiten.
6. Bei grüner Pipeline und Freigabe: Merge in den geschützten main, Feature-Branch löschen; das Deployment erfolgt über die Pipeline.

Begründung: Für ein Team von acht Personen, das ein SaaS-Produkt mit nur einer aktuellen Version kontinuierlich ausliefert, ist dieser Workflow einfach und passt zur Pipeline. Git-Flow (develop/release/hotfix-Branches) wäre unnötig aufwendig. Trunk-based Development mit sehr kurzlebigen Branches ist ebenfalls vertretbar, setzt aber sehr gute Testabdeckung voraus.

d) Punkt 6 (2 P)

ZIP-Kopien sind nicht mit der Historie verknüpft: Man weiß nicht, welcher Commit genau ausgeliefert wurde; Namen wie „final2“ sind uneindeutig; das Netzlaufwerk soll ohnehin schreibgeschützt werden. Stattdessen den Release-Commit mit einem Tag markieren, z. B. git tag -a v1.3.0 -m "Release 1.3.0" (Versionsnummer nach SemVer), und den Tag pushen; das Artefakt erzeugt die Pipeline (ggf. als GitLab-Release).

e) Punkt 5 (2 P)

Das Log zeigt Nachrichten wie fix, asdf und Zwischenstand Freitag: Ohne Blick in den Code ist nicht erkennbar, was und warum geändert wurde; Fehlersuche, Reviews und Release Notes werden erschwert. Commit-Nachrichten sollten verpflichtend sein (Ticketnummer + kurze Beschreibung). Vorschlag für a41c9e2:
MP-109: Fehlende Kundenadresse beim Speichern eines Auftrags abfangen
(optional zweiter Absatz: „Statt einer NullPointerException wird jetzt die Meldung ‚Kundenadresse fehlt‘ ausgegeben.“)

Erklärung: „Bewerten“ heißt hier: Problem benennen und eine konkrete Verbesserung vorschlagen. Besonders wichtig ist Punkt 4 – Zugangsdaten im Repository sind ein klassischer Sicherheitsfehler, der in Prüfungen gern mit IT-Sicherheit verknüpft wird.

a) Abgrenzung (3 P)

• Continuous Integration: Die Entwickler führen ihre Änderungen häufig (mindestens täglich) in den gemeinsamen Hauptzweig zusammen; jede Integration wird automatisch gebaut und getestet, sodass Fehler sofort auffallen.
• Continuous Delivery: Zusätzlich wird jede erfolgreich geprüfte Version automatisch zu einem auslieferbaren Artefakt verpackt und in Test-/Staging-Umgebungen bereitgestellt. Die Software ist jederzeit releasefähig; die Übernahme in die Produktion erfolgt nach einer manuellen Freigabe.
• Continuous Deployment: Auch die Produktivsetzung erfolgt automatisch ohne manuelle Freigabe, sobald alle Prüfungen bestanden sind.

b) Aufgaben eines Build-Werkzeugs (2 P)

Zwei davon: Abhängigkeiten (inkl. transitiver) auflösen und herunterladen · Quellcode kompilieren · automatische Tests ausführen · Artefakte packen (JAR/WAR) · Versionen in ein Repository veröffentlichen · Dokumentation/Berichte erzeugen · einheitlicher, reproduzierbarer Build-Ablauf (Lebenszyklus) auf jedem Rechner und dem CI-Server.

a) Ablauf der Pipeline für einen Push auf main (4 P)

Eine einfachere Darstellung als Kette von Kästen (Stages nebeneinander, Jobs einer Stage untereinander) ist ebenso richtig.

b) Delivery oder Deployment? (2 P)

Es handelt sich um Continuous Delivery: Bis zur Staging-Umgebung läuft alles automatisch, der Job deploy-production hat aber when: manual und startet erst, wenn eine berechtigte Person ihn auslöst. Bei Continuous Deployment würde auch die Produktion ohne manuellen Schritt aktualisiert.

c) Push auf einen Feature-Branch (2 P)

Es laufen nur build, unit-tests, integration-tests und code-analyse; package, deploy-staging und deploy-production sind per rules auf main beschränkt. Schlägt unit-tests fehl, läuft integration-tests (gleiche Stage) noch zu Ende, die Stage analyse startet nicht mehr, die Pipeline wird als fehlgeschlagen markiert und die Entwicklerin benachrichtigt. Sie muss den Fehler beheben und erneut pushen; ein Merge in main sollte bei roter Pipeline gesperrt sein.

d) Staging-Umgebung (2 P)

Die Staging-Umgebung ist eine produktionsnahe Kopie (gleiches Container-Image, gleiche Java- und PostgreSQL-Version, ähnliche Konfiguration, anonymisierte Albers-Daten). Dort wird jede neue Version vor der Produktion installiert: Installation und Datenbankmigration werden geprüft, die Testerin und ggf. Disponenten von Albers nehmen die Version ab. Fehler wie ein fehlendes Datenbankskript (Störung vom 19.06.) fallen auf, ohne dass Monteure und Disponenten betroffen sind.

a) Automatisierte Kompilierung und Bereitstellung (3 P)

Der Quellcode liegt ausschließlich in der Versionsverwaltung (Git). Ein CI/CD-Server (z. B. GitLab CI) startet bei jedem Push bzw. Merge auf main automatisch eine Pipeline, die in einer festgelegten Umgebung (Container-Image mit Java 21) mit Maven kompiliert, alle automatischen Tests und die statische Analyse ausführt und daraus ein versioniertes Artefakt (JAR bzw. Container-Image) erzeugt und in einer Registry ablegt. Ein Skript installiert dieses Artefakt automatisch auf der Staging-Umgebung und nach Freigabe auf dem Produktivserver, spielt Datenbankänderungen per Migrationswerkzeug ein, startet den Dienst neu und prüft per Health-Check, ob er läuft. Jeder Lauf wird protokolliert, bei Fehlern wird das Team benachrichtigt.

b) Zwei Störungen und Vorteile (4 P)

c) Schwachstellen im Pipeline-Entwurf (6 P)

d) Container (3 P)

Das Container-Image enthält die Anwendung zusammen mit ihrer Laufzeitumgebung (Java 21) und allen Bibliotheken. Die Pipeline baut das Image einmal; genau dieses Image läuft unverändert in Staging und Produktion. Welche Java-Version auf dem Server installiert ist, spielt keine Rolle mehr – der Server benötigt nur eine Container-Laufzeit. Ein UnsupportedClassVersionError durch Java 21 vs. Java 17 kann dadurch nicht mehr auftreten.

Unterschied zur VM (einer genügt): Container teilen sich den Kernel des Host-Betriebssystems und enthalten kein eigenes Betriebssystem → klein (MB) und in Sekunden gestartet; eine virtuelle Maschine virtualisiert Hardware und enthält ein vollständiges Gast-Betriebssystem → größer (GB), langsamer im Start, dafür stärker isoliert.

e) DevOps (2 P)

DevOps (Development + Operations) heißt, dass Entwicklung und Betrieb nicht als getrennte Abteilungen arbeiten, die Software „über den Zaun werfen“, sondern als ein Team gemeinsam Verantwortung für Entwicklung, Auslieferung und Betrieb tragen. Dazu gehören weitgehende Automatisierung (CI/CD, Infrastruktur als Code), kleine und häufige Releases, kurze Feedbackschleifen sowie Überwachung im Betrieb (Monitoring, Logging), deren Ergebnisse direkt in die Entwicklung zurückfließen – z. B. bindet das Team Herrn Okafor früh in Planung und Pipeline ein, und Entwickler sehen Fehlermeldungen aus der Produktion selbst.

Erklärung: In W22 gab es für die Umsetzung nur 2 P – dort genügten Stichworte wie „CI/CD-Pipeline: bei jedem Commit automatisch bauen, testen und auf den Server verteilen“. Bei den Vorteilen immer auf das konkrete Problem (hier Verfügbarkeit) eingehen.

a) Drei Schichten (3 P)

b) Thin Client und Fat Client (2 P)

Ein Thin Client übernimmt nur Darstellung und Eingabe; Logik und Daten liegen auf dem Server, ohne Verbindung ist er nicht nutzbar. Ein Fat Client enthält selbst einen großen Teil der Logik und häufig eigene Daten und kann daher auch offline arbeiten. Die Web-Disposition ist ein Thin Client (der Server erzeugt die Seiten, der Browser zeigt sie nur an); die Monteur-App ist ein Fat Client (lokale SQLite-Datenbank, Offline-Logik, späterer Datenabgleich).

a) Zuordnung (3 P)

b) Zusammenarbeit (4 P)

1. Der Browser sendet die Anfrage GET /auftraege?status=OFFEN&niederlassung=Kassel an den AuftragController.
2. Der Controller ruft den AuftragService (Model) mit den Filterwerten auf.
3. Der Service lässt die Aufträge über das AuftragRepository per SQL aus der Datenbank lesen, filtert und sortiert sie.
4. Das Model liefert eine Liste von Auftrag-Objekten an den Controller zurück.
5. Der Controller übergibt die Liste an die View auftragsliste.html.
6. Die View erzeugt die HTML-Seite (mit CSS gestaltet), die an den Browser zurückgeht.

c) MVC und 3-Schichten-Architektur (3 P)

Beide schließen sich nicht aus, sie betrachten unterschiedliche Ebenen. Die 3-Schichten-Architektur gliedert das gesamte System in Präsentation, Logik und Datenhaltung (auch über mehrere Rechner). MVC ist ein Muster für den Aufbau der Benutzeroberfläche einer Anwendung. Bei der Auftragsübersicht gehören View (auftragsliste.html, CSS) und AuftragController zur Präsentationsschicht – auch wenn das HTML auf dem Server erzeugt wird. Das Model verteilt sich auf die Logikschicht (AuftragService, Auftrag) und den Zugriff auf die Datenhaltungsschicht (AuftragRepository → PostgreSQL). Dieselbe Logikschicht wird außerdem von der REST-API für die App genutzt – ohne MVC-Views.

a) 3-Schichten-Architektur von MonteurPlus und Zusammenwirken (6 P)

• Präsentationsschicht: Web-Disposition im Browser der Disponenten (vom Server erzeugte HTML-Seiten, Plantafel als TypeScript-Modul) und Monteur-App auf den Android-Geräten. Die App ist ein Fat Client mit lokaler SQLite-Datenbank für den Offline-Betrieb.
• Logikschicht: Anwendungsserver (Spring Boot) mit REST-API und Web-Controllern als Schnittstelle sowie den Diensten Auftragsverwaltung, Einsatzplanung, Synchronisation und Berichtserstellung. Er bindet auch Kartendienst und ERP-System an.
• Datenhaltungsschicht: PostgreSQL-Datenbank, die nur über die Repositories des Servers per SQL angesprochen wird.

Ablauf „Auftrag mit Arbeitsbericht abschließen“: Der Monteur erfasst in der App Material, Fotos und die Unterschrift des Kunden; die App speichert alles zunächst lokal in SQLite – auch im Keller ohne Netz. Sobald eine Verbindung besteht, sendet die App die Daten per HTTPS als JSON an die REST-API. Der Synchronisationsdienst prüft Berechtigung und Vollständigkeit (und ggf. Konflikte), setzt den Auftrag auf „abgeschlossen“, der Berichtsdienst erzeugt den PDF-Arbeitsbericht. Über die Repositories werden Auftrag und Bericht per SQL in PostgreSQL gespeichert. Der Server bestätigt den Empfang (z. B. HTTP 200/201), die App markiert die Daten lokal als übertragen. Ruft eine Disponentin die Auftragsübersicht auf, liest der Server den neuen Status aus der Datenbank und liefert die Seite an den Browser. Nachts exportiert der Server die abgeschlossenen Aufträge als XML per SFTP an das ERP-System.

b) Architekturskizze (5 P)

Web-Controller und Templates werden auf dem Server ausgeführt, gehören fachlich aber zur Präsentation (serverseitiges Rendering). Beide Zuordnungen sind richtig, wenn sie begründet bzw. eindeutig dargestellt sind. Die lokale SQLite-Datenbank der App kann auch in der Datenhaltungsschicht gezeichnet werden, sofern erkennbar ist, dass sie auf dem Gerät liegt.

c) Microservices oder Monolith (5 P)

Empfehlung: Für ein Team von acht Entwicklerinnen und Entwicklern, ein Produkt im Aufbau und einen einzigen Administrator empfiehlt sich zunächst ein modularer Monolith: ein Deployment, intern aber nach Fachbereichen (Aufträge, Einsatzplanung, Synchronisation, Berichte) mit klaren Schnittstellen getrennt. Die bestehende Pipeline kann weiterverwendet werden, Komplexität und Betriebsaufwand bleiben beherrschbar. Wächst die Last durch viele SaaS-Kunden, lassen sich einzelne Module (z. B. Synchronisation) später gezielt als Microservice herauslösen.

d) Kein direkter Datenbankzugriff der App (2 P)

Zwei davon: Sicherheit – der Datenbankserver bleibt aus dem Internet unerreichbar, und es stehen keine Datenbank-Zugangsdaten in der App, die sich aus der APK auslesen ließen. · Geschäftsregeln und Berechtigungen werden zentral auf dem Server geprüft und können nicht von einer manipulierten App umgangen werden. · Entkopplung: Das Datenbankschema kann sich ändern, ohne dass alle App-Versionen auf 140 Geräten angepasst werden müssen; die REST-API bleibt stabil. · Weniger offene Datenbankverbindungen, Schichtenprinzip wird eingehalten.

Erklärung: Teilaufgabe a) entspricht W22 T1 A2a – dort gab es 6 P für Schichten und Zusammenarbeit. Wer nur die drei Schichten aufzählt, erhält etwa die Hälfte; erwartet wird der Weg einer Anfrage durch die Schichten und zurück.

a) Unterschied (2 P)

Ein Compiler übersetzt den gesamten Quellcode vor der Ausführung in Maschinencode und erzeugt eine ausführbare Datei, die anschließend ohne Compiler ausgeführt wird. Ein Interpreter liest den Quellcode zur Laufzeit Anweisung für Anweisung, übersetzt sie und führt sie sofort aus; es entsteht keine ausführbare Datei, und der Interpreter wird bei jeder Ausführung benötigt.

b) Zuordnung (3 P)

c) Vor- und Nachteil des Interpreters (2 P)

Vorteil (einer): plattformunabhängiger Quellcode – läuft überall, wo der Interpreter installiert ist · schneller Entwicklungs- und Testzyklus ohne Übersetzungsschritt, interaktives Ausprobieren.
Nachteil (einer): langsamere Ausführung, da zur Laufzeit übersetzt wird · Fehler (auch Syntax- und Typfehler) zeigen sich erst bei der Ausführung der betreffenden Zeile · Interpreter muss auf dem Zielsystem installiert sein · Quellcode wird mit ausgeliefert.

a) Fehlerarten (4 P)

b) Python (2 P)

Python ist dynamisch typisiert und wird interpretiert. Zeile 12 ist gültig – plz verweist einfach auf eine Ganzzahl. Der Fehler wird erst zur Laufzeit bemerkt, wenn Zeile 87 tatsächlich ausgeführt wird: AttributeError: 'int' object has no attribute 'zfill' – möglicherweise erst nach langer Laufzeit des Imports oder nur bei bestimmten Datensätzen. In Java (Ausschnitt 1) prüft der Compiler die Typen vor der Ausführung, der Fehler fällt also schon beim Übersetzen auf. (Zusatz: Eine Postleitzahl gehört ohnehin als Text gespeichert, sonst geht die führende 0, z. B. bei 01067, verloren.)

c) Fehlersuche mit dem Debugger (4 P)

1. Fehler reproduzierbar machen: Testfall mit bekannten Werten (250 Minuten, 4 Einsätze → erwartet 62,5).
2. Haltepunkt in der Methode setzen, die den Durchschnitt berechnet (bei unbekannter Stelle zunächst am Anfang der Berechnung), und das Programm im Debug-Modus starten.
3. Beim Anhalten die Variablen beobachten (Variablenansicht/Watch): summeMinuten = 250, anzahl = 4 – die Eingangswerte stimmen.
4. Mit Step Over die Zeile ausführen: schnitt = 62.0 → hier entsteht der Fehler. Mit „Ausdruck auswerten“ zeigt summeMinuten / anzahl den Wert 62 (int) → Ursache Ganzzahldivision. Liegt die Berechnung in einer aufgerufenen Methode, mit Step Into hineinspringen; über den Aufrufstapel sieht man, von wo sie aufgerufen wurde.
5. Code korrigieren, Unit-Test ergänzen und erneut ausführen.

Zum Ausprobieren: java\11_Werkzeuge\Aufgabe_WZ_04_2.java enthält die Ausschnitte (3) und (4) mit Korrektur; Ausgabe des Programms:

(3) Laufzeitfehler:
    IndexOutOfBoundsException: Index 3 out of bounds for length 3
    korrigiert: A-1003
(4) Logischer Fehler (keine Fehlermeldung!):
    fehlerhaft:  Durchschnitt = 62.0 min
    korrigiert:  Durchschnitt = 62.5 min
OK     Korrektur (4): erwartet 62.5, erhalten 62.5
OK     Fehler (4) reproduziert: erwartet 62.0, erhalten 62.0
OK     Korrektur (3): erwartet A-1003, erhalten A-1003

a) Java vom Entwicklerrechner bis zum Linux-Server (4 P)

1. Auf dem Windows-Rechner bzw. in der Pipeline übersetzt der Compiler javac (über Maven) die .java-Dateien in Bytecode (.class-Dateien) – plattformunabhängigen Zwischencode für eine gedachte Maschine, nicht für einen konkreten Prozessor. Die Klassen werden zu einer JAR-Datei bzw. einem Container-Image gepackt.
2. Dieselbe JAR-Datei wird ohne erneute Übersetzung auf den Linux-Server gebracht.
3. Dort lädt die Java Virtual Machine (Eclipse Temurin 21 für Linux) den Bytecode, prüft ihn und führt ihn zunächst interpretierend aus.
4. Der JIT-Compiler erkennt häufig ausgeführte Methoden („Hotspots“) und übersetzt sie zur Laufzeit in optimierten Maschinencode für den Prozessor des Servers – dadurch läuft der Server fast so schnell wie ein direkt kompiliertes Programm.

Die Plattformunabhängigkeit („Write once, run anywhere“) entsteht, weil es für jedes Betriebssystem eine eigene JVM gibt, die denselben Bytecode ausführt.

b) Python oder C++ für die Datenübernahme (4 P)

Python (interpretiert): sehr kurzer, gut lesbarer Code; CSV-Verarbeitung mit der Standardbibliothek; schneller Test-Zyklus ohne Übersetzen – Formatprobleme in den Altdaten lassen sich schnell anpassen und der Import erneut starten. Nachteil: langsamere Ausführung, Typfehler erst zur Laufzeit.
C++ (kompiliert): deutlich schnellere Ausführung, aber höherer Entwicklungsaufwand (Speicherverwaltung, CSV-Parsing, Datenbankanbindung), längerer Entwicklungszyklus, im Team (Java/Kotlin/TypeScript) kaum Erfahrung.
Einsatzzweck: Der Import läuft einmal, mit nur ca. 60 000 Datensätzen (bei Python im Bereich von Sekunden bis Minuten) und unkritischer Laufzeit über Nacht. Der Geschwindigkeitsvorteil von C++ bringt hier nichts, die Entwicklungszeit zählt.
Empfehlung: Python (alternativ Java als Teamsprache) – geringer Aufwand, schnelle Anpassung an fehlerhafte Altdaten.

c) TypeScript und tsc (3 P)

tsc ist ein Transpiler (Source-to-Source-Compiler): Er übersetzt den TypeScript-Code vor der Auslieferung in JavaScript, denn Browser können nur JavaScript ausführen. Dabei prüft er die statischen Typangaben (z. B. auftragNr: number, Struktur der Daten aus der REST-API) und meldet Typfehler, Tippfehler in Eigenschaftsnamen oder fehlende Parameter bereits beim Übersetzen; im erzeugten JavaScript sind die Typen entfernt. Ausgeführt wird das JavaScript dann im Browser (Interpreter + JIT der JavaScript-Engine).
Vorteil: Viele Fehler fallen vor der Ausführung auf statt erst bei den Disponenten; zudem bessere IDE-Unterstützung (Autovervollständigung, sicheres Umbenennen) und eine selbstdokumentierende Schnittstelle zur REST-API.

d) Go-Programm mp-export (5 P)

da) (3 P) Der Go-Compiler (go build) prüft Syntax und Typen und übersetzt die Quelldateien des Programms und der verwendeten Pakete in Maschinencode (Objektcode) für die Zielplattform (hier Windows, x86-64). Der Linker fügt diesen Objektcode mit dem Code der benötigten Bibliotheken (Go-Standardbibliothek, Fremdpakete) und der Go-Laufzeitumgebung zusammen, löst die Verweise auf Funktionen in anderen Paketen auf und erzeugt die ausführbare Datei mp-export.exe. Go bindet die Bibliotheken in der Regel statisch ein – deshalb ist das Ergebnis eine einzelne Datei, die ohne weitere Installation läuft (Anforderung aus Anlage 8).

db) (2 P) Die ausführbare Datei enthält Maschinencode und ein Dateiformat, die an Betriebssystem und Prozessor gebunden sind: Windows nutzt das PE-Format (.exe) und Windows-Systemaufrufe, Linux das ELF-Format und Linux-Systemaufrufe (ggf. auch eine andere Prozessorarchitektur). Deshalb muss für jede Zielplattform eigens übersetzt und gelinkt werden – bei Go per Cross-Compiling, z. B. GOOS=linux GOARCH=amd64 go build. Anders als bei Java gibt es keine virtuelle Maschine, die plattformneutralen Code ausführt.

a) Bibliothek vs. Framework (2 P)

Eine Klassenbibliothek ist eine Sammlung wiederverwendbarer Klassen und Methoden, die der eigene Code bei Bedarf aufruft; die Ablaufsteuerung bleibt beim eigenen Programm (z. B. TerminKern: MonteurPlus ruft istFeiertag() auf). Ein Framework gibt Struktur und Ablauf der Anwendung vor; der eigene Code wird an vorgesehenen Stellen eingefügt und vom Framework aufgerufen – Inversion of Control (z. B. Spring Boot nimmt HTTP-Anfragen an und ruft die passende Controller-Methode auf).

b) Vor- und Nachteil einer umfangreichen PDF-Bibliothek (4 P)

Vorteil (einer, beschrieben): PDF-Erzeugung ist komplex (Schriften, Seitenumbrüche, Tabellen, Fotos, Unterschrift, ggf. PDF/A für die Archivierung). Eine erprobte Bibliothek spart Entwicklungszeit und Kosten, ist von vielen Nutzern getestet und enthält dadurch weniger Fehler als eine Eigenentwicklung; das Team kann sich auf die Fachlogik der Arbeitsberichte konzentrieren. Fehlerbehebungen und Sicherheitsupdates kommen vom Hersteller.

Nachteil (einer, beschrieben): Abhängigkeit vom Hersteller bzw. Projekt – wird die Bibliothek nicht mehr gepflegt oder ändert sich die Lizenz, muss man sie mit großem Aufwand ersetzen. Weitere: Lizenzbedingungen und -kosten (PdfMaker Core: AGPL oder 2 400 € pro Jahr, Anlage 11), Einarbeitungsaufwand in eine umfangreiche API, größere Anwendung, obwohl nur ein Bruchteil genutzt wird, Sicherheitslücken im fremden Code.

a) Aufgaben von Maven bei Abhängigkeiten (3 P)

In der pom.xml werden nur die direkten Abhängigkeiten mit ihren Koordinaten (groupId, artifactId, version) deklariert. Maven lädt die passenden JAR-Dateien aus einem zentralen Repository (Maven Central bzw. Firmen-Repository) in den lokalen Zwischenspeicher und bindet sie beim Kompilieren, Testen und Packen ein. Dabei löst Maven die transitiven Abhängigkeiten automatisch auf: TerminKern benötigt seinerseits feiertage-de und json-mini; beide stehen nicht in der pom.xml, werden aber trotzdem geladen (im Abhängigkeitsbaum eingerückt unter TerminKern). Außerdem verwaltet Maven Versionen (Spring Boot gibt die Versionen für spring-boot-starter-web und junit-jupiter vor, daher fehlt dort die Versionsangabe), löst Versionskonflikte auf und trennt Gültigkeitsbereiche: junit-jupiter hat den Scope test und gelangt nicht in das ausgelieferte Programm.

b) Release Notes und SemVer (4 P)

Empfehlung: kurzfristig auf 2.4.2 aktualisieren – die Sicherheitslücke wird geschlossen, das Risiko ist minimal. Ebenfalls gut vertretbar: 2.5.0 (abwärtskompatibel, enthält als spätere Version in der Regel auch die Korrekturen aus 2.4.2; die Deprecation-Warnungen helfen, die 14 Stellen schon auf feiertage(Year, Bundesland) umzustellen). Den Umstieg auf 3.0.0 als eigenes Ticket mit Tests planen.

c) Risiko json-mini und Maßnahmen (3 P)

Risiko: json-mini 0.9.2 ist eine transitive Abhängigkeit, die in der pom.xml gar nicht auftaucht, und enthält eine bekannte Schwachstelle: Tief verschachtelte JSON-Eingaben können eine Endlosschleife auslösen. Verarbeitet der Server über TerminKern solche Daten, kann ein Angreifer (oder eine fehlerhafte Eingabe) den Server blockieren – MonteurPlus wäre für Disponenten und Monteure nicht verfügbar (Schutzziel Verfügbarkeit). Zudem signalisiert die Version 0.x eine noch instabile Bibliothek.

Maßnahmen (zwei): automatischer Schwachstellen-Scan aller (auch transitiven) Abhängigkeiten in der Pipeline, z. B. OWASP Dependency-Check, GitLab Dependency Scanning, Dependabot/Renovate, mit Abbruch bei kritischen Lücken · SBOM erstellen und laufend mit Schwachstellendatenbanken abgleichen · Sicherheitshinweise und Release Notes der Bibliotheken verfolgen, regelmäßige Update-Termine · betroffene transitive Version gezielt anheben (Maven dependencyManagement), bis die direkte Abhängigkeit aktualisiert ist · vor dem Einsatz neuer Bibliotheken Pflegezustand und Abhängigkeiten prüfen, Anzahl der Abhängigkeiten gering halten.

Erklärung: Entscheidend für den englischen Text sind die Signalwörter: Fixed und Security (Patch), New und Deprecated (Minor), BREAKING (Major). Genau das bildet SemVer in der Versionsnummer ab.

a) Drei Aspekte der Dokumentation (6 P)

• Vollständige Beschreibung der öffentlichen Schnittstelle: Zweck von Klasse, Konstruktor und Methode; jeder Parameter mit Bedeutung und erlaubten Werten (dauer muss positiv sein, ab wird mitgeprüft, m und ab dürfen nicht null sein, Wirkung von notdienst: Feiertage und arbeitsfreie Tage werden mitgeprüft); Rückgabewert (frühester Termin als Optional, leer, wenn nichts frei ist); Ausnahmen (IllegalArgumentException); Einschränkungen wie die Suche über höchstens 30 Tage. Der vorhandene Kommentar „sucht termin“ reicht dafür nicht aus.
• Bezug zur Basisbibliothek und Kompatibilität: Die Klasse erweitert Kalender aus TerminKern 2.4.1 und nutzt deren Methode istFeiertag(). Zu dokumentieren ist, mit welcher TerminKern-Version die Erweiterung getestet ist, welches Verhalten von der Basisklasse übernommen bzw. ergänzt wird und dass ab TerminKern 3.0.0 eine Anpassung nötig ist (neues Paket). Ebenso die Abhängigkeiten zu Arbeitszeitmodell, Monteur und Einsatzplan.
• Versionierung und Änderungshistorie: eigene Versionsnummer der Erweiterung (z. B. nach SemVer), @since-Angaben, Changelog. Da zwei weitere Teams die Klasse nutzen, müssen Verhaltensänderungen (z. B. eine andere Suchdauer als 30 Tage) und veraltete Methoden (@deprecated mit Alternative) nachvollziehbar sein.
• Verständlichkeit für die Zielgruppe und einheitliche Form: Die Leser sind Entwickler anderer Teams – also Javadoc direkt im Code (daraus HTML erzeugen), einheitliche Sprache und Begriffe, Codebeispiel zur typischen Verwendung, Dokumentation bei jeder Änderung aktualisieren (Teil des Code-Reviews).

b) Javadoc-Kommentar (5 P)

/**
 * Sucht den frühesten freien Einsatztermin eines Monteurs ab einem Starttag.
 *
 * <p>Geprüft werden höchstens 30 aufeinanderfolgende Tage, beginnend mit
 * {@code ab}. Für normale Aufträge werden nur Arbeitstage laut
 * Arbeitszeitmodell berücksichtigt, die im Bundesland des Kalenders keine
 * Feiertage sind. Bei Notdienst-Aufträgen ({@code notdienst = true}) wird jeder
 * Tag geprüft, also auch Wochenenden und Feiertage. Innerhalb eines Tages
 * liefert der Einsatzplan des Monteurs den frühesten freien Zeitraum der
 * benötigten Dauer.</p>
 *
 * @param m         Monteur, für den ein Termin gesucht wird; nicht {@code null}
 * @param ab        erster Tag der Suche (wird mitgeprüft); nicht {@code null}
 * @param dauer     benötigte Einsatzdauer; muss positiv sein (größer als 0)
 * @param notdienst {@code true}, wenn auch Wochenenden, arbeitsfreie Tage und
 *                  Feiertage berücksichtigt werden sollen (Notdienst-Auftrag)
 * @return Beginn (Datum und Uhrzeit) des frühesten freien Termins oder ein leeres
 *         {@link Optional}, wenn innerhalb von 30 Tagen kein passender Termin frei ist
 * @throws IllegalArgumentException wenn {@code dauer} 0 Minuten lang oder negativ ist
 * @throws NullPointerException     wenn {@code m}, {@code ab} oder {@code dauer}
 *                                  {@code null} ist
 * @since 1.0
 * @see Kalender#istFeiertag(LocalDate)
 */
public Optional<LocalDateTime> naechsterFreierTermin(
        Monteur m, LocalDate ab, Duration dauer, boolean notdienst) { … }

Geprüft: Die vollständige Klasse mit diesem Kommentar steht in java\11_Werkzeuge\Aufgabe_WZ_05_3.java; sie kompiliert und erzeugt mit javadoc -Xdoclint:all für EinsatzKalender keine Warnungen. Programmausgabe des Beispiels (Fr 02.10.2026 belegt, 03.10. Feiertag und Samstag):

Normaler Auftrag ab Fr 02.10.2026: Optional[2026-10-05T07:30]
Notdienst ab Fr 02.10.2026:        Optional[2026-10-03T07:30]
Ist 03.10.2026 Feiertag? true
Dauer 0 -> IllegalArgumentException: dauer muss positiv sein: PT0S

c) Unterklasse statt Änderung der Bibliothek (3 P)

Drei Argumente: Updates bleiben möglich – Änderungen im Quellcode der Bibliothek gingen beim nächsten Update von TerminKern verloren bzw. müssten bei jedem Update (auch bei Sicherheitsupdates wie 2.4.2) erneut eingepflegt werden; man bliebe auf einer alten Version „hängen“. · Trennung von allgemeiner und fachlicher Logik – TerminKern ist eine allgemeine Kalenderbibliothek und kennt keine Monteure, Einsatzpläne oder Arbeitszeitmodelle; diese MonteurPlus-spezifische Logik gehört in eigenen Code. · Vorgesehener Erweiterungsweg – Vererbung nutzt die öffentliche API (istFeiertag) ohne Eingriff in fremden Code (Open-Closed-Prinzip); die Erweiterung lässt sich eigenständig versionieren, testen und von anderen Teams einbinden. · Lizenz/Verantwortung – geänderter Bibliothekscode wäre ein eigener „Fork“, für den man selbst verantwortlich ist (Apache 2.0 verlangt z. B., Änderungen zu kennzeichnen).

d) Weitere Bestandteile (2 P)

Zwei davon: Einstieg/Installationsanleitung (Maven-Koordinaten, Voraussetzungen wie TerminKern-Version und Java 21) · Codebeispiele bzw. Tutorial für typische Anwendungsfälle · Changelog/Versionshinweise · Migrationshinweise bei inkompatiblen Änderungen · Überblick über Aufbau und Klassen (Architektur) · bekannte Einschränkungen · Lizenzhinweise · Ansprechpartner/Wartung.

Erklärung: Die Originalaufgabe W21 T1 A1bb fragte allgemein nach drei Aspekten (6 P). Wer konkret auf den Code eingeht (Parameter, Rückgabe, Ausnahmen, Kompatibilität zur Basisbibliothek), sammelt die Punkte sicherer als mit allgemeinen Floskeln wie „verständlich schreiben“.

a) Open Source (3 P)

Open-Source-Software ist Software, deren Quellcode öffentlich zugänglich ist und deren Lizenz jedem erlaubt, die Software für beliebige Zwecke (auch kommerziell) zu nutzen, zu untersuchen, zu verändern und – verändert oder unverändert – weiterzugeben. Welche Bedingungen dabei gelten (z. B. Lizenzhinweise beilegen, Änderungen offenlegen), legt die jeweilige Lizenz fest; anerkannte Open-Source-Lizenzen erfüllen die Open Source Definition der OSI (z. B. MIT, Apache 2.0, GPL). Das Urheberrecht bleibt beim Autor; meist ist die Nutzung kostenlos.

b) Einsatz ohne Einschränkung? (2 P)

Nein. Open Source bedeutet nicht „rechtefrei“: Man darf eine Bibliothek nur unter den Bedingungen ihrer Lizenz einsetzen. Copyleft-Lizenzen wie die GPL verlangen z. B., dass ein Programm, das die Bibliothek enthält, bei Weitergabe ebenfalls unter der GPL mit vollständigem Quellcode weitergegeben wird – das widerspricht dem proprietären Modell von MonteurPlus. Auch permissive Lizenzen verlangen zumindest Lizenz- und Copyright-Hinweise.

c) Beispiele (1 P)

Permissiv: MIT, BSD, Apache 2.0. Copyleft: GPL, AGPL, LGPL (schwach), MPL 2.0 (schwach), EPL 2.0 (schwach).

a) Software-Arten (4 P)

b) Bibliotheken Nr. 1, 3 und 4 (6 P)

a) Bibliotheken Nr. 5 bis 8 (8 P)

b) Vor- und Nachteile von Open-Source-Bibliotheken (4 P)

Vorteile (zwei): keine Lizenzkosten – wichtig, weil bei wachsender Kundenzahl keine Gebühren je Nutzer anfallen · Quellcode einsehbar: Qualität und Sicherheit prüfbar, Fehler selbst analysieren und notfalls beheben · große Community, weite Verbreitung, viel Wissen und schnelle Fehlerbehebung bei aktiven Projekten · keine Abhängigkeit von einem Hersteller, bei Einstellung kann das Projekt weitergeführt (geforkt) werden.

Nachteile (zwei): Lizenzpflichten müssen geprüft und eingehalten werden; Copyleft (Nr. 4, 5) kann das Geschäftsmodell gefährden → Aufwand für Lizenz-Compliance · keine Gewährleistung und kein garantierter Support (Haftungsausschluss) – gegenüber Albers haftet Lindner Digital trotzdem selbst · Fortbestand unsicher (Projekt wird eingestellt oder Lizenz geändert) · Sicherheitslücken sind öffentlich sichtbar, Updates muss man selbst verfolgen (vgl. json-mini).

Fazit für die Geschäftsführung: Open Source ja, aber mit festem Prüfprozess (Lizenz, Pflegezustand, Sicherheit) vor jedem Einsatz.

c) GPL-Code in eine MIT-Bibliothek kopieren (3 P)

Nicht zulässig. Der kopierte SignPad-Code bleibt urheberrechtlich geschützt und steht unter der GPL-3.0. Wird er in lindner-utils übernommen, entsteht ein abgeleitetes Werk, das bei der Veröffentlichung insgesamt unter der GPL-3.0 stehen muss. Eine Veröffentlichung unter MIT würde die GPL verletzen, weil MIT u. a. erlaubt, den Code in proprietäre Software einzubauen – GPL-Code lässt sich nicht in eine permissive Lizenz „umlizenzieren“ (umgekehrt wäre MIT-Code in einem GPL-Projekt zulässig). Außerdem würde lindner-utils selbst copyleft-pflichtig und wäre in MonteurPlus nicht mehr einsetzbar. Lösung: die Funktionen ohne Kopie selbst neu entwickeln, eine Bibliothek mit permissiver Lizenz nutzen oder den Rechteinhaber von SignPad um eine Lizenz unter MIT bitten (nur er kann umlizenzieren).

d) SBOM (3 P)

Eine Software Bill of Materials ist eine maschinenlesbare, vollständige „Stückliste“ aller Komponenten eines Softwareprodukts – einschließlich der transitiven Abhängigkeiten – mit Name, Version, Herkunft, Lizenz und Prüfsumme (Formate SPDX oder CycloneDX). Sie wird in der Pipeline automatisch für jede Version erzeugt (z. B. per Maven-Plugin).

Nutzen am Beispiel: FeiertageDE und json-mini stehen nicht in der pom.xml, sondern kommen über TerminKern ins Produkt. Die SBOM führt sie trotzdem auf. Als die Denial-of-Service-Lücke in json-mini 0.9.2 bekannt wurde, hätte ein Abgleich der SBOM mit Schwachstellendatenbanken sofort gezeigt, dass Server-Version 1.3.0 betroffen ist (Schwachstellenmanagement). Außerdem lassen sich ihre Lizenzen (BSD-3-Clause, MIT) für Lizenzprüfung und Lizenzhinweise gegenüber den SaaS-Kunden erfassen. Der EU Cyber Resilience Act verlangt von Herstellern künftig eine SBOM.

Erklärung: Der Kern aller Lizenzfragen ist immer derselbe: Welche Lizenz, und wird die Software weitergegeben (App, Download, Browser-JavaScript) oder nur intern bzw. als Netzdienst genutzt? Bei der AGPL reicht schon der Netzdienst. In W22 genügte für „Darf jede OSS-Bibliothek eingesetzt werden?“ (2 P) die Antwort „Nein, Lizenzbedingungen beachten, z. B. GPL – Offenlegung des Quellcodes“.