herzogflorian 4a1eeb4837 Auto-commit 2026-09-08 10:57: 6 files changed, 112 insertions(+)

2026-09-08 10:57:34 +02:00

26 KiB

Raw Permalink Blame History

Modulbeschreibung: AISE502 – AI in SE II

Feld	Wert
Autor/in	Herzog Florian
Ausgabestelle	Institute for Data Analysis, Artificial Intelligence, Visualization, and Simulation (DAViS)
Geltungsbereich	Departement
Klassifizierung	Nicht klassifiziert
Version	3.1.0
Ausgabedatum	8. September 2026 (Sitzungsplan an die ausgelieferten Vorlesungen 1–14 angeglichen)

Modul

Feld	Wert
Name	AI in Software Engineering II
Kürzel	AISE502
ECTS-Punkte	4
Typ	Pflichtmodul
Verantwortliche/r	Herzog Florian
Semester	5. Semester

Leitidee

Das Modul "AI in Software Engineering II" stellt das Software Engineering grosser, langlebiger Systeme in den Mittelpunkt. Sein roter Faden ist das englischsprachige Vorlesungsskript "A Theory of Architecture--Application Fit", das eine durchgängige, messbare Entscheidungstheorie der Softwarearchitektur entwickelt: Architektur wird verstanden als die Menge der signifikanten, schwer umkehrbaren Entscheidungen, die durch messbare Qualitätsattribute getrieben, durch systematischen Abgleich von Anforderungsprofilen (zehn Anwendungsklassen) und Fähigkeitsprofilen (sieben Architektur-Patterns) über zwölf gemeinsame Profildimensionen getroffen und über den gesamten Lebenszyklus empirisch überprüft werden (Fitness Functions, DORA-Metriken).

Die Leitfrage lautet: Wie entwerfe, begründe und betreibe ich die Struktur eines Software-Systems so, dass es seine Qualitätsattribute erfüllt und über Jahre wartbar bleibt -- auch dann, wenn einzelne Komponenten nicht-deterministisch, fehlbar und kostenintensiv sind?

Künstliche Intelligenz erscheint in zwei gleichwertigen, strikt getrennten Achsen:

Achse A -- AI als Werkzeug zum Bauen: Studierende setzen agentische Entwicklungswerkzeuge produktiv, aber kritisch-reflektiert ein -- auf Basis der empirischen Evidenz (randomisierte Studien mit positiven wie negativen Befunden) und mit Architektur-Dokumentation und Fitness Functions als Leitplanken.
Achse B -- AI als Komponente im System: Studierende entwerfen Architekturen, in denen LLM-, ML- und Optimierungskomponenten als Laufzeit-Bausteine wirken, und machen diese nicht-deterministischen Komponenten engineering-tauglich: gekapselt (Gateway, Ports), asynchron integriert, beobachtbar (Kosten, Latenz), getestet (Eval-Harness) und abgesichert (Ontologie-Guard, Prompt-Injection-Abwehr).

Die zentrale Erkenntnis des Moduls (Annahme A6 der Theorie): AI erweitert den Qualitätsattributraum, ändert aber die Methode nicht. Die Disziplin, die man zum Bauen mit AI braucht, ist dieselbe wie jene zum Einbetten von AI.

Didaktisches Prinzip: Das Modul arbeitet durchgängig induktiv -- Fallstudien und Beispiele zuerst, Verallgemeinerung danach. Jedes Pattern wird aus dem realen Problem entwickelt, das es hervorbrachte; jede Anwendungsklasse aus ihren realen Herausforderungen; das Matching-Verfahren aus drei durchgerechneten Fällen. Zu jedem Pattern gehören Open-Source-Frameworks zum Bauen und klonbare Open-Source-Referenzsysteme zum Inspizieren ("Build it and study it"). Ein durchgehendes Gruppenprojekt -- eine modulare, AI-gestützte Portfolio-Analyse-Plattform -- wendet den gesamten Bogen praktisch an.

