From 9fc72de9ed85e293d720a77ca2925c8bb012806b Mon Sep 17 00:00:00 2001 From: herzogflorian Date: Tue, 8 Sep 2026 10:25:39 +0200 Subject: [PATCH] Auto-commit 2026-09-08 10:25: 4 files changed, 190 insertions(+), 64 deletions(-) --- Modulbeschreibung_AISE502_v2_2026.md | 2 +- Modulbeschreibung_AISE502_v3_2026.md | 9 +- ...eschreibung_AISE502_v3_2026_confluence.txt | 146 +++++++++++------- tools/md2confluence.py | 97 ++++++++++++ 4 files changed, 190 insertions(+), 64 deletions(-) create mode 100644 tools/md2confluence.py diff --git a/Modulbeschreibung_AISE502_v2_2026.md b/Modulbeschreibung_AISE502_v2_2026.md index 710f022..4382fa3 100644 --- a/Modulbeschreibung_AISE502_v2_2026.md +++ b/Modulbeschreibung_AISE502_v2_2026.md @@ -348,7 +348,7 @@ Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium. ## Struktur -| | | +| Element | Stunden | |---|---| | Online-, Hybrid- oder Präsenzunterricht | 42 h | | Selbststudium (Skript, Lektüre und Projekt) | 78 h | diff --git a/Modulbeschreibung_AISE502_v3_2026.md b/Modulbeschreibung_AISE502_v3_2026.md index 4be21e2..3fcb6f1 100644 --- a/Modulbeschreibung_AISE502_v3_2026.md +++ b/Modulbeschreibung_AISE502_v3_2026.md @@ -209,7 +209,7 @@ die Gateway- und Eval-Harness-Vorlesung genau dann, wenn Gateway und Agenten geb - 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. Angebot, Passung und Entscheidungsprotokoll** *(Teil I, §4--6)* +**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 @@ -298,7 +298,8 @@ die Gateway- und Eval-Harness-Vorlesung genau dann, wenn Gateway und Agenten geb Circuit-Breaker, Fallback) und verifizierte Graceful Degradation -- **Check Ende Woche 11**; der Messvertrag der eigenen Abgabe wird in CI verdrahtet. -**12. Achse A: Evidenz und Konsequenzen -- Achse B: Grundlagen** *(Teil V, §40--41, §42.1--42.5)* +**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, @@ -310,7 +311,7 @@ die Gateway- und Eval-Harness-Vorlesung genau dann, wenn Gateway und Agenten geb (Pflichtteil), Ontologie-Guard auf allen Insights aktiv; Achse-A-Arbeitsregeln im Team (Agenten-Instruktionsdatei, signierte ADRs, CI-Gate, AI-Policy). -**13. Achse B: Bedrohungen, verschobene Matrix, Agenten-Orchestrierung -- und Synthese** +**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, @@ -400,7 +401,7 @@ Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium. ## Struktur -| | | +| Element | Stunden | |---|---| | Online-, Hybrid- oder Präsenzunterricht | 42 h | | Selbststudium (Skript, Lektüre und Projekt) | 78 h | diff --git a/Modulbeschreibung_AISE502_v3_2026_confluence.txt b/Modulbeschreibung_AISE502_v3_2026_confluence.txt index d2083cc..f1d3783 100644 --- a/Modulbeschreibung_AISE502_v3_2026_confluence.txt +++ b/Modulbeschreibung_AISE502_v3_2026_confluence.txt @@ -5,8 +5,8 @@ h1. Modulbeschreibung: AISE502 – AI in SE II |*Ausgabestelle*|Institute for Data Analysis, Artificial Intelligence, Visualization, and Simulation (DAViS)| |*Geltungsbereich*|Departement| |*Klassifizierung*|Nicht klassifiziert| -|*Version*|3.0.0| -|*Ausgabedatum*|2026 (Neufassung entlang des Vorlesungsskripts)| +|*Version*|3.1.0| +|*Ausgabedatum*|8. September 2026 (Sitzungsplan an die ausgelieferten Vorlesungen 1–14 angeglichen)| ---- @@ -22,7 +22,7 @@ h2. Modul h3. 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). +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?_ @@ -33,7 +33,7 @@ Künstliche Intelligenz erscheint in *zwei gleichwertigen, strikt getrennten Ach 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 verteilte, AI-gestützte Portfolio-Analyse-Plattform – wendet den gesamten Bogen praktisch an. +*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 %*. @@ -75,7 +75,7 @@ Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage: h3. Leistungsnachweis ||Anteil||Komponente|| -|50 %|Praxisprojekt (verteilte AI-gestützte Plattform, Gruppenarbeit) – inklusive Requirements-Dossier (A1), Architektur-Dossier mit ADR und Messvertrag (A2), Implementierung sowie Abschlusspräsentation mit Architektur-Verteidigung| +|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| h3. Nachprüfung @@ -84,81 +84,111 @@ Gemäss Rahmenprüfungsordnung. h3. Unterrichtssprache -Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Übungen, Paper) in Englisch. +Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Folien, Übungen, Paper) in Englisch. h3. 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. +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. + +---- + +h2. 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. + +h3. 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| ---- h2. Inhalte -Der Kurs umfasst 14 Sitzungen. 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. Didaktik durchgängig induktiv: Fallstudien und Beispiele vor der Verallgemeinerung. - -# *Das Entscheidungsproblem und das Framework* _(Skript Teil I)_ -#* Inhalte: Vier Produktionssysteme, eine Lektion (LMAX, Monzo, Stack Overflow, Prime Video); Architektur als schwer umkehrbare Entscheidungen; die fünf Framework-Elemente (R(a), C(p), fit, ADR, Messvertrag); die tragenden Annahmen A1–A6; ADR/MADR und C4. -#* Praktische Anwendung: Projektstart (Domäne, Vision, Werkzeug-Setup); ein Agent erstellt ADR-Entwürfe – der Mensch entscheidet und verantwortet (Achse A). -# *Das Koordinatensystem: zwölf Profildimensionen* _(Teil I)_ -#* Inhalte: Von Alltagsfragen zu messbaren Dimensionen; die zwölf Dimensionen einzeln motiviert (Last, Korrektheit/Vertrauen, Wandel/Delivery, Ökonomie/Organisation, AI); ISO/IEC 25010:2023 als Vokabular; Antwortmasse und Messinstrumente. -#* Praktische Anwendung: Dimensionsprofil einer täglich genutzten App erstellen und diskutieren; erste Qualitätsszenarien für die Projektplattform formulieren. -# *Nachfrage, Angebot, Passung: das formale Modell* _(Teil I)_ -#* Inhalte: Konstruktion von R(a) (ASR → Szenarien → Utility Tree → Gewichte; Workload-Shape; Knock-out-Constraints); Herleitung von C(p) über Taktiken; das dreistufige Matching-Verfahren am Mini-Match des Kursprojekts (C10 gegen drei Kandidaten); warum keine gewichtete Summe (MCDM-Kritik). -#* Praktische Anwendung: R(Projektplattform) im Team konstruieren und als Utility Tree begründen; Qualitätsszenarien mit Antwortmass fixieren. -# *Patterns I: Ein Deployable* _(Teil II)_ -#* Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters – je: reales Ursprungsproblem, Topologie, dimensionsweises Fähigkeitsprofil, Engineering-Konsequenzen, Anti-Patterns; Modulgrenzen als CI-Gegenstand (Spring Modulith, import-linter, ArchUnit). -#* Praktische Anwendung: "Build it and study it" – healthchecks (Django), Apache Fineract und das Cosmic-Python-Repo klonen und die Architektur im Code nachweisen; AI-Linse: der LLM-Provider hinter einem Port. -# *Patterns II: Verteilte Topologien* _(Teil II)_ -#* Inhalte: Microservices und Event-Driven Architecture – Ursprungsprobleme (Release-Zug, Ingest), Profile, Sagas vs. ACID, Resilienz-Grundmuster (Timeout, Retry, Circuit-Breaker), Schema-Governance; dokumentierte Fallstudien (Netflix, Uber DOMA, Segment-Rückbau). -#* Praktische Anwendung: Online Boutique (Kubernetes) und der Home-Assistant-EventBus im Quellcode; AI-Linse: ein LLM-Aufruf als unzuverlässiger Remote-Call. -# *Patterns III: Batch und Serverless; Verallgemeinerung* _(Teil II)_ -#* Inhalte: Pipes-and-Filters/Batch und Serverless/FaaS; danach die Verallgemeinerung: Architecture Quantum, "Partitioning beats distribution", Evidenzbasis (Sterne-Ratings) und die konsolidierte Fähigkeitstabelle als Vergleichssicht. -#* Praktische Anwendung: dbt-Pipeline (jaffle_shop_duckdb) lokal bauen; Knative-Bookstore inspizieren; Projekt: Bounded Contexts aus der Ontologie ableiten (Vertiefung AISE501). -# *Anwendungsklassen I: Transaktion, Content, Verwaltung* _(Teil III)_ -#* Inhalte: 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, Odoo/Fineract). -#* Praktische Anwendung: Walking Skeleton des Projekts – deterministische Services und ein minimaler Agent laufen End-to-End. -# *Anwendungsklassen II: Daten, Echtzeit, AI-nativ* _(Teil III)_ -#* Inhalte: C6 Simulation/Batch, C7 DSS/BI, C8 IoT-Streaming, C9 Collaboration/Messaging, C10 AI-native Advisory-Plattform (das Kursprojekt als zehnte Klasse); Verallgemeinerung: zehn Profile nebeneinander, Spiegelpaare, Übergabe an das Matching. -#* Praktische Anwendung: Anforderungsprofil des Projekts gegen C10 abgleichen; Resilienz gegen Ausfall externer Datenquellen einbauen. -# *Die Passung: drei Fälle, drei Stufen, die Matrix* _(Teil IV)_ -#* Inhalte: Drei durchgerechnete Matches (C6: Shape-Gate; C1: Veto und Mitigationen; C2: ordinale Rangbildung und Tradeoff-Points); das Verfahren im Allgemeinen; die 7×10-Matrix mit Zeilen-Begründungen. -#* Praktische Anwendung: Matching der eigenen Plattform-Architektur nachvollziehen und als ADR mit Rationale dokumentieren (Pflicht-Artefakt). -# *Hybride, Evolution und das achtstufige Entscheidungsverfahren* _(Teil IV)_ -#* Inhalte: Hybride als Normalfall; Evolutionspfade und Migrationsstrategien (Strangler Fig; Fallstudien Segment, Prime Video, Shopify); das achtstufige Entscheidungsverfahren von den ASRs bis zum Messvertrag, durchgespielt am Kursprojekt (ADR-007). -#* Praktische Anwendung: Orchestrierter Multi-Agent (2–3 Sub-Agenten über klare Kontrakte) – Pflichtteil des Projekts. -# *Der Messvertrag: Fitness Functions, DORA, Betrieb* _(Teil IV)_ -#* Inhalte: Fitness Functions (atomar/holistisch, triggered/continual) in CI/CD; die vier DORA-Metriken und der Kopplungs-Befund; Observability; Kostenverlauf von Architekturänderungen (Boehm vs. Menzies); Conway's Law und Team Topologies als dritte Passungsdimension. -#* Praktische Anwendung: CI/CD-Pipeline mit Architektur-Fitness-Functions (Modulgrenzen, Budgets) und Observability für Kosten und Latenz aufsetzen. -# *Achse A: AI als Werkzeug – Evidenz und Konsequenzen* _(Teil V)_ -#* Inhalte: Zwei widersprüchliche Experimente (Copilot-RCT +55.8 % vs. METR −19 % inkl. Wahrnehmungslücke) und ihre Auflösung; der Verifikations-Engpass; Architektur-Dokumente als Agenten-Kontext; Guardrails als Voraussetzung; Werkzeuglandschaft und Risiken. -#* Praktische Anwendung: Ein Agent generiert Tests/Refactorings gegen die eigene Codebasis; Studierende bewerten Abdeckung, Qualität und Review-Last. -# *Achse B: AI als Komponente – Kapselung, Evaluation, Orchestrierung* _(Teil V)_ -#* Inhalte: Der Sentiment-Call falsch und richtig verdrahtet; drei Komponententypen (LLM, ML, Solver); LLM-Gateway-Referenzarchitektur (Routing, Caching, Budgets, Fallbacks); Eval-Harness (Golden Sets, LLM-as-Judge, Domänen-Axiome) als CI-Gate; Prompt Injection und EU AI Act; Agenten-Orchestrierung als emergentes Kompositionsmuster und ihre Ökonomie. -#* Praktische Anwendung: Eval-Harness gegen Domänenregeln aufbauen (Pflicht); Ontologie-Guard und Kosten-Dashboard; Kür: autonomes Planning, Self-Repair-Loops, Model-Routing. -# *Synthese, Präsentation und Architektur-Kritik* -#* Inhalte: Die Theorie-Pipeline in einem Satz; Grenzen der Theorie (auf sich selbst angewandt); Trade-offs verteidigen; Reflexion: Wo half und wo schadete AI – im Bauen (Achse A) und im System (Achse B)? -#* Praktische Anwendung: Präsentationen, Architektur-Verteidigung und Peer-Reviews der Abschlussprojekte. +# *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). +# *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. +# *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).* +# *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. +# *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). +# *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. +# *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).* +# *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. +# *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). +# *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. +# *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. +# *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). +# *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.* +# *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.* ---- h2. Praxisprojekt: AI-Augmented Portfolio Intelligence Platform -Als durchgehendes Gruppenprojekt entwickeln die Studierenden eine verteilte 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; ihre Architektur folgt dem im Modul berechneten Verdikt: *hexagonaler modularer Monolith als deterministischer Kern, Event-getriebene Ränder, Pipelines für Ingestion und Evaluation, orchestrierter Advisor-Agent hinter einem LLM-Gateway.* +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 Insights um; +* 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". +*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):_ orchestrierter Advisor-Agent mit 2–3 Sub-Agenten über klare Service-Kontrakte; LLM-Gateway mit Kosten-Observability; Ontologie-Guard; Eval-Harness als CI-Gate; vollständig getestete deterministische Services; Resilienz gegen Ausfall externer Datenquellen; ein ADR mit Messvertrag (Token-Budget, Eval-Schwelle, Modulgrenzen-Check). -* _Kür (für Spitzennoten):_ autonomes Planning, Self-Repair-Loops, Model-Routing. +* _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). ---- +h2. 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. + h2. Lehr- und Lernmethoden *Lehrtechniken:* Vorlesungen, Übungen, Gruppenarbeit, Online-Lehre, Workshops. @@ -179,18 +209,16 @@ h2. Struktur h2. 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). diff --git a/tools/md2confluence.py b/tools/md2confluence.py new file mode 100644 index 0000000..89fd445 --- /dev/null +++ b/tools/md2confluence.py @@ -0,0 +1,97 @@ +#!/usr/bin/env python3 +"""Convert an AISE502 module description (Markdown) into Confluence wiki markup. + + python3 tools/md2confluence.py + +Handles the constructs these documents use: ATX headings, pipe tables, horizontal rules, +bullet and numbered lists (one nesting level), block quotes, and inline bold/italic/code. +Hard-wrapped lines are joined first, so a paragraph or list item becomes one line -- the form +Confluence expects. The "Inhalte" section's `**N. Title** *(part)*` blocks with their bullets +become a numbered list with sub-bullets, matching the earlier hand-written export. +""" +import re, sys, pathlib + +def inline(t): + t = t.replace("--", "–") + t = re.sub(r"\*\*(.+?)\*\*", lambda m: "\x01" + m.group(1) + "\x01", t) # bold -> *x* + t = re.sub(r"(? _x_ + t = t.replace("\x01", "*") + t = re.sub(r"`([^`]+)`", lambda m: "{{" + m.group(1) + "}}", t) + return t + +def unwrap(lines): + """join hard-wrapped continuation lines into their paragraph / list item / table row""" + out = [] + for raw in lines: + line = raw.rstrip("\n") + stripped = line.strip() + starts_block = (not stripped or line.startswith("#") or line.startswith("|") + or re.match(r"^\s*([-*+]|\d+\.)\s", line) or stripped.startswith(">") + or re.match(r"^-{3,}$", stripped)) + if out and out[-1].strip() and not starts_block: + out[-1] = out[-1].rstrip() + " " + stripped + else: + out.append(line) + return out + +def convert(md): + lines = unwrap(md.splitlines()) + res, i, section, in_item = [], 0, "", False + while i < len(lines): + line = lines[i]; s = line.strip() + if not s: + res.append(""); i += 1; continue + if re.match(r"^-{3,}$", s): + res.append("----"); i += 1; continue + m = re.match(r"^(#{1,6})\s+(.*)$", s) + if m: + level, text = len(m.group(1)), inline(m.group(2)) + if level == 3 and section.startswith("Inhalte"): + res.append(f"h4. {text}") + else: + res.append(f"h{min(level,4)}. {text}") + if level == 2: section = m.group(2); in_item = False + i += 1; continue + if s.startswith("|"): # table + rows = [] + while i < len(lines) and lines[i].strip().startswith("|"): + rows.append([c.strip() for c in lines[i].strip().strip("|").split("|")]); i += 1 + body = [r for r in rows if not all(re.fullmatch(r":?-{2,}:?", c or "-") for c in r)] + head = body[0] if body and any(body[0]) and len(body) > 1 else None + if head and rows.index(head) == 0 and any(c for c in head): + res.append("||" + "||".join(inline(c) for c in head) + "||") + body = body[1:] + for r in body: + res.append("|" + "|".join(inline(c) if c else " " for c in r) + "|") + continue + if s.startswith(">"): + res.append("{quote}"); res.append(inline(s.lstrip("> ").strip())); res.append("{quote}") + i += 1; continue + m = re.match(r"^(\s*)(\d+)\.\s+(.*)$", line) # numbered item + if m: + res.append("# " + inline(m.group(3))); in_item = True; i += 1; continue + m = re.match(r"^(\s*)[-*+]\s+(.*)$", line) # bullet + if m: + indent, text = len(m.group(1)), inline(m.group(2)) + res.append(("#* " if (indent >= 2 or in_item) else "* ") + text) + i += 1; continue + m = re.match(r"^\*\*(\d+)\.\s+(.*)$", s) # "**7. Title** *(part)*" + if m and section.startswith("Inhalte"): + res.append("# " + inline("**" + m.group(2))) # the list supplies the number + in_item = True; i += 1; continue + res.append(inline(s)); in_item = False; i += 1 + # Confluence restarts a numbered list after a blank line: drop blanks between list items + tight, item = [], re.compile(r"^(#\*?|\*)\s") + for j, line in enumerate(res): + if not line.strip() and tight and item.match(tight[-1]): + nxt = next((x for x in res[j + 1:] if x.strip()), "") + if item.match(nxt): + continue + tight.append(line) + text = "\n".join(tight) + return re.sub(r"\n{3,}", "\n\n", text).strip() + "\n" + +if __name__ == "__main__": + src, dst = pathlib.Path(sys.argv[1]), pathlib.Path(sys.argv[2]) + dst.write_text(convert(src.read_text(encoding="utf-8")), encoding="utf-8") + print(f"wrote {dst} ({len(dst.read_text(encoding='utf-8').splitlines())} lines) from {src.name}")