aiMOOC

Eine Systemarchitektur nachvollziehbar darstellen - Fachrichtungsbezogenes IT-Abschlussprojekt - Ausbildung

QR-Code

Einleitung

Du lernst, die Architektur eines fachrichtungsbezogenen IT-Abschlussprojekts so darzustellen, dass Auftraggebende, Entwicklung, Betrieb und prüfende Fachleute dieselbe Lösung nachvollziehen können. Eine Softwarearchitektur beschreibt die wichtigen Bausteine, ihre Verantwortlichkeiten, Beziehungen, Schnittstellen und begründeten Entscheidungen. Sie ist mehr als eine Sammlung hübscher Kästen: Jedes Diagramm muss eine konkrete Frage beantworten. Du lernst Kontext-, Baustein-, Laufzeit- und Verteilungssichten kennen und belegst Aussagen mit fiktiven Testdaten.

Zielgruppe: Fachinformatikerinnen und Fachinformatiker im dritten Ausbildungsjahr. Gewählte Fachrichtung: Anwendungsentwicklung. Die Verfahren lassen sich mit anderer Schwerpunktsetzung auf Systemintegration, Daten- und Prozessanalyse oder Digitale Vernetzung übertragen, sind hier aber ausdrücklich an einem Softwareprojekt erläutert.

Fiktiver Ausbildungsfall: Die vollständig erfundene „Lernwerkstatt Morgenlicht“ möchte einen webbasierten Raumreservierungsdienst „RaumPlan“ für sechs berechtigte Mitarbeitende entwickeln. Es gibt drei Räume. Mitarbeitende legen Reservierungen an, sehen Belegungszeiten und können ihre eigenen Einträge stornieren. Eine Administratorrolle verwaltet Räume. Es werden ausschließlich erfundene Benutzernamen und Raumdaten eingesetzt. Weder handelt es sich um ein reales Prüfungsprojekt noch um einen Auftrag eines tatsächlichen Betriebs.

Lernziele: Du grenzt das System ab, beschreibst fünf wesentliche Komponenten, erläuterst mindestens drei Schnittstellen, führst einen Reservierungsablauf über die Systemgrenzen nach, begründest Sicherheits- und Architekturentscheidungen und prüfst Diagramme gegen konkrete Anforderungen.

Ausbildungsbezug, Stand Oktober 2026: Der KMK-Rahmenlehrplan, Beschluss vom 13.12.2019, beschreibt im schulischen Lernfeld 11a die Planung modularer Softwarekomponenten und die Dokumentation von Schnittstellen sowie im Lernfeld 12a „Kundenspezifische Anwendungsentwicklung durchführen“ die vollständige Durchführung und Bewertung eines Kundenauftrags im dritten Ausbildungsjahr (120 Stunden als schulischer Zeitrichtwert, nicht als Dauer dieses Kurses). Davon zu unterscheiden ist die betriebliche Fachinformatikerausbildungsverordnung (FIAusbV) vom 28.02.2020: Sie regelt Ausbildungsrahmenplan und Anforderungen der Ausbildung beziehungsweise Prüfung. Eine selbst erstellte Übungsdokumentation ist keine offizielle Prüfungsaufgabe und keine Prüfungsfreigabe. Quellen und Daten stehen im OER-Abschnitt.

Architekturauftrag, Grenzen und Anforderungen

Aus einem Wunsch werden prüfbare Anforderungen

Die Aussage „Das System soll schnell sein“ reicht nicht. Für RaumPlan vereinbaren die fiktiven Beteiligten: Eine erfolgreiche Reservierung muss für die angemeldete Person innerhalb von höchstens 2 Sekunden bestätigt werden, gemessen bei einem fiktiven Test mit 20 gleichzeitig gesendeten Anfragen; dies ist ein Zielwert, kein nachgewiesenes Messergebnis. Die Eingabe muss einen Raum, ein Datum sowie Start und Ende enthalten. Für denselben Raum dürfen sich zwei bestätigte Reservierungsintervalle nicht überschneiden. Die Zeiten werden intern als Zeitpunkte mit Zeitzonenbezug gespeichert; in der Oberfläche wird die lokale Zeitzone kenntlich gemacht.