Das Verhältnis von klassischem Software Engineering zu AI-spezifischen Techniken beträgt etwa 60 % zu 40 %.

Voraussetzungen

AI in Software Engineering I (AISE501)
Software Technik I und II
Maschinelles Lernen, Deep Learning
Mathematik-Grundlagen, Informatik-Grundlagen

Lernergebnisse

Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage:

Architektur als Entscheidungsproblem behandeln (Skript Teil I):
- Architektur als Menge schwer umkehrbarer, qualitätsgetriebener Entscheidungen verstehen (tragende Annahmen A1--A6) und Entscheidungen mit Rationale dokumentieren (Architecture Decision Records, C4-Sichten, ISO/IEC/IEEE 42010).
- Die zwölf Profildimensionen (ISO/IEC 25010:2023-verankert, je mit Antwortmass und Messinstrument) als gemeinsames Koordinatensystem von Anforderung und Fähigkeit anwenden.
Anforderungsprofile konstruieren (Teil I und III):
- Architektur-relevante Anforderungen elizitieren und als sechsteilige Qualitätsszenarien mit Antwortmass formulieren; Gewichte über Utility Trees ableiten.
- Anwendungsklassen als Anforderungsprofile R(a) charakterisieren: Gewichte, Workload-Shape und regulatorische Knock-out-Constraints (u. a. BCBS 239, FINMA 2023/1, PCI DSS, EU AI Act).
Fähigkeitsprofile herleiten und Architektur-Patterns beherrschen (Teil II):
- Die sieben Patterns (Schichtenarchitektur, modularer Monolith, Hexagonal, Microservices, Event-Driven, Pipes-and-Filters, Serverless) mit Topologie, realem Ursprungsproblem, Taktiken und dimensionsweisem Fähigkeitsprofil C(p) erklären.
- Pro Pattern Open-Source-Frameworks einsetzen und Referenzsysteme im Quellcode inspizieren; Engineering-Konsequenzen (Build, Test, CI/CD, Deployment, Betrieb, Teamstruktur) ableiten.
Passung berechnen, begründen und verteidigen (Teil IV):
- Das dreistufige, nicht-kompensatorische Matching-Verfahren anwenden (Knock-out und Workload-Shape-Gate, Veto auf hochgewichteten Dimensionen mit dokumentierten Mitigationen, ordinale Rangbildung mit Sensitivitätsanalyse) und die 7×10-Matrix als Explikations- statt Rechenmodell nutzen.
- Hybride als Normalfall erkennen (z. B. ACID-Kern mit Event-getriebenen Rändern) und Evolutionspfade planen (Strangler Fig, dokumentierte Rückbau-Fallstudien).
Entscheidungen messbar machen und betreiben (Teil IV):
- Jede Architekturentscheidung mit einem Messvertrag abschliessen: Fitness Functions in CI/CD (z. B. Modulgrenzen-Checks, Performance- und Token-Budgets), DORA-Metriken und Observability (Logging, Metriken, Tracing) im Betrieb.
AI als Werkzeug professionell und kritisch einsetzen (Achse A, Teil V):
- Die empirische Evidenz zu AI-Coding-Werkzeugen differenziert bewerten (u. a. Copilot-RCT, METR-Studie, DORA-Reports) und daraus Konsequenzen für Spezifikation, Verifikation und Architektur ziehen.
- Agentische Werkzeuge mit Architektur-Dokumentation als Kontext und Tests/Fitness Functions als Leitplanken einsetzen; Ausgaben kritisch bewerten und verantworten.
AI als Systemkomponente engineering-tauglich machen (Achse B, Teil V):
- LLM-, ML- und Optimierungskomponenten hinter stabilen Schnittstellen kapseln (Gateway, Anti-Corruption-Layer), asynchron integrieren, deterministische von nicht-deterministischen Systemteilen strikt trennen.
- Eigene Eval-Harnesses aufbauen (Golden Sets, LLM-as-Judge mit Kalibrierung, Domänen-Axiome) und als CI-Gate betreiben; Token-Kosten und Latenz messen und optimieren (Caching, Batching, Model-Routing).
- Multi-Agenten-Systeme als Komposition klassischer Topologien konzipieren (Chain/Router/Orchestrator/Multi-Agent) und deren Ökonomie bewerten.
Ethik und Verantwortung reflektieren:
- Gesellschaftliche, regulatorische (EU AI Act) und ethische Implikationen AI-gestützter Systeme im sensiblen Anwendungskontext (Finanzdaten) bewerten; neue Bedrohungsklassen (Prompt Injection, OWASP LLM Top 10) im Threat-Modeling berücksichtigen.

