Auto-commit 2026-09-08 10:25: 4 files changed, 190 insertions(+), 64 deletions(-)
This commit is contained in:
herzogflorian
parent
1a5e5f2246
commit
9fc72de9ed
@ -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 |
|
||||
|
||||
@ -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 |
|
||||
|
||||
@ -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).
|
||||
|
||||
97
tools/md2confluence.py
Normal file
97
tools/md2confluence.py
Normal file
@ -0,0 +1,97 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Convert an AISE502 module description (Markdown) into Confluence wiki markup.
|
||||
|
||||
python3 tools/md2confluence.py <in.md> <out.txt>
|
||||
|
||||
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"(?<!\w)\*(.+?)\*(?!\w)", lambda m: "_" + m.group(1) + "_", t) # italic -> _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}")
|
||||
Loading…
x
Reference in New Issue
Block a user