Weitere Anforderungen: Nur angemeldete Personen dürfen reservieren, die Administratorrolle darf Räume deaktivieren, jede Veränderung erhält eine technische Ereigniskennung ohne unnötige personenbezogene Inhalte. Fehler müssen verständlich erscheinen. Für eine Architekturprüfung notierst du je Anforderung ihre Kennung, die zuständige Komponente und den passenden Test. Beispiel: A-03 „keine Doppelbelegung“ → Reservierungsdienst und Datenhaltung → zwei konkurrierende Buchungsanfragen.

Systemkontext und Verantwortungsgrenze

Ein Kontextdiagramm zeigt das System als einen Kasten: außen befinden sich Nutzende, Administratorrolle und gegebenenfalls externe Dienste. Bei RaumPlan sind Browser und Authentifizierungsdienst als Schnittstellenpartner zu beschreiben. Innerhalb der Systemgrenze liegen Weboberfläche, API, Reservierungslogik und Datenbankzugriff. Ein externer E-Mail-Dienst ist ausdrücklich nicht Teil des vereinbarten Funktionsumfangs. Eine punktierte oder farbliche Systemgrenze allein genügt nicht: Textlich muss erkennbar sein, wer die Daten speichert und welche Verantwortung ausgelagert ist.

Nenne auf jedem Diagramm Projektnamen, Sicht, Version, Bearbeitungsstand, Legende und eindeutige Pfeilbedeutung. „Pfeil von A nach B“ sollte etwa „HTTPS-Anfrage mit JSON-Nutzdaten“ oder „Antwort mit HTTP-Status“ bedeuten, nicht ein bloßes „ist verbunden mit“. Ein Architekturdiagramm ist ein Modell, keine Netzwerkmessung.

Datei:3-Schichten-Architektur.svg

Beispiel einer Drei-Schichten-Architektur, nicht das Architekturdiagramm des fiktiven RaumPlan-Projekts. Quelle: Wikimedia Commons; Dew1978, CC BY-SA 4.0.

Bausteinsicht und Schnittstellen

Ein System aus fünf klaren Bausteinen

Das Architekturmodell von RaumPlan trennt Browseroberfläche (Eingaben und Darstellung), API-Schicht (Anfrageannahme und Berechtigungsprüfung), Reservierungsdienst (Fachregel gegen Überlappungen), Datenzugriff (Abfragen und Transaktionen) sowie relationale Datenbank (dauerhafte Speicherung). Die Datenbank ist ein Speicherbaustein, keine Geschäftslogik. Diese Trennung erleichtert verständliche Abhängigkeiten und Tests.

Beschreibe jeden Kasten auf dem Bausteindiagramm nach einem einheitlichen Muster: Verantwortung, Eingaben, Ausgaben, verwendete Technik als Beispiel, abhängige Bausteine, Fehlerfälle und zugehörige Anforderungen. Ein guter Schnitt erlaubt, die Reservierungsregel isoliert mit künstlichen Datensätzen zu prüfen. Für ein kleines Projekt kann ein modularer Monolith mit diesen logischen Komponenten genügen; fünf Komponenten bedeuten nicht fünf eigenständige Server oder Microservices.

API-Vertrag an einem kontrollierbaren Beispiel

Beispiel einer fiktiven HTTP-Schnittstelle: „POST /api/reservierungen“ über HTTPS. Die JSON-Anfrage enthält raumId, beginn und ende. Ein erfolgreicher Aufruf liefert beispielhaft den HTTP-Status 201 und eine neue Reservierungskennung. Fehlende Angaben liefern 400, fehlende Anmeldung 401, eine authentifizierte Person ohne ausreichende Berechtigung 403 und eine Belegungskollision 409. Die konkrete Zuordnung ist eine bewusste Schnittstellenvereinbarung dieses Modellprojekts und muss dokumentiert sowie getestet werden.

