Block 11 · Entwicklungsumgebung & Werkzeuge

A · Erklärungssatz

Die Themen dieses Blocks kamen bisher nur in den ersten beiden Prüfungen nach neuer Ausbildungsordnung vor (W21 und W22), dort aber jeweils mit rund 20 Punkten in Teil 1. Jedes Unterthema wurde genau einmal gefragt – meist mit kurzen Wissensfragen („Nennen Sie …“, „Beschreiben Sie den Unterschied …“) oder einer Bewertung („Entscheiden Sie, ob Sie dem Vorschlag zustimmen“). Es ist Grundlagenwissen aus dem Ausbildungsalltag und kann jederzeit wiederkommen, z. B. als Einstieg in Aufgabe 1 oder 2 von Teil 1.

WZ-01 · Versionsverwaltung (Git) Sonstige

Vorkommen: 1/9 · Prüfung: W21 T1 A1c (4 P: Ein Entwicklungsteam aus zehn Personen schlägt vor, mit einer Versionsverwaltung zu arbeiten – zustimmen oder ablehnen und fachlich begründen)

Eine Versionsverwaltung (Version Control System, VCS) speichert jede Änderung an Dateien – meist Quellcode – als neue Version in einem Repository. Zu jeder Version werden Autor, Zeitpunkt und eine Beschreibung festgehalten. Dadurch kann ein Team gleichzeitig an denselben Dateien arbeiten, Änderungen zusammenführen und jederzeit auf einen früheren Stand zurückgehen.

Wozu eine Versionsverwaltung? (Argumente für die Prüfung)

• Paralleles Arbeiten im Team: Jeder arbeitet auf seiner eigenen Kopie bzw. seinem eigenen Branch; Änderungen werden kontrolliert zusammengeführt, statt sich gegenseitig zu überschreiben (Netzlaufwerk-Problem).
• Nachvollziehbarkeit: Wer hat wann was und warum geändert? Fehler lassen sich auf eine Änderung zurückführen (git log, git blame).
• Wiederherstellbarkeit: Jeder frühere Stand ist abrufbar; fehlerhafte Änderungen können gezielt rückgängig gemacht werden (git revert).
• Releases und Varianten: Ausgelieferte Versionen werden markiert (Tags); ein Fehler in Version 1.2 lässt sich beheben, während an 1.3 weitergearbeitet wird (Branches).
• Qualitätssicherung und Automatisierung: Grundlage für Code-Reviews (Pull Requests) und für CI/CD-Pipelines, die bei jedem Push bauen und testen (→ WZ-02).
• Datensicherheit: Bei verteilten Systemen liegt die komplette Historie auf jedem Entwicklerrechner und auf dem Server (ersetzt aber kein geplantes Backup).

Gegen eine Versionsverwaltung spricht praktisch nur der Einarbeitungs- und Einrichtungsaufwand. In der Prüfung lautet die erwartete Antwort daher fast immer: zustimmen – und mit zwei konkreten Vorteilen für dieses Team begründen.

Zentrale und verteilte Versionsverwaltung

Die wichtigsten Begriffe

Beispiel: Projekt „Kassenbuch“. main steht auf Commit C2. Dann werden diese Befehle ausgeführt:

git switch -c feature/csv-export
git commit -m "…"                      # E1
git commit -m "…"                      # E2
git switch main
git commit -m "…"                      # C3 (dringender Fix direkt auf main)
git merge feature/csv-export           # M
git tag -a v2.0.0 -m "Version 2.0.0"

Weil main mit C3 einen eigenen neuen Commit hat, ist kein Fast-Forward möglich: Es entsteht der Merge-Commit M mit den Vorgängern C3 und E2. (Hätte es C3 nicht gegeben, wäre main beim Merge einfach auf E2 vorgerückt.)

Zeichenregeln für Commit-Graphen: Commits als Kreise in zeitlicher Reihenfolge, Linien zum Vorgänger, Branch-Namen und Tags als beschriftete Zeiger auf „ihren“ Commit, HEAD beim aktuell ausgecheckten Branch. (In Git zeigt jeder Commit auf seinen Vorgänger; Pfeile sind daher korrekt in Richtung Vergangenheit. Ohne Pfeile mit Zeitachse ist es ebenso eindeutig.)

Merge-Konflikte erkennen und lösen

Git führt Änderungen automatisch zusammen, solange sie unterschiedliche Stellen betreffen. Ändern beide Seiten dieselben Zeilen (oder löscht eine Seite eine Datei, die die andere ändert), stoppt der Merge und markiert die Stelle in der Datei:

timeout.sekunden=
<<<<<<< HEAD
30
=======
120
>>>>>>> feature/langsame-drucker

Oberhalb von ======= steht der Stand des aktuellen Branches (HEAD), darunter der des einzumergenden Branches. So gehst du vor: (1) Konfliktdateien mit git status ermitteln, (2) fachlich entscheiden, welcher Inhalt richtig ist – eine Seite, die andere oder eine Kombination, bei Unklarheit mit dem Autor der anderen Änderung sprechen, (3) Konfliktmarker entfernen, (4) kompilieren und testen, (5) mit git add als gelöst markieren und mit git commit den Merge abschließen. Alternativ bricht git merge --abort den Merge ab.