Leistungsnachweis

Anteil	Komponente
50 %	Praxisprojekt (modulare AI-gestützte Plattform, Gruppenarbeit) -- inklusive Requirements-Dossier (A1, Ende Woche 3), Architektur-Dossier mit ADR und Messvertrag (A2, Ende Woche 7), Implementierung sowie Abschlusspräsentation mit Architektur-Verteidigung (A3, Woche 14)
50 %	Schriftliche Modulschlussprüfung, 60 Minuten, open book (Skript und eigene Unterlagen in Papierform), closed internet -- Schwerpunkt: Architektur-Reasoning und Trade-off-Analyse entlang der Passungstheorie, keine reine Faktenabfrage

Nachprüfung

Gemäss Rahmenprüfungsordnung.

Unterrichtssprache

Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Folien, Übungen, Paper) in Englisch.

Eingangskompetenzen

Sicherer Umgang mit Python, Versionsverwaltung (Git) und grundlegenden Software-Engineering- Prinzipien (Clean Code, SOLID). Grundverständnis von LLMs, Prompting und RAG aus AISE501. Grundlagen in Statistik und maschinellem Lernen.

Aufbau des Semesters

Der Kurs umfasst 14 Sitzungen zu je 4 Lektionen. Der rote Faden ist das Vorlesungsskript "A Theory of Architecture--Application Fit" (Teile I--V); jede Sitzung verbindet einen Skript-Abschnitt mit einer AI-Linse und einem Projektschritt. Der Semesterplan folgt einer Zwei-Phasen-Logik, die Vorlesung und Projekt eng koppelt:

Phase	Wochen	Aufteilung	Logik
Designphase	1--7	2 L Vorlesung + 2 L Übung	Die Übung erarbeitet Requirements → Architekturstudium → Architekturentscheid → Lösungsdesign. Die Vorlesung liefert just-in-time genau das Handwerkszeug, das die Übung in derselben oder der Folgewoche braucht.
Implementierungsphase	8--13	3 L Vorlesung + 1 L Übung (Standup/Coaching)	Die Implementierung läuft primär im Selbststudium. Die Vorlesung holt die nicht design-blockierenden Inhalte nach (Anwendungsklassen-Katalog, Messvertrag-Vertiefung, AI-Dimension) -- jeweils in der Woche, in der das Projekt sie braucht.
Abschluss	14	1 L Synthese + 3 L Präsentationen	Synthese, Grenzen der Theorie und Prüfungsorientierung; danach Abschlusspräsentationen, Architektur-Verteidigung und Peer-Reviews.

Kernprinzip der Abstimmung: Alles, was die Übung zum Entwerfen braucht -- die R(a)-Methode, die sieben Patterns, das dreistufige Matching-Verfahren --, ist bis Ende Woche 7 gelesen. Alles, was nicht design-blockierend ist (die Klassen C1--C9, Hybride und Evolutionspfade, die AI-Dimension), liegt in der Implementierungsphase, wo es inhaltlich passt: die Gateway- und Eval-Harness-Vorlesung genau dann, wenn Gateway und Agenten gebaut werden.

Meilensteine und Abgaben