Datenvertrag: raumId ist eine gültige Kennung; beginn und ende sind Zeitpunkte im ISO-8601-Darstellungsformat mit Zeitzonenbezug; ende muss später als beginn liegen. Das Fachmodell verhindert Überschneidungen auch bei gleichzeitigen Anfragen mittels geeigneter Transaktions- beziehungsweise Sperrstrategie. Nur eine Prüfung im Browser wäre nicht ausreichend: Andere Clients könnten sie umgehen. Eine API-Beschreibung enthält zusätzlich Beispielwerte, Zugangsvoraussetzungen, Fehlerformat und Versionsregel.

Datei:Component-3.png

UML-Komponentendiagramm als fremdes Darstellungsbeispiel: eigene Bausteinbezeichnungen müssen für RaumPlan neu erarbeitet werden. Quelle: Wikimedia Commons; Gubaer, GFDL 1.2 oder später.

Deutschsprachiges ergänzendes Video „Was ist eine Softwarearchitektur?“ von ModelMyMind (01.09.2024). Video ansehen und anschließend eine eigene Definition mit Bezug auf RaumPlan formulieren.

Laufzeitsicht und Datenflüsse

Ein Reservierungsvorgang Schritt für Schritt

Während die Bausteinsicht die Bausteine benennt, zeigt ein Sequenzdiagramm die zeitliche Reihenfolge eines Vorgangs. Für „Raum A reservieren“ lautet der modellierte Normalfall: Browser sendet Anfrage an API; API prüft Anmeldung und Berechtigung; Reservierungsdienst prüft fachliche Regeln; Datenzugriff führt eine transaktionale Prüfung und Speicherung aus; Datenbank bestätigt; API sendet 201 an den Browser. Im Kollisionsfall wird nichts neu bestätigt, die Transaktion wird entsprechend behandelt und die API liefert 409. Ein gestrichelter Rückpfeil kann eine Antwort kennzeichnen; die Diagrammlegende muss es erklären.

Gerade die Reihenfolge von „Überlappung prüfen“ und „Datensatz speichern“ ist kritisch: Ohne Schutz vor konkurrierenden Änderungen können zwei gleichzeitig gestartete Anfragen beide eine zunächst freie Zeit sehen. Zeichne deshalb neben dem Normalfall mindestens einen Fehlerpfad mit Status 409. Ein Diagramm, das nur den Normalfall zeigt, macht diese Architekturentscheidung unsichtbar.

Fehler beim Erstellen des Vorschaubildes:

Verifiziertes allgemeines Sequenzdiagramm, englischsprachige Bildbeschriftung; bitte nicht als RaumPlan-Ablauf missverstehen. Quelle: Wikimedia Commons; Dannyc20, CC BY-SA 3.0.

Datenmodell und prüfbare Größen

Das fiktive Minimalmodell enthält „Raum“ (raumId, name, aktiv), „Konto“ (kontoId, rolle) und „Reservierung“ (reservierungId, raumId, kontoId, beginn, ende, status). Beziehungen werden mit Kardinalitäten beschrieben: Ein Raum kann viele Reservierungen haben; eine Reservierung gehört genau zu einem Raum. Zu beachten sind referenzielle Integrität, Zugangsbeschränkungen und die zeitbezogene Sperrregel.

Kapazitätsannahme für ein Rechenbeispiel: Es werden 240 Reservierungsdatensätze pro Tag erzeugt; ein kompletter gespeicherter Datensatz einschließlich rechnerisch pauschal angenommener Metadaten benötigt 30 KiB. Bei 90 Tagen Aufbewahrung ergibt sich 240 × 30 KiB × 90 = 648.000 KiB = 632,8125 MiB, ohne Reserve für Datenbankindizes, Protokolle, Sicherungskopien und Speicherverwaltung. Dies ist eine Modellrechnung, keine Messung und keine reale Speicherbedarfsprognose. Dokumentiere Annahmen, Einheiten und Unsicherheiten immer getrennt vom Ergebnis.