Branching-Strategien

Ergänzend: Branch-Schutz auf main (kein direkter Push, Merge nur per Pull Request mit mindestens einem Review und grüner Pipeline).

Pull Request und Code-Review

Vorteile: Vier-Augen-Prinzip (Fehler, Sicherheitslücken und unklarer Code werden vor dem Merge gefunden), Wissensverteilung im Team (mehr als eine Person kennt jeden Codeteil), einheitlicher Stil und Einhaltung von Konventionen, dokumentierte Diskussion zu jeder Änderung, automatische Prüfungen (Build, Tests, statische Analyse) laufen vor dem Merge. Nachteile: Zeitaufwand, Wartezeiten, wenn Reviews liegen bleiben – deshalb kleine Pull Requests.

.gitignore – was gehört nicht ins Repository?

# erzeugte Dateien
__pycache__/
*.pyc
dist/
# virtuelle Umgebung
.venv/
# Editor / Betriebssystem
.vscode/
Thumbs.db
# Geheimnisse
.env
*.log

Gute Commit-Nachrichten

• Erste Zeile: kurze Zusammenfassung (ca. 50 Zeichen), was die Änderung bewirkt, gern mit Ticketnummer; im Imperativ oder sachlich („Rundung der Mehrwertsteuer korrigiert“).
• Danach optional eine Leerzeile und ein Text, warum die Änderung nötig war.
• Ein Commit = eine zusammengehörige (atomare) Änderung, die das Projekt in einem lauffähigen Zustand hinterlässt.
• Konvention „Conventional Commits“: Präfix wie feat:, fix:, docs:, refactor:, test:.

WZ-02 · CI/CD & Deployment Sonstige

Vorkommen: 1/9 · Prüfung: W22 T1 A1c (6 P: Durch manuelles Kompilieren und Bereitstellen gab es Probleme mit der Verfügbarkeit – ca) beschreiben, wie automatisierte Kompilierung und Bereitstellung umgesetzt werden können (2 P), cb) zwei Vorteile gegenüber der manuellen Bereitstellung nennen (4 P))

Deployment (Bereitstellung) bezeichnet alle Schritte, mit denen eine neue Softwareversion auf eine Zielumgebung gebracht und dort in Betrieb genommen wird. Manuell heißt das oft: Ein Administrator baut die Software auf seinem Rechner, kopiert Dateien auf den Server, passt Konfigurationen von Hand an und startet Dienste neu. Jeder dieser Schritte kann vergessen oder falsch ausgeführt werden – typische Folgen sind Ausfälle, „bei mir lief es aber“ und Abhängigkeit von einer einzelnen Person.

CI, Continuous Delivery, Continuous Deployment

Stufen einer Pipeline

Schlägt eine Stufe fehl, stoppt die Pipeline: Nachfolgende Stufen laufen nicht, das Team wird benachrichtigt. Die Pipeline wird als Datei im Repository beschrieben („Pipeline as Code“) und damit selbst versioniert. Beispiel für ein Node.js-Projekt mit GitHub Actions:

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]          # Auslöser
jobs:
  pruefen:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4   # Code aus dem Repository holen
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci                 # Abhängigkeiten exakt nach Lock-Datei
      - run: npm run lint           # statische Analyse
      - run: npm test               # Unit-Tests

Build-Werkzeuge

Ein Build-Tool automatisiert alles, was nötig ist, um aus Quellcode ein lauffähiges Produkt zu machen: Abhängigkeiten auflösen und herunterladen (inkl. transitiver Abhängigkeiten), kompilieren, Tests ausführen, Artefakte packen (JAR/WAR, APK), Dokumentation erzeugen, Versionen veröffentlichen. Weil der Ablauf in einer Datei beschrieben ist, baut jeder Rechner und der CI-Server das Projekt gleich (reproduzierbarer Build).

Umgebungen (Stages)

Entwicklung (lokal) → Test/Integration (automatische Tests) → Staging → Produktion. Die Staging-Umgebung ist eine möglichst exakte Kopie der Produktion (gleiche Betriebssystem- und Laufzeitversionen, gleiche Konfiguration, realistische, aber anonymisierte Daten). Dort werden Installation, Datenbankmigration und Abnahme (z. B. durch Fachbereich oder Kunden) geprüft, ohne echte Nutzer zu gefährden. Grundsatz „Build once, deploy many“: Dasselbe, einmal gebaute Artefakt wandert durch alle Umgebungen; nur die Konfiguration (Umgebungsvariablen, Secrets) unterscheidet sich.

Vorteile automatisierter Bereitstellung

Nachteile/Aufwand: Einrichtung und Pflege der Pipeline und der Infrastruktur, Know-how, aussagekräftige automatische Tests sind Voraussetzung (eine Pipeline ohne gute Tests liefert Fehler nur schneller aus).

Weitere Begriffe: Rollback = Zurück auf die letzte funktionierende Version. Blue-Green-Deployment = neue Version parallel aufbauen und dann umschalten. Canary Release = neue Version zuerst nur für einen kleinen Teil der Nutzer. Secrets (Passwörter, Schlüssel) gehören nie in die Pipeline-Datei oder das Repository, sondern in geschützte Variablen des CI-Systems bzw. einen Secret-Speicher.

Container (Docker) im Deployment