Meilenstein	Wochen	Abgabe / Check
M1 Requirements und Ontologie	1--3	A1 Requirements-Dossier (Ende Woche 3): Qualitätsszenarien mit Antwortmass, Utility Tree, R(Plattform)
M2 Architekturentscheid und Lösungsdesign	4--7	A2 Architektur-Dossier (Ende Woche 7): ADR mit Rationale, C4-Sichten, Messvertrag -- plus Design-Review-Gate; Produktivcode beginnt erst nach dem Gate
M3 Walking Skeleton	8--9	Check Woche 9: dünner End-to-End-Schnitt läuft
M4 Deterministischer Kern und Resilienz	10--11	Check Ende Woche 11: Kern vollständig gegen Referenzvektoren getestet, Resilienz auf allen externen Aufrufen
M5 Multi-Agent-Orchestrierung, Evaluation, Hardening	12--13	Check Ende Woche 13: Eval-Harness als CI-Gate, Ontologie-Guard aktiv, Kosten-Observability
M6 Präsentation und Architektur-Verteidigung	14	A3 Abschlusspräsentation mit Architektur-Verteidigung und Peer-Reviews

Inhalte

1. Das Entscheidungsproblem und das Framework (Skript Teil I, §1--2)

Inhalte: Vier Produktionssysteme, zwei Fakten (Stack Overflow, Monzo, Segment, Prime Video); Architektur als schwer umkehrbare, qualitätsgetriebene Entscheidungen; die fünf Framework-Elemente (R(a), C(p), fit, ADR, Messvertrag); die tragenden Annahmen A1--A6; von Alltagsfragen zu den zwölf Dimensionen (Überblick der fünf Gruppen).
Praktische Anwendung: Projekt-Kickoff (Teams, Repository und Werkzeug-Setup inkl. agentischer Entwicklungswerkzeuge, Domänenverständnis, erste Ontologie-Skizze, rohe Stakeholder-Wünsche); ein Agent erstellt ADR-Entwürfe -- der Mensch entscheidet und verantwortet (Achse A).

2. Das Koordinatensystem: zwölf Profildimensionen und messbare Anforderungen (Teil I, §2--3)

Inhalte: Die zwölf Dimensionen einzeln motiviert, je mit Antwortmass und Messinstrument (Last, Korrektheit/Vertrauen, Wandel/Delivery, Ökonomie/Organisation, AI-Integrierbarkeit); ISO/IEC 25010:2023 als Vokabular; architektur-relevante Anforderungen (ASR), Quality Attribute Workshop, sechsteilige Qualitätsszenarien, Utility Tree → Gewichte; R(a) aus Gewichten, Workload-Shape und Knock-out-Constraints.
Praktische Anwendung: Requirements-Workshop I -- Qualitätsszenarien mit Antwortmass für die Projektplattform (mindestens acht, davon drei für die AI-Komponenten), Utility Tree beginnen.

3. Nachfrage, Angebot, Passung: das formale Modell (Teil I, §4--6)

Inhalte: Herleitung von C(p) über Taktiken (Pattern vs. Taktik, Evidenzbasis); das dreistufige, nicht-kompensatorische Matching-Verfahren am Mini-Match des Kursprojekts (C10 gegen L, MM und MS); warum keine gewichtete Summe (MCDM-Kritik); ADR/MADR und der Messvertrag als Abschluss jeder Entscheidung.
Praktische Anwendung: Requirements-Workshop II -- R(Plattform) finalisieren (Gewichte, Workload-Shape, Knock-out-Constraints), Ontologie als Vertrag fixieren. Abgabe A1: Requirements-Dossier (Ende Woche 3).

4. Patterns I: ein Deployable (Teil II, §8--10)

Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters -- je: reales Ursprungsproblem, Topologie, Architecture Quantum, dimensionsweises Fähigkeitsprofil, Engineering-Konsequenzen, Anti-Patterns; Modulgrenzen als CI-Gegenstand (Spring Modulith, import-linter, ArchUnit, Packwerk).
Praktische Anwendung: "Build it and study it" -- healthchecks (Django), Apache Fineract und das Cosmic-Python-Repo klonen und die Architektur im Code nachweisen; Architekturstudium I für die Plattform, C4-Kontext- und Container-Entwurf; AI-Linse: der LLM-Provider hinter einem Port.