Verteilung, Sicherheit und Betriebsfähigkeit

Vom logischen Modul zum Ausführungsort

Ein Verteilungsdiagramm zeigt, auf welchen Laufzeitumgebungen Komponenten betrieben werden. Für die Schulübung ist folgende Lösung zulässig: Browser auf einem Testgerät, Webanwendung mit API und Reservierungsdienst in einer abgeschotteten Testumgebung, Datenbank nur über eine interne Verbindung erreichbar. Der Datenbankport ist nicht öffentlich zugänglich. Logische Schichten und physische Rechner sind unterschiedliche Sichten: Mehrere Schichten können auf demselben Server liegen.

Alternativen werden sachlich verglichen: Ein modularer Monolith erlaubt weniger betriebliche Komplexität; unabhängig betriebene Dienste könnten getrennte Skalierung erleichtern, erhöhen aber Schnittstellen-, Betriebs- und Beobachtungsaufwand. Es gibt für RaumPlan keinen nachgewiesenen Bedarf an Microservices. Die ausgewählte Lösung wird mit Projektgröße und Qualitätserwartungen begründet.

Sicherheits- und Datenschutzgrenzen

Der Datenfluss markiert eine Vertrauensgrenze zwischen Internet-Browser und API. Der Server prüft Authentifizierung und Autorisierung unabhängig von der Oberfläche. Die Verbindung zum Dienst soll verschlüsselt erfolgen, Fehlermeldungen dürfen keine Daten anderer Konten offenlegen, und technische Protokolle enthalten weder Passwörter noch unnötige Reservierungsdetails. Ein Berechtigungstest muss belegen, dass Konto A nicht die Reservierung von Konto B storniert, wenn dafür keine Berechtigung vorliegt.

Backups, Wiederherstellung, Software-Updates, Fehlerbehandlung und Überwachung gehören in die Architekturdokumentation, auch wenn der Ausbildungsfall nur in einer Testumgebung umgesetzt wird. Benenne verantwortliche Rollen, Prüfintervalle und die noch offenen Entscheidungen statt bloß „sicher“ zu schreiben. Keine Arbeiten an Produktionsnetzen oder gefährlichen technischen Anlagen; praktische Versuche nur auf freigegebenen Systemen, unter qualifizierter Aufsicht und nach betrieblichen Vorgaben. Dieser Kurs ersetzt keine Befähigung oder Freigabe.

Fiktive Kostenentscheidung: Eine interne Testinstanz wird mit 45 Euro pro Monat und eine alternative betreute Umgebung mit 70 Euro pro Monat angesetzt. Für zwölf Monate sind dies 540 Euro gegenüber 840 Euro, also 300 Euro Differenz. Diese Zahlen sind ausschließlich didaktische Annahmen und unterstellen vergleichbaren Funktionsumfang; tatsächliche Sicherheits-, Arbeits- und Betriebskosten werden damit nicht vollständig bewertet.

Datei:Multidimensional software architecture contraction (MSAC).gif

Animation einer abstrakten Architekturmodellierung; nicht als reale Infrastruktur oder als vorgeschriebene Methode für RaumPlan zu verstehen. Quelle: Wikimedia Commons; Lora Gilyard, CC BY-SA 4.0.

Audio-Wortschatz: Datei:De-Computernetzwerk.ogg – Aussprache des Begriffs „Computernetzwerk“, Jeuwre, CC BY-SA 4.0; ergänzende Sprachhilfe, keine technische Anleitung.

Architekturentscheidungen dokumentieren und überprüfen

Die richtigen Dokumente für die richtige Zielgruppe