Ein Container-Image enthält die Anwendung samt Laufzeitumgebung (z. B. Java 21), Bibliotheken und Konfigurationsvorgaben. Aus dem Image werden Container gestartet – auf dem Entwicklerrechner, im Test und in der Produktion identisch. Damit verschwinden Fehler durch abweichende Umgebungen. Images werden in einer Registry abgelegt; viele Container werden mit Kubernetes orchestriert (verteilen, skalieren, neu starten). Beschrieben wird ein Image in einem Dockerfile:

# Dockerfile für das Projekt „Kassenbuch“
# Basis-Image mit Java-21-Laufzeit
FROM eclipse-temurin:21-jre
WORKDIR /app
# gebaute Anwendung in das Image kopieren
COPY target/kassenbuch.jar app.jar
EXPOSE 8080
# Startbefehl des Containers
ENTRYPOINT ["java", "-jar", "app.jar"]

Kommentare stehen im Dockerfile immer in einer eigenen Zeile.

DevOps

DevOps (Development + Operations) ist eine Kultur bzw. Arbeitsweise, in der Entwicklung und Betrieb nicht getrennt „über den Zaun werfen“, sondern gemeinsam Verantwortung für die laufende Software übernehmen. Kernelemente: Automatisierung (CI/CD, Infrastructure as Code), kurze Feedbackschleifen, Messen und Überwachen im Betrieb (Monitoring, Logging), kleine und häufige Releases, „You build it, you run it“. CI/CD ist das wichtigste Werkzeug von DevOps.

WZ-03 · Softwarearchitektur Sonstige

Vorkommen: 1/9 · Prüfung: W22 T1 A2a (6 P: beschreiben, wie die 3-Schichten-Architektur bei einer Webanwendung typischerweise aussieht und wie die Komponenten zusammenarbeiten)

Die Softwarearchitektur beschreibt die grundlegende Struktur eines Systems: aus welchen Komponenten es besteht, welche Aufgabe jede hat und wie sie miteinander kommunizieren. Gute Architektur trennt Verantwortlichkeiten („Separation of Concerns“), damit Teile unabhängig geändert, getestet und ausgetauscht werden können.

Client-Server, Thin Client und Fat Client

Beim Client-Server-Modell bietet ein Server Dienste an (Daten, Berechnungen), Clients fordern sie an (Anfrage → Antwort, z. B. per HTTP). Wie viel Logik auf dem Client liegt, unterscheidet Thin und Fat Client:

Schichtenarchitektur und 3-Schichten-Architektur

In einer Schichtenarchitektur wird die Software in übereinanderliegende Schichten mit klaren Aufgaben zerlegt. Jede Schicht nutzt nur die Dienste der Schicht direkt darunter über definierte Schnittstellen und kennt die Schichten darüber nicht. Die klassische Aufteilung ist die 3-Schichten-Architektur:

Zusammenspiel (Beispiel „Platz buchen“): Der Nutzer wählt im Browser einen Platz; die Präsentationsschicht schickt eine HTTPS-Anfrage an den Anwendungsserver. Die Logikschicht prüft, ob der Platz frei ist, berechnet den Preis (Ermäßigung) und veranlasst die Speicherung: Sie sendet SQL-Befehle an die Datenhaltungsschicht, die die Buchung in der Datenbank speichert und das Ergebnis zurückmeldet. Die Logikschicht gibt eine Antwort (z. B. JSON mit Buchungsnummer) an die Präsentationsschicht, die sie dem Nutzer anzeigt. Die Präsentationsschicht greift nie direkt auf die Datenbank zu.

Schicht (Layer) vs. Stufe (Tier): Layer ist die logische Aufteilung des Codes, Tier die physische Verteilung auf Rechner. Drei Schichten können auf einem Rechner laufen; bei einer Webanwendung sind sie meist auf drei Stufen verteilt (Client-Rechner, Anwendungsserver, Datenbankserver) – deshalb auch „3-Tier“ bzw. allgemein n-Tier.

MVC – Model View Controller

MVC ist ein Architektur- bzw. Entwurfsmuster für Anwendungen mit Benutzeroberfläche. Es trennt drei Verantwortlichkeiten:

• Model: die fachlichen Daten und die zugehörige Geschäftslogik (Klassen wie Medium, Dienste wie MedienKatalog, Datenzugriff). Kennt weder View noch Controller.
• View: die Darstellung der Daten (HTML-Template, Fenster, Liste). Enthält keine Geschäftslogik.
• Controller: nimmt Benutzereingaben entgegen, ruft das Model auf und wählt die passende View aus. Er „steuert“, rechnet aber nicht selbst.

Vorteile von MVC: Darstellung lässt sich ändern oder ergänzen (z. B. zusätzliche Smartphone-Ansicht), ohne Geschäftslogik anzufassen; mehrere Views für dasselbe Model; Logik ist ohne Oberfläche testbar; Designer und Entwickler können parallel arbeiten. Im klassischen Desktop-MVC benachrichtigt das Model die View über Änderungen (Beobachter-Muster); in Web-Frameworks (Spring MVC, ASP.NET Core MVC, Laravel) übergibt der Controller die Daten an die View. Verwandte Muster: MVP, MVVM (z. B. bei Android, WPF, Angular).

