diff --git a/Modulbeschreibung_AISE502_v2_2026.md b/Modulbeschreibung_AISE502_v2_2026.md index bc876eb..710f022 100644 --- a/Modulbeschreibung_AISE502_v2_2026.md +++ b/Modulbeschreibung_AISE502_v2_2026.md @@ -6,8 +6,14 @@ | **Ausgabestelle** | Institute for Data Analysis, Artificial Intelligence, Visualization, and Simulation (DAViS) | | **Geltungsbereich** | Departement | | **Klassifizierung** | Nicht klassifiziert | -| **Version** | 2.0.0 | -| **Ausgabedatum** | 2026 (Neufassung) | +| **Version** | 2.1.0 | +| **Ausgabedatum** | 8. September 2026 (Inhalte an die ausgelieferten Vorlesungen 1–14 angeglichen) | + +> **Hinweis:** Dies ist die **Kurzfassung**. Die ausführliche Fassung mit Phasenlogik, +> Meilenstein-Tabelle und Literaturapparat ist `Modulbeschreibung_AISE502_v3_2026.md` +> (Version 3.1.0) mit dem zugehörigen Confluence-Export. Beide Fassungen beschreiben denselben +> Kurs; massgeblich für den Sitzungsplan ist die eingereichte Semesterinformation +> (`semesterinformation_HS26_AISE502_AIinSE2.xlsx`). --- @@ -28,32 +34,38 @@ Das Modul "AI in Software Engineering II" stellt das **Software Engineering gros Systeme** in den Mittelpunkt und behandelt Künstliche Intelligenz als integralen Bestandteil moderner Softwarearchitekturen. Aufbauend auf den Grundlagen aus "AI in Software Engineering I" (LLMs, Prompting, RAG, Clean Code, erste Agenten-Konzepte) verschiebt sich -der Fokus von der *einzelnen AI-Funktion* hin zum *Entwurf vollständiger, verteilter -Software-Systeme*, in denen AI-Komponenten zur Laufzeit mitarbeiten. +der Fokus von der *einzelnen AI-Funktion* hin zum *Entwurf vollständiger Software-Systeme*, +in denen AI-Komponenten zur Laufzeit mitarbeiten. -Der Kurs ist **architektur-zentriert** (verankert in Sommerville, *Modernes Software-Engineering*) -und folgt der Leitfrage: *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 – +Der Kurs ist **architektur-zentriert** und folgt einem eigenen, englischsprachigen +Vorlesungsskript: *"A Theory of Architecture--Application Fit"*. Dieses entwickelt eine +messbare Entscheidungstheorie der Softwarearchitektur -- Architektur als Menge schwer +umkehrbarer, qualitätsgetriebener Entscheidungen, getroffen durch den systematischen Abgleich +von **Anforderungsprofilen** (zehn Anwendungsklassen) und **Fähigkeitsprofilen** (sieben +Architektur-Patterns) über **zwölf gemeinsame Profildimensionen**, dokumentiert in einem ADR +und über den Lebenszyklus empirisch überprüft (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 dabei in **zwei gleichwertigen Rollen**, die durchgängig -miteinander verwoben werden: +Künstliche Intelligenz erscheint dabei in **zwei gleichwertigen Rollen**: - **AI als Werkzeug zum Bauen (Achse A):** Studierende setzen moderne agentische - Entwicklungswerkzeuge (z.B. Claude Code, Cursor, Agent-SDKs, MCP) produktiv, aber - kritisch-reflektiert ein, um Architektur zu entwerfen, Code zu generieren, zu refactoren - und zu reviewen. + Entwicklungswerkzeuge produktiv, aber kritisch-reflektiert ein -- auf Basis der empirischen + Evidenz (randomisierte Studien mit positiven wie negativen Befunden), mit + Architektur-Dokumentation als Agenten-Kontext und Fitness Functions als Leitplanken. - **AI als Komponente im System (Achse B):** Studierende entwerfen Architekturen, in denen - ein oder mehrere AI-Agenten als Laufzeit-Bausteine wirken, und lernen, diese - nicht-deterministischen Komponenten *engineering-tauglich* zu machen – also testbar, - beobachtbar, robust, skalierbar und bezahlbar. + LLM-, ML- und Optimierungskomponenten als Laufzeit-Bausteine wirken, und machen diese + nicht-deterministischen Komponenten *engineering-tauglich* -- gekapselt (Gateway, Ports), + asynchron integriert, beobachtbar, getestet (Eval-Harness) und abgesichert (Ontologie-Guard). -Den verbindenden roten Faden bildet die Erkenntnis, dass die ingenieurmässige Disziplin, die -man zum **Bauen mit** AI benötigt, dieselbe ist wie jene, die man zum **Einbetten von** AI -benötigt. Durch ein durchgehendes Gruppenprojekt – eine verteilte, AI-gestützte -Portfolio-Analyse-Plattform – wenden die Studierenden den gesamten Architektur- und -Engineering-Bogen praktisch an und erleben unmittelbar, wo der Umgang mit -nicht-deterministischer AI das System-Engineering herausfordert. +Den verbindenden roten Faden bildet die Erkenntnis (Annahme A6 der Theorie), dass die +ingenieurmässige Disziplin, die man zum **Bauen mit** AI benötigt, dieselbe ist wie jene, die +man zum **Einbetten von** AI benötigt: AI erweitert den Qualitätsattributraum, ändert aber die +Methode nicht. Durch ein durchgehendes Gruppenprojekt -- eine modulare, AI-gestützte +Portfolio-Analyse-Plattform -- wenden die Studierenden den gesamten Architektur- und +Engineering-Bogen praktisch an. Das Verhältnis von klassischem Software Engineering zu AI-spezifischen Techniken beträgt etwa **60 % zu 40 %**. @@ -69,65 +81,73 @@ etwa **60 % zu 40 %**. Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage: -1. **Software-Architektur entwerfen und begründen:** - - Architektur als Summe schwer umkehrbarer Entscheidungen verstehen und diese - dokumentieren (Architecture Decision Records, C4-Sichten). - - Qualitätsattribute (Wartbarkeit, Skalierbarkeit, Zuverlässigkeit, Performance, - Sicherheit) als Treiber von Architekturentscheidungen einsetzen und Trade-offs - analysieren. - - Architekturstile (modularer Monolith, Microservices, Event-Driven, Hexagonal/Ports & - Adapters) kennen, vergleichen und situationsgerecht auswählen. +1. **Architektur als Entscheidungsproblem behandeln:** + - Architektur als Menge schwer umkehrbarer Entscheidungen verstehen und 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 anwenden. -2. **Verteilte Systeme robust gestalten:** - - Schnittstellen und Kontrakte zwischen Services entwerfen, versionieren und absichern. - - Synchrone und asynchrone Kommunikationsmuster anwenden. - - Resilienz-Patterns (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback) gegen - unzuverlässige externe Abhängigkeiten einsetzen. +2. **Anforderungsprofile konstruieren:** + - Architektur-relevante Anforderungen als sechsteilige Qualitätsszenarien mit Antwortmass + formulieren und über einen Utility Tree gewichten. + - Anwendungsklassen als Anforderungsprofile R(a) charakterisieren -- Gewichte, + Workload-Shape und regulatorische Knock-out-Constraints. -3. **AI als Systemkomponente integrieren:** - - AI-Komponenten hinter stabilen Schnittstellen kapseln (Anti-Corruption-Layer) und - deterministische von nicht-deterministischen Systemteilen sauber trennen. - - Multi-Agenten-Systeme als Architekturentscheidung konzipieren (Orchestrierungs- - Topologien: Chain, Tree, Graph, Multi-Agent) und implementieren. - - Domänenwissen (Ontologie) zugleich als Architektur-Vertrag und als Schutzmechanismus - gegen Halluzinationen einsetzen. +3. **Architektur-Patterns beherrschen und ihre Fähigkeitsprofile herleiten:** + - Die sieben Patterns (Schichtenarchitektur, modularer Monolith, Hexagonal, Microservices, + Event-Driven, Pipes-and-Filters, Serverless) mit Topologie, Ursprungsproblem, Taktiken + und Fähigkeitsprofil C(p) erklären und vergleichen. + - Open-Source-Referenzsysteme im Quellcode inspizieren und Engineering-Konsequenzen + (Build, Test, CI/CD, Betrieb, Teamstruktur) ableiten. -4. **Qualität nicht-deterministischer Software sichern:** - - Teststrategien (Testpyramide, TDD, Contract-Tests) für die deterministischen - Systemteile anwenden. - - Eigene Evaluations-Harnesses für nicht-deterministische AI-Ausgaben aufbauen - (LLM-as-Judge, Regression gegen Domänen-Axiome, gelabelte Referenzdaten). +4. **Die Passung berechnen, begründen und verteidigen:** + - Das dreistufige, nicht-kompensatorische Matching-Verfahren anwenden (Knock-out und + Workload-Shape-Gate, Veto mit dokumentierten Mitigationen, ordinale Rangbildung mit + Sensitivitätsanalyse) und die 7×10-Matrix als Explikationsmodell nutzen. + - Hybride als Normalfall erkennen und Evolutionspfade planen (Strangler Fig). -5. **AI-gestützte Software professionell bauen (Achse A):** - - Moderne agentische Entwicklungswerkzeuge produktiv einsetzen und deren Ausgaben - kritisch bewerten und verantworten. +5. **Verteilte Ränder robust gestalten:** + - Schnittstellen und Kontrakte entwerfen und versionieren; synchrone und asynchrone + Kommunikationsmuster situationsgerecht einsetzen. + - Resilienz-Patterns (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback, Dead-Letter + Queue, idempotenter Consumer) gegen unzuverlässige externe Abhängigkeiten einsetzen. -6. **Betreiben, skalieren und absichern:** - - CI/CD, Deployment-Strategien und Observability (Logging, Metriken, Tracing) anwenden. - - Token-Kosten, Latenz und Ressourcennutzung von AI-Komponenten messen und optimieren - (Caching, Batching, Model-Routing). - - Sicherheitsaspekte berücksichtigen, insbesondere Threat-Modeling und neue - Bedrohungsklassen wie Prompt-Injection. +6. **AI als Systemkomponente integrieren (Achse B):** + - AI-Komponenten hinter stabilen Schnittstellen kapseln (Port, LLM-Gateway, + Anti-Corruption-Layer) und deterministische von nicht-deterministischen Systemteilen + strikt trennen. + - Multi-Agenten-Systeme als Komposition klassischer Topologien konzipieren und ihre + Ökonomie bewerten; Domänenwissen (Ontologie) zugleich als Architektur-Vertrag und als + Halluzinations-Guard einsetzen. + - Eigene Eval-Harnesses aufbauen (Golden Sets, LLM-as-Judge, Domänen-Axiome) und als + CI-Gate betreiben. -7. **Evolution und Wartbarkeit gewährleisten:** - - Strategien zur Weiterentwicklung und Migration (z.B. Strangler-Fig) sowie evolutionäre - Architektur mit Fitness Functions anwenden. +7. **Entscheidungen messbar machen, betreiben und weiterentwickeln:** + - Jede Architekturentscheidung mit einem Messvertrag abschliessen: Fitness Functions in + CI/CD (Modulgrenzen-Checks, Performance- und Token-Budgets), DORA-Metriken und + Observability (Logging, Metriken, Tracing). + - Token-Kosten und Latenz messen und optimieren (Caching, Batching, Model-Routing); + Conway's Law und Team Topologies als dritte Passungsdimension berücksichtigen. -8. **Ethik und Verantwortung reflektieren:** - - Gesellschaftliche und ethische Implikationen AI-gestützter Systeme im sensiblen - Anwendungskontext (z.B. Finanzdaten) bewerten und verantwortungsbewusste Lösungen - entwickeln. +8. **AI als Werkzeug professionell einsetzen sowie Ethik und Verantwortung reflektieren + (Achse A):** + - Die empirische Evidenz zu AI-Coding-Werkzeugen differenziert bewerten und agentische + Werkzeuge mit ADRs als Kontext und Tests als Leitplanken einsetzen; Ausgaben kritisch + prüfen und verantworten. + - Gesellschaftliche, regulatorische (EU AI Act) und ethische Implikationen im sensiblen + Anwendungskontext Finanzdaten bewerten; neue Bedrohungsklassen (Prompt Injection, + OWASP LLM Top 10) im Threat-Modeling berücksichtigen. ### Leistungsnachweis | Anteil | Komponente | |---|---| -| 50 % | Praxisprojekt (verteilte AI-gestützte Plattform, Gruppenarbeit) | -| 50 % | Schriftliche Prüfung (Schwerpunkt: Architektur-Reasoning und Trade-off-Analyse, keine reine Faktenabfrage) | +| 50 % | Praxisprojekt (modulare AI-gestützte Plattform, Gruppenarbeit) -- Requirements-Dossier (A1, Woche 3), Architektur-Dossier mit ADR und Messvertrag (A2, Woche 7), Implementierung, 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, keine reine Faktenabfrage | ### Unterrichtssprache -Deutsch mit englischen Unterlagen und Papern. +Deutsch mit englischen Unterlagen und Papern (Skript, Folien, Übungen und Prüfung in Englisch). ### Eingangskompetenzen @@ -139,129 +159,178 @@ Grundlagen in Statistik und maschinellem Lernen. ## Inhalte -Der Kurs umfasst 14 Sitzungen. Das klassische, architektur-zentrierte Software Engineering -bildet die Substanz (~60 %). AI wird in zwei Rollen eingewoben: als kurze **AI-Linse** an jedem -SE-Thema (AI illustriert das jeweilige SE-Konzept) sowie in zwei **eigenen Fokus-Einheiten** für -genuin neue Themen (Agenten-Architektur, Evaluation). Ein durchgehendes Projekt verschränkt -beide Achsen. +Der Kurs umfasst **14 Sitzungen zu je 4 Lektionen**, dem Vorlesungsskript (Teile I--V) folgend. +Das klassische, architektur-zentrierte Software Engineering bildet die Substanz (~60 %); AI +erscheint als kurze **AI-Linse** an den einzelnen Themen sowie in zwei eigenen Sitzungen zur +AI-Dimension (Sitzungen 12 und 13). Ein durchgehendes Projekt verschränkt beide Achsen. +**Wochen 1--7** sind Designphase (2 L Vorlesung + 2 L Übung), **Wochen 8--13** +Implementierungsphase (3 L Vorlesung + 1 L Standup/Coaching), **Woche 14** Synthese und +Präsentationen (1 L + 3 L). -**1. Was ist Software-Architektur?** -- Inhalte: Architektur vs. Design vs. Implementierung; Architektur als begründete - Entscheidungen; Architecture Decision Records (ADR); C4-Sichten; Stakeholder. -- AI-Linse (A): Ein Agent erstellt ADR-Entwürfe – der Mensch verantwortet die Entscheidung. -- Projekt: Domäne und Vision; Setup der Entwicklungswerkzeuge. +**1. Das Entscheidungsproblem und das Framework** *(Teil I)* +- Inhalte: Vier Produktionssysteme, zwei Fakten (Stack Overflow, Monzo, Segment, Prime Video); + Architektur als schwer umkehrbare Entscheidungen; die fünf Framework-Elemente (R(a), C(p), + fit, ADR, Messvertrag); die Annahmen A1--A6; ADR/MADR und C4. +- AI-Linse (A): Ein Agent erstellt ADR-Entwürfe -- der Mensch verantwortet die Entscheidung. +- Projekt: Kickoff -- Teams, Repository und Werkzeug-Setup, Domänenverständnis, + Ontologie-Skizze, rohe Stakeholder-Wünsche. -**2. Qualitätsattribute als Architektur-Treiber** -- Inhalte: Funktionale vs. nicht-funktionale Anforderungen; Wartbarkeit, Skalierbarkeit, - Zuverlässigkeit, Performance, Sicherheit; NFRs messbar machen (Szenarien, Fitness Functions). -- AI-Linse (B): Nicht-Determinismus, Latenz und Kosten als neue Qualitätsattribute von - AI-Komponenten. -- Projekt: Qualitätsszenarien definieren. +**2. Das Koordinatensystem: zwölf Profildimensionen** *(Teil I)* +- Inhalte: Die zwölf Dimensionen mit Antwortmass und Messinstrument; ISO/IEC 25010:2023 als + Vokabular; ASR und Quality Attribute Workshop; sechsteilige Qualitätsszenarien; Utility Tree + → Gewichte; R(a) aus Gewichten, Workload-Shape und Constraints. +- AI-Linse (B): Nicht-Determinismus, Latenz und Kosten als Dimension D12 der AI-Integrierbarkeit. +- Projekt: Requirements-Workshop I -- Qualitätsszenarien mit Antwortmass, Utility Tree beginnen. -**3. Strukturieren im Kleinen: Kopplung & Kohäsion** -- Inhalte: Kopplung und Kohäsion als zentrale Metriken; Modularität; Richtung von - Abhängigkeiten. -- AI-Linse (B): Adapter/Facade um ein LLM als Anti-Corruption-Layer. -- Projekt: Domänenmodell (Vertiefung des Stoffs aus AISE501). +**3. Nachfrage, Angebot, Passung: das formale Modell** *(Teil I)* +- Inhalte: C(p) über Taktiken; das dreistufige, nicht-kompensatorische Matching-Verfahren am + Mini-Match des Kursprojekts (C10 gegen L, MM, MS); warum keine gewichtete Summe; + ADR/MADR mit Messvertrag als Abschluss. +- AI-Linse (A/B): Der LLM-Provider hinter einem Port; ein Agent entwirft den MADR, ein Mensch + zeichnet ihn. +- Projekt: Requirements-Workshop II -- R(Plattform) finalisieren, Ontologie als Vertrag. + **Abgabe A1 (Ende Woche 3).** -**4. Design Patterns als Architektur-Vokabular** -- Inhalte: Relevante GoF-Patterns (Strategy, Adapter, Observer, Factory, Facade) im - Architekturkontext; Abgrenzung Prinzip vs. Struktur. -- AI-Linse (A): Ein Agent schlägt Patterns/Refactorings vor; Studierende prüfen die - resultierende Kopplung. -- Projekt: Ontologie als Vertrag formalisieren. +**4. Patterns I: ein Deployable** *(Teil II)* +- Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters -- je + Ursprungsproblem, Topologie, Architecture Quantum, Fähigkeitsprofil, Anti-Patterns; + Modulgrenzen als CI-Gegenstand (Spring Modulith, import-linter, ArchUnit, Packwerk). +- AI-Linse (B): Der Port als Anti-Corruption-Layer, der die LLM-Komponente austauschbar macht. +- Projekt: Architekturstudium I -- healthchecks (Django), Apache Fineract und Cosmic Python im + Code; C4-Kontext- und Container-Entwurf. -**5. Architekturstile** -- Inhalte: Modularer Monolith, Microservices, Event-Driven Architecture, Hexagonal/Ports & - Adapters; Auswahlkriterien; Conway's Law und Team-Topologien. -- AI-Linse (B): Welcher Stil eignet sich, wenn eine Komponente ein Agent ist? -- Projekt: Architektur aus der Ontologie ableiten (Bounded Contexts → Services). +**5. Patterns II: verteilte Topologien** *(Teil II)* +- Inhalte: Microservices und Event-Driven Architecture; Sagas vs. ACID; der verteilte Monolith; + Broker- vs. Mediator-Topologie; die sieben Resilienz-Grundmuster; Fallstudien (Netflix, + Uber DOMA, Monzo, Segment-Rückbau). +- AI-Linse (B): Ein LLM-Aufruf als unzuverlässiger Remote-Call; Queues absorbieren Latenz, + Rate-Limits und Ausfälle. +- Projekt: Architekturstudium II -- Ränder entwerfen (Ingestion-Queue, Resilienz gegen + API-Ausfall), Service-Kontrakte skizzieren, Matrix-Vorfilter. -**6. Verteilte Systeme I: Schnittstellen und Kontrakte** -- Inhalte: API-Design, Kontrakte, Versionierung; synchrone vs. asynchrone Kommunikation. -- AI-Linse (B): Ein LLM-Aufruf als unzuverlässiger Remote-Call. -- Projekt: Walking Skeleton – Services und ein minimaler Agent laufen. +**6. Patterns III: Batch und Serverless, Verallgemeinerung -- und die eigene Klasse C10** +*(Teil II; Teil III)* +- Inhalte: Pipes-and-Filters/Batch und Serverless/FaaS; Stepping Back -- Architecture Quantum, + "Partitioning beats distribution", konsolidierte Fähigkeitstabelle, Ausblick + Agenten-Orchestrierung; danach C10, die AI-native Advisory-Plattform (Klasse des Projekts) + mit dem Spiegelpaar C1/C2 als Vorschau. +- AI-Linse (B): Serverless und Pipelines als natürliche Heimat von Ingestion und Evaluation. +- Projekt: **Der Match** -- drei Stufen für die eigene Plattform, Architekturentscheid, + ADR-Entwurf. -**7. Verteilte Systeme II: Resilienz** -- Inhalte: Resilienz-Patterns (Timeout, Retry, Circuit-Breaker, Bulkhead, Fallback); - asynchrone Architektur, Queues, Backpressure. -- AI-Linse (B): Guards und Fallbacks gegen Halluzination und API-Ausfälle. -- Projekt: Resilienz gegen Ausfall externer Datenquellen einbauen. +**7. Die Passung: drei Fälle, das Verfahren, die Matrix** *(Teil IV)* +- Inhalte: Drei durchgerechnete Matches (C6 Shape-Gate, C1 Veto und Mitigationen, C2 ordinale + Lesung mit Sensitivitätsanalyse); das Verfahren im Allgemeinen; die 7×10-Matrix lesen; + Einführung des Messvertrags (Fitness Functions, DORA). +- AI-Linse (A/B): Der Messvertrag als Betriebslizenz auch für agentisch erzeugten Code. +- Projekt: Lösungsdesign finalisieren (Service-Schnitt, Kontrakte, Walking-Skeleton-Plan, + Messvertrag mit Zahlen); **Design-Review-Gate**, **Abgabe A2 (Ende Woche 7)**. -**8. Fokus-Einheit: AI-Agenten als Architektur-Baustein** -- Inhalte: Agent = Loop + Tools + State; Orchestrierungs-Topologien (Chain, Tree, Graph, - Multi-Agent) als Architekturentscheidung; Tool-Use; Inter-Service-Kommunikation der Agenten. -- Projekt: Orchestrierter Multi-Agent (2–3 Sub-Agenten über klare Kontrakte) – Pflichtteil. +**8. Anwendungsklassen I: C1--C5** *(Teil III)* +- Inhalte: Anwendungsklassen als ASR-Bündel; C1 Kernbanking, C2 Social/Content, C3 Back-Office, + C4 ERP, C5 E-Commerce -- Herausforderungen mit Zahlen und Regulatorik, Anforderungsprofile + und die reale Architekturwahl (LMAX vs. Monzo, Instagram, Shopify, Fineract). +- AI-Linse (B): Die Latenzklasse, nicht die Genauigkeit, entscheidet über die Platzierung einer + AI-Komponente; Agenten schlagen vor, deterministische Services entscheiden und buchen. +- Projekt: Sprint 1 -- Walking Skeleton beginnen (MarketDataService, minimaler ResearchAgent, + stabile API). -**9. Qualität & Test I** -- Inhalte: Teststrategie, Testpyramide, TDD, Contract-Tests; technische Schuld; Code Reviews. -- AI-Linse (A): Ein Agent generiert Tests; Studierende bewerten Abdeckung und Qualität. -- Projekt: Testabdeckung der deterministischen Services. +**9. Anwendungsklassen II: C6--C9 und zehn Profile nebeneinander** *(Teil III)* +- Inhalte: C6 Simulation/Batch, C7 DSS/BI, C8 IoT-Streaming, C9 Collaboration/Messaging; + die dritte Konsistenzsemantik (Reproduzierbarkeit, Freshness-Kontrakt); zehn Profile + nebeneinander mit fünf klassenübergreifenden Beobachtungen. +- AI-Linse (B): Text-to-SQL nur auf der governierten semantischen Schicht; keine LLM-Aufrufe + pro Event im Stream. +- Projekt: Coaching; Walking Skeleton fertigstellen -- **Meilenstein: läuft End-to-End**. -**10. Fokus-Einheit: Evaluation nicht-deterministischer Ausgaben** -- Inhalte: Testen nicht-deterministischer Software; LLM-as-Judge; Regression gegen - Domänen-Axiome und gelabelte Referenzdaten; Eval-Harness als Software-Engineering-Artefakt. -- Projekt: Eval-Harness gegen Domänenregeln aufbauen. +**10. Hybride, Evolution und das achtstufige Entscheidungsverfahren** *(Teil IV)* +- Inhalte: Hybride als Normalfall; Fit als Funktion der Zeit; Migrationsstrategien + (MonolithFirst, Strangler Fig, Sacrificial Architecture; Segment, Prime Video, Shopify); + das achtstufige Verfahren an ADR-007; Matrix-Zeilenbegründungen. +- AI-Linse (B): Die AI-Schicht als bewusst ersetzbare Sacrificial Architecture hinter einem Port. +- Projekt: Coaching; deterministische Services (Performance, Risk, Optimization) mit exakten + Tests gegen die Referenzvektoren. -**11. DevOps und Betrieb** -- Inhalte: CI/CD, Build-Reproduzierbarkeit, Deployment-Strategien (Blue/Green, Canary); - Observability (Logging, Metriken, Tracing); Grundgedanke SRE. -- AI-Linse (B): Token-Kosten und Latenz im Monitoring; Versionierung von Prompts und Modellen. -- Projekt: CI/CD-Pipeline und Observability. +**11. Der Messvertrag, Conway's Law und die Grenzen der Theorie** *(Teil IV)* +- Inhalte: Fitness Functions in CI/CD (Taxonomie, drei Instrumentenfamilien); die vier + DORA-Metriken und der Kopplungs-Befund; Kostenverlauf von Änderungen (Boehm vs. Menzies); + Conway's Law und Team Topologies; sechs Grenzen der Theorie. +- AI-Linse (A/B): Eval-Harness-Pass-Rate und Token-Budget als neue Fitness-Function-Typen mit + alter Mechanik. +- Projekt: Coaching; Resilienz auf allen externen Aufrufen, verifizierte Graceful Degradation + -- **Meilenstein: deterministischer Kern vollständig getestet und resilient**. -**12. Skalierung und Evolution** -- Inhalte: Caching, Lasttests, Skalierungs-Patterns; Strangler-Fig-Migration; evolutionäre - Architektur und Fitness Functions. -- AI-Linse (B): Model-Routing, Caching und Batching als Skalierungs-Patterns. -- Projekt: Lasttest und Optimierung; Kür: autonome Agenten / Self-Repair-Loops. +**12. AI-Dimension I: Achse A -- Evidenz und Konsequenzen; Achse B -- Grundlagen** *(Teil V)* +- Inhalte: Zwei widersprüchliche RCTs (Copilot +55.8 % vs. METR −19 % samt Wahrnehmungslücke) + und ihre Auflösung; der Verifikations-Engpass; ADRs und Agenten-Instruktionsdateien als + Kontrollschnittstelle; Achse B: der Sentiment-Call falsch und richtig verdrahtet, drei + Komponententypen, LLM-Gateway-Referenzarchitektur, Eval-Harness-Grundlagen. +- Projekt: Coaching; AdvisorAgent mit 2--3 Sub-Agenten hinter dem Gateway (Pflichtteil), + Ontologie-Guard auf allen Insights aktiv. -**13. Sicherheit** -- Inhalte: Threat-Modeling, Secure-by-Design, Least Privilege, Defense in Depth. -- AI-Linse (A/B): Prompt-Injection als neue Bedrohungsklasse; Security-Review mit AI-Unterstützung. -- Projekt: Hardening des Systems. +**13. AI-Dimension II: Bedrohungen, verschobene Matrix, Orchestrierung -- und Synthese** *(Teil V)* +- Inhalte: OWASP LLM Top 10 und Prompt Injection als Architekturproblem; EU AI Act als + Knock-out-Constraint; die fünf Zellverschiebungen der Matrix; Agenten-Orchestrierung als + achtes, emergentes Kompositionsmuster und die Ökonomie der Autonomie; Synthese und + Prüfungsorientierung. +- Projekt: Coaching; Eval-Harness als CI-Gate, Kosten- und Latenz-Dashboard, Threat-Model, + Hardening, Topologie-ADR; Kür: autonomes Planning, Self-Repair, Model-Routing -- + **Meilenstein: Eval-Harness im CI, Guard aktiv, Kosten-Observability**. -**14. Synthese, Präsentation und Architektur-Kritik** -- Inhalte: Trade-offs verteidigen; kritische Bewertung der Architektur; Feedback. -- Reflexion: Wo half und wo schadete die AI – im Bauen (A) und im System (B)? -- Projekt: Präsentationen und Peer-Reviews der Abschlussprojekte. +**14. Synthese, Präsentation und Architektur-Verteidigung** +- Inhalte (1 L): Die Theorie-Pipeline in einem Satz; eine Disziplin an zwei Bindungsstellen; + Prüfungsorientierung und Q&A -- kein neuer Stoff. +- Reflexion: Wo half und wo schadete die AI -- im Bauen (A) und im System (B)? +- Projekt (3 L): Präsentationen, Architektur-Verteidigung und Peer-Reviews -- **Abgabe A3**. --- ## 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: +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; ob ihre Services als ein Deployable oder als mehrere ausgeliefert werden, ist +die Architekturentscheidung der Teams in Woche 6, die in Woche 14 verteidigt wird. Die +Plattform: -- bezieht **strukturierte externe Daten** (Börsenkurse / Preisdaten, z.B. via Yahoo Finance) – - mit Live-API und verpflichtendem Cache-/Snapshot-Fallback; +- 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, Web-Berichte) und wandelt sie über - eine AI-Komponente in strukturierte Insights um; -- berechnet **Risikomanagement-, Performance- und Portfolio-Optimierungs-Kennzahlen** - (Formeln und Testvektoren werden vorgegeben; die Lernleistung ist das Engineering darum - herum, nicht die Herleitung der Finanzmathematik); -- stellt die Funktionalität **API-first** bereit, mit einem dünnen Dashboard (z.B. Streamlit) + 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 einem dünnen Dashboard (z. B. Streamlit) nur zur Demonstration. -**Zentrale Architekturregel:** Die AI-Agenten dürfen quantitative Werte ausschliesslich über -die deterministischen Services beziehen und interpretieren – niemals selbst berechnen. Diese -Trennung von deterministischen und nicht-deterministischen Systemteilen ist die prüfbare -Manifestation von "AI engineering-tauglich machen". +**Zentrale Architekturregel:** *Agents propose; deterministic services decide and book.* Die +AI-Agenten dürfen quantitative Werte ausschliesslich über die deterministischen Services +beziehen und interpretieren -- niemals selbst berechnen. Diese Trennung von deterministischen +und nicht-deterministischen Systemteilen ist die prüfbare Manifestation von "AI +engineering-tauglich machen" und wird bewertet. **Beispielhafte Service-Landschaft (Bounded Contexts):** MarketData-Service, News-Ingestion, Risk-Service, Performance-Service, Optimization-Service, Portfolio-Service sowie ein orchestrierender Advisor-Agent mit spezialisierten Sub-Agenten (Research-, Risk-, -Optimization-Agent). Eine Ontologie der Anlagedomäne (Asset-Klassen, Sektoren, Regeln) dient -als Architektur-Vertrag und als Halluzinations-Guard. +Optimization-Agent) hinter einem einzigen LLM-Gateway. Eine Ontologie der Anlagedomäne +(Asset-Klassen, Sektoren, Regeln) dient als Architektur-Vertrag und als Halluzinations-Guard. + +**Meilensteine:** M1 Requirements und Ontologie (Wochen 1--3, Abgabe A1) · M2 +Architekturentscheid und Lösungsdesign (4--7, Abgabe A2 mit Design-Review-Gate) · M3 Walking +Skeleton (8--9) · M4 deterministischer Kern und Resilienz (10--11) · M5 +Multi-Agent-Orchestrierung, Evaluation und Hardening (12--13) · M6 Präsentation und +Architektur-Verteidigung (14, Abgabe A3). **Abstufung Pflicht / Kür:** -- *Pflicht (bestehensrelevant):* orchestrierter Advisor-Agent mit 2–3 Sub-Agenten über klare - Service-Kontrakte; Ontologie-Guard; Sentiment-Evaluation der News; vollständig getestete - deterministische Services; Resilienz gegen Ausfall externer Datenquellen; Observability für - Kosten und Latenz. -- *Kür (für Spitzennoten):* autonomes Planning (der Agent entscheidet selbst über - Tool-/Sub-Agent-Aufrufe), 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 über klare Service-Kontrakte; Ontologie-Guard; + Resilienz gegen Ausfall externer Datenquellen; Eval-Harness für die AI-Komponente; + Observability für Kosten und Latenz ü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 Tool- und + Sub-Agent-Aufrufe), Self-Repair-Loops, Model-Routing, Deployment mit CI/CD und Tracing. --- @@ -269,8 +338,9 @@ als Architektur-Vertrag und als Halluzinations-Guard. **Lehrtechniken:** Vorlesungen, Übungen, Gruppenarbeit, Online-Lehre, Workshops. -**Lernaktivitäten:** Studium von Literatur, Übungsaufgaben, Bearbeiten von Problemen und deren -Lösungsfindung, Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium. +**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. @@ -281,14 +351,24 @@ Lösungsfindung, Zusammenarbeit mit anderen Studierenden, projektbegleitendes Se | | | |---|---| | Online-, Hybrid- oder Präsenzunterricht | 42 h | -| Selbststudium (Lektüre und Projekt) | 78 h | +| Selbststudium (Skript, Lektüre und Projekt) | 78 h | | **Total** | **120 h (4 ECTS)** | ## Literatur -- *Modernes Software-Engineering: Entwurf und Entwicklung von Softwareprodukten* – Ian - Sommerville (Hauptanker). -- Ergänzend: *Fundamentals of Software Architecture* (Richards & Ford), *Building - Microservices* (Newman), *Refactoring* (Fowler) – nach Bedarf als Reader. -- Aktuelle wissenschaftliche Artikel und Branchenforschung im Bereich AI-Agenten, - agentische Entwicklungswerkzeuge und Evaluation von AI-Systemen. +**Leitmedium:** +- *AISE502 Lecture Notes -- A Theory of Architecture--Application Fit*, F. Herzog, + Fachhochschule Graubünden, 2026 (englisch; wird abgegeben). + +**Methodische Hauptquellen der Theorie:** +- L. Bass, P. Clements, R. Kazman: *Software Architecture in Practice*, 4. Aufl., 2021. +- M. Richards, N. Ford: *Fundamentals of Software Architecture*, 2. Aufl., O'Reilly, 2025. +- N. Ford, R. Parsons, P. Kua, P. Sadalage: *Building Evolutionary Architectures*, 2. Aufl., + O'Reilly, 2022. +- N. Forsgren, J. Humble, G. Kim: *Accelerate*, IT Revolution, 2018. + +**Begleitend:** +- I. Sommerville: *Modernes Software-Engineering*, Pearson, 2020 (deutschsprachiger Anker). +- S. Newman: *Building Microservices*, 2. Aufl., O'Reilly, 2021 (nach Bedarf als Reader). +- Aktuelle wissenschaftliche Artikel und Branchenforschung zu AI-Agenten, agentischen + Entwicklungswerkzeugen und Evaluation von AI-Systemen (u. a. DORA-Reports, METR). diff --git a/Modulbeschreibung_AISE502_v3_2026.md b/Modulbeschreibung_AISE502_v3_2026.md index 2202add..4be21e2 100644 --- a/Modulbeschreibung_AISE502_v3_2026.md +++ b/Modulbeschreibung_AISE502_v3_2026.md @@ -6,8 +6,8 @@ | **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) | --- @@ -59,7 +59,7 @@ Beispiele zuerst, Verallgemeinerung danach. Jedes Pattern wird aus dem realen Pr 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 +("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 @@ -138,7 +138,7 @@ Nach erfolgreichem Abschluss dieses Moduls sind die Studierenden in der Lage: | 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 | ### Nachprüfung @@ -147,7 +147,7 @@ Gemäss Rahmenprüfungsordnung. ### Unterrichtssprache -Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Übungen, Paper) in Englisch. +Deutsch. Sämtliche Unterlagen (Vorlesungsskript, Folien, Übungen, Paper) in Englisch. ### Eingangskompetenzen @@ -157,132 +157,196 @@ 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 -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. +**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). -**1. 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). +**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. -**2. 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. +**3. Angebot, Passung und Entscheidungsprotokoll** *(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).** -**3. 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. - -**4. Patterns I: Ein Deployable** *(Teil II)* +**4. Patterns I: ein Deployable** *(Teil II, §8--10)* - Inhalte: Schichtenarchitektur, modularer Monolith, Hexagonal/Ports-and-Adapters -- je: - reales Ursprungsproblem, Topologie, dimensionsweises Fähigkeitsprofil, + reales Ursprungsproblem, Topologie, Architecture Quantum, 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. + 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)* +**5. Patterns II: verteilte Topologien** *(Teil II, §11--12)* - 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. + 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; 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). +**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. 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. +**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. 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. +**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. 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). +**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)* -- 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. +**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: 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. +**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. 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. +**12. 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. 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. +**13. Achse B: Bedrohungen, verschobene Matrix, Agenten-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-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. +**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 verteilte Analyse- und +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; 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.** +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; + 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. @@ -290,19 +354,38 @@ Ingestion und Evaluation, orchestrierter Advisor-Agent hinter einem LLM-Gateway. **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". +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). --- +## 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. @@ -342,6 +425,7 @@ Zusammenarbeit mit anderen Studierenden, projektbegleitendes Selbststudium. **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/~$semesterinformation_HS26_AISE502_AIinSE2.xlsx b/~$semesterinformation_HS26_AISE502_AIinSE2.xlsx new file mode 100644 index 0000000..fb39bd6 Binary files /dev/null and b/~$semesterinformation_HS26_AISE502_AIinSE2.xlsx differ