Ein präziser Architekturbericht beginnt mit Auftrag und Systemkontext, benennt funktionale und nichtfunktionale Anforderungen, erklärt Bausteine und Schnittstellen, zeigt ein Laufzeitbeispiel sowie die Verteilung und begründet Sicherheitsentscheidungen. Ergänze offene Punkte, Quellen, Diagrammversionen und nachvollziehbare Testergebnisse. Für fachfremde Auftraggebende ist die Kontextsichtsprache wichtiger als technische Details. Für Entwicklerinnen und Entwickler sind die Schnittstellenverträge und Fehlerpfade entscheidend. Der Betrieb benötigt Ausführungsorte, Protokollierung und Wiederherstellungsabläufe.

Nutze einen knappen Architekturentscheidungsbericht (ADR): Ausgangslage „kleiner Reservierungsdienst für sechs Personen“; Entscheidung „modularer Monolith“; Alternativen „mehrere eigenständige Dienste“; Begründung „geringer Koordinations- und Betriebsaufwand“; Folgen „gemeinsames Deployment, spätere Aufteilung möglich, wenn neue Anforderungen sie rechtfertigen“. Trenne bewusst Fakten, Annahmen und Entscheidung.

Review mit Rückverfolgbarkeit

Lege eine Tabelle mit fünf Spalten an: Anforderungs-ID, Architekturbaustein, Diagramm, Testfall, Ergebnis. Beispiel: A-03 | Reservierungsdienst und Datenzugriff | Sequenzsicht v1.1 | zwei überlappende Testbuchungen | erwartet: erste erfolgreich, zweite 409. Dass das Ergebnis erwartet wird, ist noch kein tatsächlich durchgeführter Test. Notiere bei Ausführung Messdatum, Testumgebung und beobachtete Resultate. A-01 Antwortzeit testest du mit definiertem Lastprofil und der Messgröße p95 statt aus Einzelwerten auf Betriebsgüte zu schließen.

Typische Fehler im Review: Pfeile ohne Bedeutung; Authentifizierung nur im Browser; zwei Diagramme mit widersprüchlichen Komponentennamen; fehlende Datenflüsse bei Löschung; Zielwerte als Messresultate ausgegeben; undefinierte Zeitzonen; ein Architekturentscheid ohne betrachtete Alternative. Eine gute Darstellung lässt eine dritte Person einen Pfad vom Nutzungswunsch über Diagramm und Entscheidung bis zum Test nachvollziehen.

Deutschsprachiges ergänzendes Video „UML-Klassendiagramme kurz erklärt“ von informatikZentrale (19.04.2016); es vertieft die Datenmodellierung, ersetzt aber keine Komponenten- oder Laufzeitsicht.

Interaktive Aufgaben

Quiz: Teste dein Wissen

Warum ist ein Systemkontextdiagramm für RaumPlan nützlich? (Es zeigt Systemgrenze und äußere Beteiligte) (!Es ersetzt alle späteren Tests) (!Es schreibt jeden Datenbankindex vor) (!Es zeigt zwingend fünf Server)

Rückmeldung: Die Kontextsicht klärt Verantwortung und Kommunikationspartner, nicht interne Implementierungsdetails.

Welche Komponente prüft die Regel gegen Doppelbelegung? (Reservierungsdienst) (!Browserfarbe) (!Videoeinbettung) (!Lizenzverzeichnis)

Rückmeldung: Die Geschäftsregel liegt auf der Serverseite im Reservierungsdienst und wird transaktional abgesichert.

Welche Rückmeldung passt im vereinbarten Modell zur Buchungskollision? (HTTP Status 409) (!HTTP Status 201) (!HTTP Status 301) (!HTTP Status 204)

Rückmeldung: 409 kennzeichnet den vereinbarten Konflikt; 201 wäre die erfolgreiche Neuanlage.

Was unterscheidet eine Laufzeitsicht von einer Bausteinsicht? (Sie zeigt die zeitliche Reihenfolge der Interaktionen) (!Sie ist nur eine Liste von Geräten) (!Sie ersetzt ein Datenmodell) (!Sie beschreibt nur die Projektkosten)

Rückmeldung: Ein Sequenzdiagramm zeigt den Ablauf einer konkreten Anfrage zwischen zuvor definierten Bausteinen.