Monolith und Microservices

Ein guter Mittelweg ist der modulare Monolith: ein Deployment, intern aber streng in fachliche Module getrennt – bei Bedarf lassen sich einzelne Module später als Microservice herauslösen.

So gehst du vor: Architektur aus einem Szenario ableiten und skizzieren

1. Benutzergruppen und Endgeräte sammeln → Clients in der Präsentationsschicht (Browser, App, Kassen-Terminal).
2. Fachliche Funktionen sammeln → Dienste/Komponenten der Logikschicht (meist ein Anwendungsserver mit REST-API).
3. Daten sammeln → Datenbank(en) in der Datenhaltungsschicht; lokale Datenhaltung auf Clients (Offline) gesondert zeigen.
4. Externe Systeme ergänzen (Zahlungsdienst, Kartendienst, ERP) – meist von der Logikschicht angesprochen.
5. Verbindungen beschriften: Protokoll und Format (HTTPS/REST mit JSON, SQL, Datei-Export XML/CSV).
6. Schichten als Bänder oder Rahmen kennzeichnen und eine kurze Legende ergänzen.

WZ-04 · Compiler vs. Interpreter Sonstige

Vorkommen: 1/9 · Prüfung: W21 T1 A1a (6 P: aa) je eine Programmiersprache für Compiler- und Interpretersprachen nennen, ab) Unterschied beschreiben, ac) je einen Vor- und Nachteil eines Interpreters gegenüber einem Compiler nennen – je 2 P)

Ein Prozessor versteht nur Maschinencode (Befehle seines Befehlssatzes, z. B. x86-64 oder ARM). Programme in Hochsprachen müssen deshalb übersetzt werden. Dafür gibt es zwei Grundprinzipien – und Mischformen.

• Compiler: übersetzt den gesamten Quellcode vor der Ausführung in Maschinencode (bzw. eine andere Zielsprache) und erzeugt eine ausführbare Datei. Ausgeführt wird später nur noch diese Datei – Quellcode und Compiler werden dafür nicht mehr gebraucht.
• Interpreter: liest den Quellcode zur Laufzeit Anweisung für Anweisung, übersetzt sie und führt sie sofort aus. Es entsteht keine ausführbare Datei; auf jedem Zielrechner muss der Interpreter installiert sein.

Mischformen: Bytecode, virtuelle Maschine und JIT

Java wird vom Compiler javac nicht in Maschinencode, sondern in plattformunabhängigen Bytecode (.class-Dateien, gebündelt als .jar) übersetzt. Diesen führt die Java Virtual Machine (JVM) aus: Sie interpretiert den Bytecode zunächst und übersetzt häufig genutzte Programmteile („Hotspots“) zur Laufzeit mit dem Just-in-time-Compiler (JIT) in optimierten Maschinencode. Ergebnis: „Write once, run anywhere“ (dieselbe .jar läuft auf jedem System mit passender JVM) bei fast nativer Geschwindigkeit. Genauso arbeiten C# und andere .NET-Sprachen (Zwischencode IL, Laufzeitumgebung CLR) und Kotlin. Auch Python erzeugt intern Bytecode (.pyc), gilt aber als interpretierte Sprache; JavaScript-Engines im Browser kombinieren Interpreter und JIT.

Ein Transpiler (Source-to-Source-Compiler) übersetzt eine Hochsprache in eine andere, z. B. TypeScript → JavaScript (tsc). Vorteil: Die strengere Ausgangssprache (statische Typen) findet Fehler beim Übersetzen; ausgeführt wird das erzeugte JavaScript.

Der Übersetzungsvorgang im Detail

1. Präprozessor (C/C++): bindet Header-Dateien ein (#include), ersetzt Makros.
2. Compiler:
   • lexikalische Analyse: Quelltext in Tokens zerlegen (Schlüsselwörter, Bezeichner, Zahlen, Operatoren),
   • Syntaxanalyse (Parser): prüft die Grammatik und baut einen Syntaxbaum → Syntaxfehler,
   • semantische Analyse: prüft Bedeutung, z. B. Typen, deklarierte Variablen → Typfehler,
   • Optimierung und Codeerzeugung: Objektcode (Maschinencode mit noch offenen Verweisen).
3. Linker (Binder): verbindet die Objektdateien des Programms mit den benötigten Bibliotheken, löst Verweise auf Funktionen in anderen Dateien auf und erzeugt die ausführbare Datei.
4. Loader (Betriebssystem): lädt die Datei beim Start in den Speicher.

Fehlerarten

Werkzeuge der Entwicklungsumgebung (IDE)

Eine IDE (Integrated Development Environment, z. B. IntelliJ IDEA, Eclipse, Visual Studio, Android Studio; VS Code als erweiterbarer Editor) vereint die Werkzeuge der Entwicklung unter einer Oberfläche: Editor mit Syntaxhervorhebung und Autovervollständigung, Fehleranzeige schon beim Tippen, Compiler/Build-Integration (Maven, Gradle), Debugger, Test-Runner (JUnit), Refactoring-Funktionen (z. B. Methode umbenennen in allen Dateien), Code-Formatierung, Git-Integration, Navigation (zur Definition springen, Aufrufe finden), Profiler.

Mit dem Debugger wird ein Programm kontrolliert ausgeführt, um logische Fehler zu finden:

• Haltepunkt (Breakpoint): Das Programm hält an einer gewählten Zeile an; bedingter Haltepunkt nur, wenn eine Bedingung gilt (z. B. i == 99).
• Schrittweise Ausführung: Step Over (nächste Zeile), Step Into (in die aufgerufene Methode hinein), Step Out (bis zum Ende der Methode), Resume (bis zum nächsten Haltepunkt).
• Variablen und Ausdrücke beobachten (Watches), Werte zur Laufzeit ändern, Aufrufstapel (Call Stack) ansehen.

WZ-05 · Klassenbibliotheken, Frameworks & Dokumentation Sonstige

Vorkommen: 1/9 · Prüfung: W21 T1 A1b (10 P: ba) einen Vorteil und einen Nachteil des Einsatzes einer umfassenden Klassenbibliothek beschreiben (4 P), bb) drei Aspekte beschreiben, die bei der Dokumentation einer eigenen Erweiterung der Bibliothek zu beachten sind (6 P))