5. Patterns II: verteilte Topologien (Teil II, §11--12)

Inhalte: Microservices und Event-Driven Architecture -- Ursprungsprobleme (Release-Zug, Ingest), Fähigkeitsprofile, Sagas vs. ACID, der verteilte Monolith als häufigster Fehlausgang, Broker- vs. Mediator-Topologie, Schema-Governance, die sieben Resilienz-Grundmuster (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback, Dead-Letter Queue, idempotenter Consumer); Fallstudien (Netflix, Uber DOMA, Monzo, Segment-Rückbau).
Praktische Anwendung: Online Boutique und der Home-Assistant-EventBus im Quellcode; Architekturstudium II -- Ränder entwerfen (Ingestion-Queue, Resilienz gegen API-Ausfall), Service-Kontrakte skizzieren, Matrix-Vorfilter der Kandidaten; AI-Linse: ein LLM-Aufruf als unzuverlässiger Remote-Call, Queues als Puffer (D12).

6. Patterns III: Batch und Serverless, die Verallgemeinerung -- und die eigene Klasse C10 (Teil II, §13--17; Teil III, §28)

Inhalte: Pipes-and-Filters/Batch und Serverless/FaaS; die Verallgemeinerung: Architecture Quantum, "Partitioning beats distribution", Evidenzbasis und die konsolidierte Fähigkeitstabelle als Vergleichssicht; Agenten-Orchestrierung als emergentes Kompositionsmuster (Ausblick); danach C10 -- AI-native Advisory-Plattformen, die Klasse des Kursprojekts, mit dem Spiegelpaar C1/C2 als Kurzvorschau.
Praktische Anwendung: dbt-Pipeline (jaffle_shop_duckdb) lokal bauen und den Knative-Bookstore inspizieren; der Match: das dreistufige Verfahren für die eigene Plattform durchführen (Knock-out → Veto → ordinale Lesung), Entscheid fällen, ADR beginnen.

7. Die Passung, formal: drei Fälle, das Verfahren, die Matrix (Teil IV, §30--32, 34; §37 Einführung)

Inhalte: Drei durchgerechnete Matches (C6: das Shape-Gate leert sechs von sieben Zellen; C1: Veto und dokumentierte Mitigationen; C2: ordinale Lesung mit Sensitivitätsanalyse und Tradeoff-Point); das Verfahren im Allgemeinen und was eine gewichtete Summe zerstört hätte; Zellsemantik und Lesart der 7×10-Matrix (Spalten, Zeilen, fünf Stützpunkte); Einführung des Messvertrags (Fitness Functions, vier DORA-Metriken).
Praktische Anwendung: Lösungsdesign finalisieren -- Service-Schnitt und Kontrakte, Walking-Skeleton-Plan, Messvertrag mit Zahlen (Token-Budget, Eval-Schwelle ≥ 95 %, p95-Latenz ≤ 20 s, null Modulgrenzen-Verletzungen); Design-Review-Gate mit Verteidigung des ADR. Abgabe A2: Architektur-Dossier (Ende Woche 7).

8. Anforderungsprofile I: Anwendungsklassen C1--C5 (Teil III, §18--23)

Inhalte: Anwendungsklassen als ASR-Bündel, nicht als Branchenlabel; C1 Kernbanking, C2 Social/Content, C3 Back-Office, C4 ERP, C5 E-Commerce -- je: reale Herausforderungen mit Zahlen und Regulatorik, Anforderungsprofil über die zwölf Dimensionen, und welche Architektur reale Systeme wählten und warum (LMAX vs. Monzo, Instagram, Shopify, Fineract).
Praktische Anwendung: Sprint 1 -- Beginn des Walking Skeleton (MarketDataService, minimaler ResearchAgent, stabile API); AI-Linse: die Latenzklasse, nicht die Genauigkeit, entscheidet über die Platzierung einer AI-Komponente.