Warum darf die Doppelbelegungsprüfung nicht allein im Browser liegen? (Mehrere Clients könnten sie sonst umgehen) (!Weil Browser niemals Daten anzeigen) (!Weil CSS die Datenbank sperrt) (!Weil eine Grafik genügt)

Rückmeldung: Die verbindliche fachliche Regel muss serverseitig und unter Konkurrenzbedingungen sicher gelten.

Welche Angabe gehört an den Pfeil zwischen Browser und API? (HTTPS Anfrage mit Datenformat und Richtung) (!Beliebige Doppellinie ohne Legende) (!Nur eine kreative Farbe) (!Die Privatadresse der Auszubildenden)

Rückmeldung: Protokoll, Richtung und Datenart machen einen Informationsfluss überprüfbar.

Was zeigt eine Verteilungssicht? (Auf welchen Laufzeitumgebungen Bausteine ausgeführt werden) (!Die Reihenfolge der Kurskapitel) (!Ausschließlich Benutzerwünsche) (!Nur die Lizenzkosten eines Bildes)

Rückmeldung: Die Verteilungssicht ordnet Komponenten Laufzeitumgebungen und Kommunikationswegen zu.

Wie viel Speicher ergeben 240 Datensätze zu 30 KiB täglich für 90 Tage ohne Zuschläge? (632,8125 MiB) (!632,8125 KiB) (!648000 MiB) (!30 MiB)

Rückmeldung: 240 mal 30 mal 90 ergibt 648000 KiB; geteilt durch 1024 sind das 632,8125 MiB.

Welche Aussage über den fiktiven Lasttest ist korrekt? (Zwei Sekunden sind zunächst ein zu prüfender Zielwert) (!Zwei Sekunden sind bereits gemessen) (!Der Mittelwert beweist den p95 Wert) (!Eine Skizze ersetzt den Lasttest)

Rückmeldung: Ein Zielwert wird erst durch einen dokumentierten Test mit festgelegter Messmethode überprüft.

Warum braucht ein Architekturentscheid eine Alternative? (Damit die Auswahl und ihre Folgen begründet werden können) (!Damit jedes Projekt Microservices verwenden muss) (!Damit die Dokumentation möglichst lang wird) (!Damit Risiken automatisch verschwinden)

Rückmeldung: Ein ADR macht den Abwägungsprozess und die verbleibenden Nachteile nachvollziehbar.

Memory

Ordne den Fachbegriffen ihre Bedeutung zu; jeder Begriff und jede Erklärung erscheint nur einmal.

Systemkontext	Außenbeziehungen und Systemgrenze
Bausteinsicht	Verantwortlichkeiten und Abhängigkeiten
Sequenzsicht	Zeitlicher Nachrichtenaustausch
Verteilungssicht	Zuordnung zu Laufzeitumgebungen
Schnittstellenvertrag	Vereinbarte Eingaben und Antworten
Architekturentscheid	Begründete Auswahl mit Folgen

Drag-and-Drop

Ordne jede Sicht ihrem Informationszweck zu.

Passende Darstellung	Informationszweck
Kontextdiagramm	Externe Nutzende und Systemgrenze
Komponentendiagramm	Module und ihre Beziehungen
Sequenzdiagramm	Anfragen und Antworten in zeitlicher Folge
Verteilungsdiagramm	Software auf technischen Laufzeitorten
Anforderungsmatrix	Verbindung von Ziel und Prüfnachweis

Kreuzworträtsel

Finde für jede Erklärung einen Fachbegriff aus den Kapiteln.

Kontext	Sicht mit der Systemgrenze und den Nachbarsystemen
Schnittstelle	Vertrag über Kommunikation zwischen Komponenten
Transaktion	Abgeschlossene Arbeitseinheit für konsistente Speicherung
Datenbank	Dauerhafter strukturierter Datenspeicher
Sequenz	Zeitliche Reihenfolge von Nachrichten
Autorisierung	Prüfung ob eine angemeldete Person etwas ausführen darf

LearningApps