Eine Klassenbibliothek ist eine Sammlung wiederverwendbarer, bereits getesteter Klassen und Methoden für wiederkehrende Aufgaben, z. B. die Java-Standardbibliothek (java.util, java.time), Bibliotheken für JSON, PDF-Erzeugung, Logging oder Diagramme. Die öffentlich nutzbaren Klassen und Methoden bilden die API (Application Programming Interface) der Bibliothek – nur auf sie darf sich der eigene Code verlassen; interne Details können sich ändern.

Bibliothek oder Framework?

Ein Framework ist ein Rahmengerüst, das den Ablauf und die Struktur der Anwendung vorgibt. Der Entwickler ergänzt nur fachlichen Code an vorgesehenen Stellen (Klassen ableiten, Interfaces implementieren, Annotationen wie @GetMapping oder @Test), und das Framework ruft diesen Code zur richtigen Zeit auf. Diese Umkehr der Steuerung heißt Inversion of Control („Hollywood-Prinzip: Don’t call us, we call you“). Beispiele: Spring/Spring Boot, Jakarta EE, ASP.NET Core, Angular, Django, Laravel, Android-SDK, JUnit.

Vor- und Nachteile (umfangreicher) Klassenbibliotheken

Paketmanager und Abhängigkeiten

Paketmanager bzw. Build-Tools mit Abhängigkeitsverwaltung (Maven/Gradle für Java, npm für JavaScript, pip für Python, NuGet für .NET) erledigen: Bibliotheken in der angegebenen Version aus einem zentralen Repository (Maven Central, npm-Registry, PyPI) herunterladen, transitive Abhängigkeiten (Abhängigkeiten der Abhängigkeiten) automatisch mitladen, Versionskonflikte auflösen, Gültigkeitsbereiche trennen (z. B. Testbibliotheken nur zum Testen) und den Stand reproduzierbar machen (Lock-Datei wie package-lock.json hält die exakt verwendeten Versionen fest). Abhängigkeiten werden deklariert statt als JAR-Dateien ins Repository kopiert.

"dependencies": {
  "express": "^4.19.2",
  "dayjs":   "~1.11.10"
},
"devDependencies": {
  "jest": "^29.7.0"
}

Semantische Versionierung (SemVer)

Versionsnummern der Form MAJOR.MINOR.PATCH (z. B. 4.19.2) mit festen Regeln:

Versionen 0.y.z gelten als Anfangsentwicklung – dort kann sich alles jederzeit ändern. Vorabversionen werden angehängt: 2.0.0-beta.1. Übliche Praxis: Veraltetes erst in einer MINOR-Version als deprecated markieren und frühestens in der nächsten MAJOR-Version entfernen.

Risiken durch Abhängigkeiten und Gegenmaßnahmen

Eine eigene Bibliothekserweiterung dokumentieren

Wer eine Bibliothek um eigene Klassen erweitert, muss so dokumentieren, dass andere Entwickler (Zielgruppe!) die Erweiterung ohne Rückfrage korrekt einsetzen und später warten können. Worauf zu achten ist:

• Vollständige API-Beschreibung jeder öffentlichen Klasse und Methode: Zweck, Parameter (Bedeutung, Einheit, gültiger Wertebereich, ob null erlaubt ist), Rückgabewert, mögliche Exceptions und wann sie auftreten, Seiteneffekte, ggf. Thread-Sicherheit.
• Bezug zur Originalbibliothek: Was wurde erweitert oder überschrieben, welches Verhalten weicht ab, mit welcher Version der Basisbibliothek ist die Erweiterung getestet/kompatibel?
• Versionierung und Änderungshistorie: eigene Versionsnummer (SemVer), Changelog, veraltete Methoden kennzeichnen (@deprecated mit Alternative), @since.
• Codebeispiele und Einstieg (Einbindung als Abhängigkeit, typische Verwendung).
• Form und Pflege: direkt im Quellcode (Javadoc), daraus HTML erzeugen; einheitliche Sprache und Begriffe, verständlich, aktuell halten – Dokumentation ist Teil jeder Änderung (Review!).
• Rechtliches/Organisatorisches: Lizenz der Basisbibliothek beachten (Hinweise, ggf. Offenlegungspflichten), Autor/Ansprechpartner.