9. Anforderungsprofile II: C6--C9 und zehn Profile nebeneinander (Teil III, §24--27, 29)

Inhalte: C6 Simulation/Batch, C7 DSS/BI, C8 IoT-Streaming, C9 Collaboration/Messaging; die dritte Konsistenzsemantik (Reproduzierbarkeit, Freshness-Kontrakt); Verallgemeinerung: zehn Profile nebeneinander mit ihren Fussnoten und fünf klassenübergreifenden Beobachtungen (u. a.: D11 High, nicht Skalierung, erzwingt Microservices).
Praktische Anwendung: Coaching; Walking Skeleton fertigstellen -- Check Woche 9: läuft End-to-End; das Projekt erbt C6 (Ingestion- und Eval-Pipelines) und C7 (Analytik).

10. Hybride, Evolution und das achtstufige Entscheidungsverfahren (Teil IV, §35--36, 33)

Inhalte: Hybride als Normalfall und die Bewertungseinheit Subsystem; Fit als Funktion der Zeit (Lehman, Annahme A5), Migrationsstrategien (MonolithFirst, Strangler Fig in beide Richtungen, Sacrificial Architecture; Fallstudien Segment, Prime Video, Shopify); das achtstufige Entscheidungsverfahren von den ASRs bis zum Messvertrag, durchgespielt an ADR-007; die Zeilen-Begründungen der Matrix im Detail.
Praktische Anwendung: Coaching; deterministische Services (Performance, Risk, Optimization) mit exakten Tests gegen die Referenzvektoren; AI-Linse: die AI-Schicht als bewusst ersetzbare Sacrificial Architecture hinter einem Port.

11. Der Messvertrag, Conway's Law und die Grenzen der Theorie (Teil IV, §37--39)

Inhalte: Fitness Functions (atomar/holistisch, triggered/continual/temporal) in CI/CD und ihre drei Instrumentenfamilien; die vier DORA-Metriken und der Kopplungs-Befund; die vierstufige Kaskade und der C10-Referenzvertrag; Kostenverlauf von Änderungen (Boehm vs. Menzies); Conway's Law und Team Topologies als dritte Passungsdimension; sechs Grenzen der Theorie, auf sich selbst angewandt.
Praktische Anwendung: Coaching; Resilienz auf allen externen Aufrufen (Timeout, Retry, Circuit-Breaker, Fallback) und verifizierte Graceful Degradation -- Check Ende Woche 11; der Messvertrag der eigenen Abgabe wird in CI verdrahtet.

12. Die AI-Dimension I: Achse A -- Evidenz und Konsequenzen; Achse B -- Grundlagen (Teil V, §40--41, §42.1--42.5)

Inhalte: Zwei widersprüchliche randomisierte Experimente (Copilot-RCT +55.8 % vs. METR −19 % inklusive Wahrnehmungslücke) und ihre Auflösung über fünf Moderatorvariablen; der Verifikations-Engpass; ADRs und Agenten-Instruktionsdateien als Kontrollschnittstelle, Fitness Functions als Betriebslizenz für Agenten; danach Achse B: der Sentiment-Call falsch und richtig verdrahtet, drei Komponententypen (LLM, ML, Solver), die LLM-Gateway-Referenzarchitektur (Port, Routing, Caching, Budgets, Fallbacks, Ontologie-Guard) und die Grundlagen des Eval-Harness.
Praktische Anwendung: Coaching; AdvisorAgent mit 2--3 Sub-Agenten hinter dem Gateway (Pflichtteil), Ontologie-Guard auf allen Insights aktiv; Achse-A-Arbeitsregeln im Team (Agenten-Instruktionsdatei, signierte ADRs, CI-Gate, AI-Policy).

13. Die AI-Dimension II: Bedrohungen, verschobene Matrix, Orchestrierung -- und Synthese (Teil V, §42.6--42.7, 43--45)