Suche eine passende Zusatzübung; externe Angebote können sich ändern und wurden nicht als eigener Kursinhalt geprüft.

Lückentext

Die Sicht auf Außenstehende und Systemgrenze heißt

.

Die fachliche Doppelbelegungsregel prüft der

.

Ein Vertrag zwischen zwei Bausteinen heißt

.

Die zeitliche Reihenfolge von Nachrichten zeigt ein

.

Die Zuordnung von Software zu Laufzeitumgebungen zeigt die

.

Ein erfolgreich angelegter Eintrag liefert im Modell den Status

.

Bei einer Kollision liefert die modellierte API den Status

.

Eine abgeschlossene konsistente Speichereinheit heißt

.

Die Prüfung von Handlungsrechten heißt

.

Ein dokumentierter Architekturentscheid wird auch als

abgekürzt.

}

Offene Aufgaben

Bearbeite ausschließlich die erfundenen RaumPlan-Daten; reale Zugänge und produktive Infrastruktur sind ausgeschlossen.

Leicht

Systemgrenze: Zeichne für die erfundene Lernwerkstatt ein Kontextbild mit mindestens drei beteiligten Rollen und erkläre jeden Pfeil in einem Satz.
Anforderungen: Formuliere fünf prüfbare Anforderungen mit Kennung und messbarem oder beobachtbarem Kriterium.
Begriffe: Schreibe ein eigenes Glossar zu Komponente, Schnittstelle, Laufzeitsicht, Trust Boundary und Deployment mit je einem RaumPlan-Beispiel.
Datentabelle: Berechne aus 240 Einträgen pro Tag und 30 KiB je Eintrag den reinen Speicherbedarf für 90 Tage und kennzeichne fehlende Zuschläge.

Standard

Bausteindiagramm: Entwerfe fünf Komponenten und dokumentiere je Verantwortung, Eingang, Ausgang und typische Fehler.
API-Vertrag: Erstelle für POST /api/reservierungen einen Vertrag mit positiven und negativen Beispielantworten, fiktiven Testkennungen und Datentypen.
Ablaufmodell: Zeichne ein Sequenzdiagramm mit Normalfall und Konfliktfall einschließlich der transaktionalen Kollisionsprüfung.
Sicherheitsreview: Analysiere an einem erfundenen Zugriff einer unberechtigten Person mindestens vier Risiken und überprüfbare Gegenmaßnahmen.

Schwer

Variantenvergleich: Vergleiche modularen Monolithen und Microservices mit selbst begründeten Gewichtungen sowie Unsicherheiten, ohne echte Kundendaten.
Architekturentscheidung: Erstelle einen ADR mit Anlass, Entscheidung, zwei Alternativen, Kostenannahmen, Konsequenzen und Auslösern einer Neubewertung.
Reproduzierbarer Test: Entwerfe in einer ausschließlich freigegebenen Testumgebung unter Aufsicht einen Plan für konkurrierende Reservierungen und einen p95-Lasttest mit dokumentierten Messbedingungen.
Architekturdossier: Stelle einen vollständigen fiktiven Kurzbericht mit vier Diagrammsichten, Versionen, Rückverfolgbarkeitsmatrix und fünf begründeten Verbesserungsvorschlägen zusammen.

Lernkontrolle

Überprüfe Begründungen, Anwendung und Transfer, nicht nur auswendig gelernte Wörter.