Beispiel: Javadoc-Kommentar

/**
 * Berechnet den Bruttobetrag aus einem Nettobetrag.
 * Das Ergebnis wird kaufmännisch auf zwei Nachkommastellen gerundet.
 *
 * <p>Beispiel: {@code berechneBrutto(new BigDecimal("100.00"), Steuersatz.ERMAESSIGT)}
 * liefert {@code 107.00}.</p>
 *
 * @param netto Nettobetrag in Euro; nicht {@code null} und nicht negativ
 * @param satz  anzuwendender Steuersatz; nicht {@code null}
 * @return Bruttobetrag in Euro mit zwei Nachkommastellen
 * @throws IllegalArgumentException wenn {@code netto} negativ ist
 * @since 1.4
 * @see Steuersatz
 */
public static BigDecimal berechneBrutto(BigDecimal netto, Steuersatz satz) { … }

Wichtige Javadoc-Tags: @param, @return, @throws, @since, @deprecated, @see, {@code …}, {@link …}. Daraus erzeugt das Werkzeug javadoc eine HTML-Referenz (entsprechend: XML-Kommentare in C#, Docstrings in Python, JSDoc).

Erweitern statt ändern: Eine Bibliothek erweitert man über ihre vorgesehenen Erweiterungspunkte – eigene Unterklassen, Implementierung von Interfaces, Komposition/Wrapper (eigene Klasse benutzt die Bibliotheksklasse) – und nicht durch Ändern ihres Quellcodes. Sonst gehen die eigenen Änderungen beim nächsten Update der Bibliothek verloren oder Updates (auch Sicherheitsupdates) werden praktisch unmöglich (Open-Closed-Prinzip: offen für Erweiterung, geschlossen für Änderung).

WZ-06 · Open Source & Lizenzen Sonstige

Vorkommen: 1/9 · Prüfung: W22 T1 A2c (9 P: ca) Begriff Open Source erläutern (3 P), cb) begründen, ob jede Open-Source-Bibliothek ohne Einschränkungen eingesetzt werden darf (2 P), cc) einen Vor- und einen Nachteil von Open-Source-Bibliotheken beschreiben (4 P))

Was ist Open Source?

Open-Source-Software ist Software, deren Quellcode öffentlich zugänglich ist und deren Lizenz jedem erlaubt, sie für beliebige Zwecke zu nutzen, den Code zu untersuchen, zu verändern und – verändert oder unverändert – weiterzugeben. Welche Lizenzen das erfüllen, legt die Open Source Initiative (OSI) anhand der Open Source Definition fest. Deren zehn Kriterien zusammengefasst:

• freie Weitergabe (auch Verkauf als Teil einer Distribution) ohne Lizenzgebühr,
• Quellcode muss verfügbar sein; veränderte und abgeleitete Werke müssen erlaubt sein (die Lizenz darf verlangen, dass Änderungen gekennzeichnet werden),
• keine Diskriminierung von Personen, Gruppen oder Einsatzgebieten (auch kommerzielle Nutzung erlaubt),
• die Rechte gelten für alle Empfänger, ohne Zusatzvertrag, und sind nicht an ein bestimmtes Produkt gebunden,
• die Lizenz darf andere Software, die zusammen verbreitet wird, nicht einschränken und muss technologieneutral sein.

Die Free Software Foundation spricht von Freier Software mit vier Freiheiten (benutzen, untersuchen, weitergeben, verbessern). Gemeint sind praktisch dieselben Lizenzen, die Begründung ist eher ethisch; zusammengefasst oft „FOSS“.

Abgrenzung zu anderen Software-Arten

Lizenztypen: permissiv und Copyleft

Kern der Unterscheidung ist die Frage, ob die Lizenz auf abgeleitete Werke „vererbt“ wird. Copyleft bedeutet: Wer die Software verändert oder in eigene Software einbaut und weitergibt, muss das Ergebnis unter derselben Lizenz und mit Quellcode weitergeben.

Wann greift das Copyleft? – Weitergabe ist der Auslöser

• Weitergabe (Verbreitung) = Software verlässt die eigene Organisation: Verkauf, Download, App-Store, Auslieferung an Kunden, auch JavaScript, das an Browser ausgeliefert wird. Dann gelten die Pflichten der Lizenz.
• Nur interne Nutzung (auch verändert) und Betrieb auf dem eigenen Server, den Kunden nur über das Netz nutzen (SaaS): Bei MIT, LGPL und GPL entsteht keine Offenlegungspflicht – bei der AGPL schon.
• Werkzeuge wie Compiler, Git, Build-Server oder Datenbanken, die man nur benutzt, „infizieren“ den eigenen Code nicht, auch wenn sie unter GPL stehen.

Dual Licensing: Manche Hersteller bieten dieselbe Software unter einer Copyleft-Lizenz (GPL/AGPL) und gegen Gebühr unter einer kommerziellen Lizenz an. Wer den Quellcode nicht offenlegen will, kauft die kommerzielle Lizenz.