Inhalte: OWASP LLM Top 10 und Prompt Injection als Architektur-, nicht Modellproblem; EU AI Act als Knock-out-Constraint in R(a); wie AI die Matrix verschiebt (D12-Mechanik, fünf Zellverschiebungen, MLOps-Reifegrade); Agenten-Orchestrierung als achtes, emergentes Kompositionsmuster (sechs Topologien, Task-Signatur-Tabelle, Ökonomie der Autonomie); Synthese der Theorie und Prüfungsorientierung.
Praktische Anwendung: Coaching; Eval-Harness als CI-Gate, Kosten- und Latenz-Dashboard, Threat-Model inklusive Prompt Injection über News, Hardening, Topologie-ADR; Kür: autonomes Planning, Self-Repair-Loops, Model-Routing. Check Ende Woche 13.

14. Synthese, Präsentation und Architektur-Verteidigung

Inhalte (1 Lektion, kein neuer Stoff): das Skript rückwärts als ein Argument gelesen; die Theorie-Pipeline in einem Satz; eine Disziplin an zwei Bindungsstellen (Achse A und B); Prüfungsorientierung und Q&A.
Praktische Anwendung (3 Lektionen): Abschlusspräsentationen, Architektur-Verteidigung der eigenen Trade-offs, Reflexion (wo half und wo schadete AI -- im Bauen und im System) sowie Peer-Reviews. Abgabe A3 / Meilenstein M6.

Praxisprojekt: AI-Augmented Portfolio Intelligence Platform

Als durchgehendes Gruppenprojekt entwickeln die Studierenden eine modulare Analyse- und Advisory-Plattform für Aktienportfolios (kein Trading, kein echtes Geld -- ausschliesslich Analyse und Empfehlung). Die Plattform ist im Skript als zehnte Anwendungsklasse (C10) durchmodelliert; das im Modul berechnete Verdikt lautet hexagonaler modularer Monolith als deterministischer Kern, Event-getriebene Ränder, Pipelines für Ingestion und Evaluation, orchestrierter Advisor-Agent hinter einem LLM-Gateway. Ob die Services als ein Deployable oder als mehrere ausgeliefert werden, ist nicht vorgegeben, sondern die Architekturentscheidung, welche die Teams in Woche 6 mit dem dreistufigen Verfahren treffen und in Woche 14 verteidigen. Die Plattform:

bezieht strukturierte externe Daten (Börsenkurse, z. B. via Yahoo Finance) -- mit Live-API und verpflichtendem Cache-/Snapshot-Fallback;
bezieht unstrukturierte externe Daten (Firmen-News) und wandelt sie über eine AI-Komponente in strukturierte, gegen die Ontologie validierte Insights um;
berechnet Risiko-, Performance- und Portfolio-Optimierungs-Kennzahlen (Formeln und Testvektoren werden vorgegeben; die Lernleistung ist das Engineering darum herum);
stellt die Funktionalität API-first bereit, mit dünnem Dashboard zur Demonstration.

Zentrale Architekturregel: Agents propose; deterministic services decide and book. Die AI-Agenten beziehen und interpretieren quantitative Werte ausschliesslich über die deterministischen Services -- sie berechnen nie selbst. Diese Trennung ist die prüfbare Manifestation von "AI engineering-tauglich machen" und wird bewertet.

Abstufung Pflicht / Kür:

Pflicht (bestehensrelevant): aus der Ontologie abgeleitete Architektur mit ADRs und C4-Sicht; vollständig und exakt getestete deterministische Services; orchestrierter Advisor-Agent mit 2--3 Sub-Agenten, die nur über Service-Kontrakte kooperieren; Ontologie-Guard auf allen AI-Insights; Resilienz gegen Ausfall externer Datenquellen; Eval-Harness für die AI-Komponente; Kosten- und Latenz-Observability über das einzige LLM-Gateway; der Messvertrag aus A2 (Modulgrenzen-Check, Eval-Schwelle, Token-Budget) in CI verdrahtet.
Kür (für Spitzennoten): autonomes Planning (der Advisor entscheidet selbst über Sub-Agent- und Tool-Aufrufe), Self-Repair-Loops, Model-Routing, Deployment mit CI/CD und Tracing.