Nachvollziehbarkeit: Erkläre an A-03 die Kette vom Nutzungswunsch über Baustein und Schnittstelle bis zum erwarteten Konflikttest; benenne die noch fehlenden Nachweise.
Perspektivwechsel: Erkläre dieselbe RaumPlan-Architektur einmal für eine Auftraggeberin und einmal für einen Systemadministrator; beurteile die nötigen Unterschiede.
Fehleranalyse: Eine neue Fassung legt die Kollisionsprüfung nur in JavaScript im Browser ab. Begründe fachlich, warum das nicht genügt, und skizziere die bessere Transaktion.
Mengengerüst: Berechne den fiktiven Speicherbedarf für 180 Tage und die monatliche Preisdifferenz des Modellvergleichs; unterscheide KiB, MiB und Euro.
Schnittstellenrevision: Ein mobiles Testgerät benötigt eine Buchungsübersicht. Erkläre, welche API-Vertrags- und Sicherheitsdetails du prüfen musst und welche Diagramme du aktualisierst.
Dokumentationsaudit: Bewerte ein Architekturdiagramm ohne Version, Pfeillegende und Fehlerpfad anhand einer eigenen Checkliste und formuliere drei konkrete Korrekturen.

Lernnachweis

Wissen: Du definierst Systemarchitektur, Anforderung, Baustein, API-Vertrag, Sequenz und Deployment in eigenen Worten.

Fertigkeiten: Du zeichnest vier beschriftete Sichten, erklärst mindestens drei Datenflüsse, berechnest Speicherbedarf mit Einheiten und leitest aus einer Anforderung einen Testfall ab.

Produkte: Versioniertes fiktives Architekturdossier mit Kontext- und Bausteindiagramm, Sequenz- und Verteilungsbild, ADR, Schnittstellentabelle, Quellenverzeichnis sowie Anforderungen-Test-Matrix.

Transfer: Du begründest, welche Inhalte die Fachrichtung Systemintegration statt Anwendungsentwicklung betonen würde und welche Teile der Lösung unabhängig davon gültig bleiben. Der Nachweis einer tatsächlich bestandenen Prüfung oder einer betrieblichen Freigabe ist damit nicht verbunden.

OER und Wikipedia

Amtliche Orientierung (abgerufen am 21.10.2026):

KMK-Rahmenlehrplan, Beschluss 13.12.2019 – berufsbezogene schulische Lernfelder, insbesondere 11a und 12a.
Fachinformatikerausbildungsverordnung vom 28.02.2020 – betriebliche Ausbildungsordnung mit Ausbildungsrahmenplan und Prüfungsbestimmungen; die jeweils geltende Fassung ist maßgeblich.
BIBB, Ausbildung gestalten: Fachinformatiker/Fachinformatikerin, 2020 – Umsetzungshilfe; keine amtliche Prüfungsaufgabe.
arc42, Hinweise zu sparsamer Architekturdokumentation – fachlicher Praxisbezug; Inhalte nicht kopiert.
Softwarearchitektur und Client-Server-Modell – frei zugängliche Überblicksartikel.

Geprüfte Mediennachweise und Nutzungsrechte: Die Abbildungen sind fremde allgemeine Beispiele, keine Bilder aus dem fiktiven Projekt. Die jeweiligen Lizenzbedingungen inklusive Namensnennung und gegebenenfalls ShareAlike sind bei einer Weiterverwendung zu beachten. Die lizenzierten Bilder wurden nicht verändert.

Datei oder Video	Geprüfte Originalquelle	Urheber / Kanal	Lizenz oder Rechtehinweis
File:3-Schichten-Architektur.svg	Wikimedia Commons	Dew1978	CC BY-SA 4.0
File:Component-3.png	Wikimedia Commons	Gubaer	GFDL 1.2 oder später
File:Sequence diagram.png	Wikimedia Commons	Dannyc20	CC BY-SA 3.0
File:Multidimensional software architecture contraction (MSAC).gif	Wikimedia Commons	Lora Gilyard	CC BY-SA 4.0
File:De-Computernetzwerk.ogg	Wikimedia Commons	Jeuwre	CC BY-SA 4.0
https://www.youtube.com/watch?v=s9zAZ96GQsk	YouTube: Was ist eine Softwarearchitektur?	ModelMyMind	Plattformvideo des Kanals; keine freie Weiterverwendung behauptet
https://www.youtube.com/watch?v=VsCYGYtZT0I	YouTube: UML-Klassendiagramme kurz erklärt	informatikZentrale	Plattformvideo des Kanals; keine freie Weiterverwendung behauptet