Lizenzkompatibilität: Code unter permissiver Lizenz darf in GPL-Projekte übernommen werden (MIT → GPL: ja; Apache 2.0 → GPL-3.0: ja, aber nicht in „GPL-2.0-only“-Projekte). Umgekehrt nicht: GPL-Code darf nicht in ein MIT- oder proprietäres Projekt kopiert werden, weil die Lizenz des Ergebnisses dann GPL sein muss. GPL-2.0-only und GPL-3.0 sind untereinander nicht kompatibel („or later“-Klausel beachten).

Vor- und Nachteile von Open-Source-Bibliotheken

So gehst du vor: Darf diese Bibliothek eingesetzt werden?

1. Lizenz ermitteln (LICENSE-Datei, Paketangaben) – keine Lizenz = nicht verwenden bzw. Erlaubnis einholen.
2. Einsatz klären: Wird die Software weitergegeben (App, Download, Auslieferung an Kunden), nur intern genutzt oder als Netzdienst (SaaS) betrieben? Wird die Bibliothek verändert?
3. Lizenztyp prüfen: permissiv → Hinweise beilegen; schwaches Copyleft → Bibliothek unverändert und austauschbar einbinden, Änderungen offenlegen; GPL bei Weitergabe bzw. AGPL bei SaaS → mit proprietärem Geschäftsmodell nicht vereinbar → Alternative oder kommerzielle Lizenz.
4. Transitive Abhängigkeiten und kommerzielle Lizenzbedingungen (Nutzerzahl, Weitergabe) ebenso prüfen.
5. Ergebnis dokumentieren (Lizenzliste/SBOM, Third-Party-Notices in der Anwendung); Prüfung in der Pipeline automatisieren.

Software Bill of Materials (SBOM)

Eine SBOM („Stückliste“ der Software) ist eine maschinenlesbare, vollständige Liste aller Komponenten eines Softwareprodukts – einschließlich transitiver Abhängigkeiten – mit Name, Version, Hersteller/Herkunft, Lizenz und Prüfsumme. Gängige Formate sind SPDX und CycloneDX; Build-Werkzeuge erzeugen sie automatisch in der Pipeline. Nutzen: Wird eine Sicherheitslücke in einer Bibliothek bekannt, sieht man sofort, welche Produkte und Versionen betroffen sind; Lizenzprüfung und Weitergabe von Lizenzinformationen an Kunden; Transparenz in der Lieferkette. Der EU Cyber Resilience Act (Verordnung (EU) 2024/2847) verpflichtet Hersteller von Produkten mit digitalen Elementen u. a. dazu, die enthaltenen Komponenten und Schwachstellen zu dokumentieren und dafür eine SBOM in einem gängigen, maschinenlesbaren Format zu erstellen. Die Meldepflichten für aktiv ausgenutzte Schwachstellen gelten seit 11. September 2026, die übrigen Pflichten ab 11. Dezember 2027.

B · Belegsatz

Enthält nur, was dir auch die IHK beilegen würde: die Ausgangssituation und die Anlagen, auf die sich die Aufgaben beziehen. Notationshilfen legt die IHK für diese Themen nicht bei (die Belegsätze W21 und W22 enthielten nur UML, Pseudocode/Struktogramm und SQL). Alle Firmen, Personen und Bibliotheken sind frei erfunden; Lizenzen, Werkzeuge und Befehle sind real.

$ git log --oneline --graph --all
* 7d2e4b1 (HEAD -> main, origin/main) MP-118: Auftragsliste nach Termin sortieren
* 3c9a0f5 MP-112: REST-Endpunkt GET /auftraege/{id} ergänzt
* e58b3d7 asdf
* d0c4417 Zwischenstand Freitag
* a41c9e2 fix
* 19be7d0 Projektgerüst angelegt

$ git show --stat a41c9e2
commit a41c9e2b7f3d8e1c0a59b6d2f4e7c8a1b3d5e6f7
Author: Lukas Brandt <l.brandt@lindner-digital.example>
Date:   Tue Sep 15 16:42:10 2026 +0200

    fix

 src/main/java/de/lindner/monteurplus/auftrag/AuftragService.java | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

# .gitlab-ci.yml – MonteurPlus Server (Spring Boot, Java 21)
stages:
  - build
  - test
  - analyse
  - package
  - staging
  - production

default:
  image: maven:3.9-eclipse-temurin-21

build:
  stage: build
  script:
    - mvn -B compile

unit-tests:
  stage: test
  script:
    - mvn -B test
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml

integration-tests:
  stage: test
  services:
    - postgres:16
  variables:
    POSTGRES_DB: monteurplus_test
    POSTGRES_USER: ci
    POSTGRES_PASSWORD: $TEST_DB_PASSWORT    # geschützte CI/CD-Variable
  script:
    - mvn -B verify -P integrationstest

code-analyse:
  stage: analyse
  script:
    - mvn -B compile checkstyle:check spotbugs:check

package:
  stage: package
  image: docker:27
  services:
    - docker:27-dind
  script:
    # Das Dockerfile baut die JAR-Datei und verpackt sie mit Java 21 in ein Image
    - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY"
    - docker build -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-staging:
  stage: staging
  script:
    - ./deploy.sh staging "$CI_COMMIT_SHORT_SHA"
  environment: staging
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-production:
  stage: production
  script:
    - ./deploy.sh production "$CI_COMMIT_SHORT_SHA"
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

# .gitlab-ci.yml – Monteur-App (Android) – Entwurf J. Weber
image: registry.lindner.example/android-build:35