Bewertungsschwerpunkte: Architektur und Trade-offs (Schnitt, Kontrakte, Trennung deterministisch/nicht-deterministisch, ADRs), Robustheit (Resilienz, Guards, Graceful Degradation), Qualität (Tests der deterministischen Services, Eval-Harness), AI-Integration (Anti-Corruption-Layer, Ontologie-Guard), Betrieb (Observability von Kosten und Latenz).

Unterlagen und Lernumgebung

Vorlesungsskript A Theory of Architecture--Application Fit (Teile I--V, 45 Abschnitte) -- Leitmedium, Prüfungsgrundlage und Lektüre vor jeder Sitzung; wird während des Semesters entlang der Vorlesung korrigiert und ergänzt (die jeweils aktuelle Fassung liegt auf Moodle).
Foliensätze der 14 Vorlesungen sowie ein eigener Foliensatz zur Projekteinführung.
Aufgabenblatt zum Praxisprojekt (normative Quelle für Anforderungen, Meilensteine und Bewertung) inklusive UI-Skizzen der sechs Bildschirme.
Moodle-Kursraum mit einem Abschnitt pro Woche (Lernziele, Theorie, Selbststudium und Aufgaben), einem Abschnitt zum Skript und einem Abschnitt zum Praxisprojekt.

Lehr- und Lernmethoden

Lehrtechniken: Vorlesungen, Übungen, Gruppenarbeit, Online-Lehre, Workshops.

Lernaktivitäten: Studium des Skripts und der Literatur, Inspektion realer Open-Source-Systeme, Übungsaufgaben, Bearbeiten von Problemen und deren Lösungsfindung, Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium.

Lehrmethode: Präsentation; Einzel-, Partner- und Gruppenarbeit; E-Learning.

Struktur

Element	Stunden
Online-, Hybrid- oder Präsenzunterricht	42 h
Selbststudium (Skript, Lektüre und Projekt)	78 h
Total	120 h (4 ECTS)

Literatur

Leitmedium (roter Faden):

AISE502 Lecture Notes -- A Theory of Architecture--Application Fit, F. Herzog, Fachhochschule Graubünden, 2026 (englisch; wird abgegeben).

Die vier methodischen Hauptquellen der Theorie (im Skript gewürdigt):

L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, 4. Aufl., Addison-Wesley/SEI, 2021 (Qualitätsszenarien, Taktiken, Utility Tree/ATAM).
M. Richards, N. Ford: Fundamentals of Software Architecture -- A Modern Engineering Approach, 2. Aufl., O'Reilly, 2025 (Architecture Characteristics, Trade-off-Gesetze).
N. Ford, R. Parsons, P. Kua, P. Sadalage: Building Evolutionary Architectures, 2. Aufl., O'Reilly, 2022 (Fitness Functions, Messvertrag).
N. Forsgren, J. Humble, G. Kim: Accelerate -- The Science of Lean Software and DevOps, IT Revolution, 2018 (DORA-Metriken, Kopplungs-Befund).

Begleitend:

I. Sommerville: Modernes Software-Engineering, Pearson, 2020 (deutschsprachiger Anker).
S. Newman: Building Microservices, 2. Aufl., O'Reilly, 2021 (nach Bedarf als Reader).
ISO/IEC 25010:2023 (Qualitätsvokabular) und ISO/IEC/IEEE 42010:2022 (Architekturbeschreibung).
Aktuelle wissenschaftliche Artikel und Branchenforschung zu AI-Agenten, agentischen Entwicklungswerkzeugen und Evaluation von AI-Systemen (u. a. DORA-Reports, METR, Anthropic Engineering).

26 KiB Raw Permalink Blame History Unescape Escape