variables:
  KEYSTORE_PASSWORT: "Albers2026!"          # Passwort des App-Signaturschlüssels
  PLAY_STORE_ZUGANG: "pl4y-st0re-7731-mp"   # Zugang zum Play-Store-Konto

stages:
  - build
  - test
  - deploy

build-app:
  stage: build
  script:
    - ./gradlew assembleRelease

unit-tests:
  stage: test
  script:
    - ./gradlew testReleaseUnitTest
  allow_failure: true        # damit die Pipeline nicht so oft rot ist

deploy-playstore:
  stage: deploy
  script:
    - ./gradlew publishReleaseBundle --track production

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
  <dependency>
    <groupId>de.example.terminkern</groupId>
    <artifactId>terminkern</artifactId>
    <version>2.4.1</version>
  </dependency>
  <dependency>
    <groupId>com.example.pdf</groupId>
    <artifactId>pdfmaker-core</artifactId>
    <version>7.1.0</version>
  </dependency>
  <dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
    <scope>test</scope>
  </dependency>
</dependencies>

[INFO] de.lindner:monteurplus-server:jar:1.3.0
[INFO] +- org.springframework.boot:spring-boot-starter-web:jar:3.5.6:compile
[INFO] |  \- (… 27 weitere Bibliotheken …)
[INFO] +- de.example.terminkern:terminkern:jar:2.4.1:compile
[INFO] |  +- org.example.kalender:feiertage-de:jar:1.8.0:compile
[INFO] |  \- org.example.json:json-mini:jar:0.9.2:compile
[INFO] +- com.example.pdf:pdfmaker-core:jar:7.1.0:compile
[INFO] \- org.junit.jupiter:junit-jupiter:jar:5.12.2:test

package de.lindner.monteurplus.termin;

import de.example.terminkern.Bundesland;
import de.example.terminkern.Kalender;
import java.time.Duration;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.util.Optional;

// Erweiterung von TerminKern 2.4.1 für MonteurPlus
public class EinsatzKalender extends Kalender {

    private static final int MAX_TAGE = 30;
    private final Arbeitszeitmodell modell;

    public EinsatzKalender(Bundesland land, Arbeitszeitmodell modell) {
        super(land);
        this.modell = modell;
    }

    // sucht termin
    public Optional<LocalDateTime> naechsterFreierTermin(
            Monteur m, LocalDate ab, Duration dauer, boolean notdienst) {
        if (dauer.isNegative() || dauer.isZero()) {
            throw new IllegalArgumentException("dauer");
        }
        LocalDate tag = ab;
        for (int i = 0; i < MAX_TAGE; i++) {
            if (notdienst || (!istFeiertag(tag) && modell.istArbeitstag(tag))) {
                Optional<LocalDateTime> slot =
                        m.getEinsatzplan().freierSlot(tag, dauer);
                if (slot.isPresent()) {
                    return slot;
                }
            }
            tag = tag.plusDays(1);
        }
        return Optional.empty();
    }
}

C · Aufgaben

Alle Aufgaben beziehen sich auf die Ausgangssituation in Anlage 1. Antworten Sie – wie in der Prüfung – in ganzen Sätzen und mit Bezug auf die Situation, sofern nicht ausdrücklich nur „nennen“ verlangt ist.

WZ-01 · Versionsverwaltung (Git)

(1)  git switch -c feature/MP-130-fotos
(2)  git add FotoController.java                       # neue Datei
(3)  git commit -m "MP-130: Upload von Auftragsfotos"            # F1
(4)  git commit -am "MP-130: Fotos vor dem Upload verkleinern"   # F2
(5)  git switch main
(6)  git pull
(7)  git merge feature/MP-130-fotos                    # M, kein Konflikt
(8)  git tag -a v1.3.0 -m "Release 1.3.0"
(9)  git push origin main
(10) git push origin v1.3.0

$ git merge feature/MP-131-anfahrt
Auto-merging src/main/java/de/lindner/monteurplus/auftrag/AuftragService.java
CONFLICT (content): Merge conflict in src/main/java/de/lindner/monteurplus/auftrag/AuftragService.java
Automatic merge failed; fix conflicts and then commit the result.

public double anfahrtspauschale(Auftrag a) {
<<<<<<< HEAD
    return a.isNotdienst() ? 89.00 : 39.00;
=======
    return a.isNotdienst() ? 79.00 : 35.00 + 0.50 * a.getEntfernungKm();
>>>>>>> feature/MP-131-anfahrt
}

WZ-02 · CI/CD & Deployment

WZ-03 · Softwarearchitektur

WZ-04 · Compiler vs. Interpreter

WZ-05 · Klassenbibliotheken, Frameworks & Dokumentation

WZ-06 · Open Source & Lizenzen

Originalaufgaben zum Üben

Diese echten Prüfungsaufgaben passen zu diesem Block (Dateien im Ordner Prüfungsvorbereitung). Für W21 und W22 gibt es keine Lösungsdateien; Lösungen liegen nur für 2023 Sommer, 2023 Winter, 2024 Sommer und 2025 Winter vor (dort vom u-form-Verlag). Vergleiche deine Antworten zu W21/W22 mit den Lösungen der entsprechenden Übungsaufgaben in diesem Block.