983 lines
112 KiB
HTML
983 lines
112 KiB
HTML
<!doctype html><html lang="en"><head><meta charset="utf-8"><title>AISE502 – Moodle preview</title>
|
||
<style>
|
||
body { font-family: -apple-system, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; font-size: 15px;
|
||
color: #1d2125; background: #f4f6f8; margin: 0; padding: 24px; }
|
||
.page { max-width: 1100px; margin: 0 auto; }
|
||
.section { background: #fff; border: 1px solid #dee2e6; border-radius: 10px; padding: 18px 26px; margin: 0 0 18px 0; }
|
||
.section > h3 { font-weight: 400; font-size: 1.35rem; margin: 4px 0 18px 0; }
|
||
.section h4 { font-weight: 400; font-size: 1.25rem; margin: 22px 0 10px 0; }
|
||
.section h5 { font-weight: 600; font-size: 1.02rem; margin: 20px 0 8px 0; }
|
||
ul { margin: 4px 0 10px 0; padding-left: 26px; } li { margin: 3px 0; }
|
||
p { margin: 8px 0; line-height: 1.45; }
|
||
.toc a { margin-right: 14px; white-space: nowrap; }
|
||
</style>
|
||
</head><body><div class="page"><p class="toc"><strong>AISE502 · Moodle sections (preview, not for pasting)</strong><br><a href="#s0">Week 1</a> <a href="#s1">Week 2</a> <a href="#s2">Week 3</a> <a href="#s3">Week 4</a> <a href="#s4">Week 5</a> <a href="#s5">Week 6</a> <a href="#s6">Week 7</a> <a href="#s7">Week 8</a> <a href="#s8">Week 9</a> <a href="#s9">Week 10</a> <a href="#s10">Week 11</a> <a href="#s11">Week 12</a> <a href="#s12">Week 13</a> <a href="#s13">Week 14</a> <a href="#s14">📘 Lecture script</a> <a href="#s15">🛠️ Project exercise</a></p>
|
||
<div class="section" id="s0"><h3>Week 1: Architecture as a Decision Problem</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 1
|
||
Section title (Edit section → Section name): Week 1: Architecture as a Decision Problem
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 1 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_01.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can explain, using the four production systems, why no structure dominates and why each failure was a mismatch.</li>
|
||
<li>I know Maxim 1: patterns are neither good nor bad; only the fit is.</li>
|
||
<li>I can explain architecture as hard-to-reverse structural decisions and distinguish it from design and implementation by cost of change.</li>
|
||
<li>I can name the five elements of the framework: R(a), C(p), fit(a,p), ADR, measurement contract.</li>
|
||
<li>I can explain the two AI axes: Axis A (tool in the process), Axis B (runtime component).</li>
|
||
<li>I know the six assumptions A1–A6 and which framework element each one justifies.</li>
|
||
<li>I can derive Maxim 2 – match, document, measure – from assumptions A1, A2, A3 and A5.</li>
|
||
<li>I can explain why the twelve dimensions D1–D12 are recurring, measurable engineering questions in five groups.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 1: Architecture as a Decision Problem</strong> · 2 lessons lecture + 2 lessons exercise<br>
|
||
This lecture introduces the module and frames architecture selection as a decidable matching problem: four production systems, two facts, a five-element framework, six assumptions A1–A6, two maxims.</p>
|
||
<ul>
|
||
<li>Four production systems (Stack Overflow, Monzo, Segment, Prime Video) show two facts: structures differ radically for similar problems, and no structure dominates; the failures were mismatches, not bad patterns.</li>
|
||
<li>Maxim 1: patterns are neither good nor bad; only the fit between a requirements profile and a capability profile is. The decision problem: choose among non-dominated alternatives, expensive to reverse.</li>
|
||
<li>Architecture = the hard-to-reverse structural decisions that determine quality behaviour; design and implementation are cheaper to reverse. ISO/IEC/IEEE 42010:2022 obliges recording decisions with rationale. Two refusals: no fashion, no taste.</li>
|
||
<li>Five framework elements: requirements profile R(a) (demand), capability profile C(p) (supply), the ordinal, non-compensatory fit(a,p), the ADR and the measurement contract; both profiles span the same twelve dimensions.</li>
|
||
<li>AI enters twice: Axis A, a tool in the development process (changing how we decide); Axis B, a runtime component bringing non-determinism, latency and per-call cost (changing what we decide).</li>
|
||
<li>Load-bearing assumptions: A1 architecture = hard-to-reverse decisions (justifies the ADR); A2 everything is a trade-off, dominance does not occur (matching problem); A3 quality attributes, not functionality, drive architecture (twelve dimensions).</li>
|
||
<li>A4 requirements = measurable scenarios (demand-side method); A5 a decision is a hypothesis, continuously tested (measurement contract); A6 AI extends the space, not the method (D12 plus eval harness).</li>
|
||
<li>Maxim 2: architecture selection is matching (A2, A3); the match must be documented and continuously measured (A1, A5). The red line: demand → supply → match → record → test.</li>
|
||
<li>Three observations: engineering questions recur, ask how well rather than what, and each has a number; the twelve dimensions D1–D12 are these questions – grouped in five groups, named, measurable.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 1 <em>(added below by the lecturer)</em> · Script: Part I – Sections 1 (The Decision Problem) and 2 (The Coordinate System: Twelve Profile Dimensions). Section 2: introduced this week, completed in week 2.</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part I – Sections 1 (The Decision Problem) and 2 (The Coordinate System: Twelve Profile Dimensions). Section 2: introduced this week, completed in week 2.</p>
|
||
<p><strong>🧩 Exercise session:</strong> Project kickoff: form teams, set up repository and tooling including agentic coding tools, build domain understanding, sketch a first ontology and collect raw stakeholder wishes.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M1 – Requirements and Ontology (weeks 1–3)</p>
|
||
<ul>
|
||
<li>Form your team and set up the project: repository, environment and agentic coding tools.</li>
|
||
<li>Build domain understanding of the investment domain and sketch a first domain model and ontology.</li>
|
||
<li>Collect raw stakeholder wishes – unfiltered, unweighted; next week they become scenarios, in week 3 your requirements profile (Deliverable A1).</li>
|
||
<li>Study the exercise sheet: the AI-augmented portfolio intelligence platform – prices and news in, deterministic services, an LLM Insight component, a multi-agent advisor, API-first.</li>
|
||
</ul>
|
||
<p><em>No deliverable is due this week.</em></p>
|
||
</div>
|
||
<div class="section" id="s1"><h3>Week 2: The Twelve Dimensions – and How Requirements Become Measurable</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 2
|
||
Section title (Edit section → Section name): Week 2: The Twelve Dimensions – and How Requirements Become Measurable
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 2 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_02.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can name the twelve profile dimensions D1–D12, their five groups and the recurring question behind each.</li>
|
||
<li>I can give a response measure and a measurement instrument for each dimension – no instrument, no dimension.</li>
|
||
<li>I know the three admission conditions for a dimension and the ISO/IEC 25010:2023 changes relevant to AI systems.</li>
|
||
<li>I can distinguish quality attribute requirements from functional requirements and explain why only the former drive structure.</li>
|
||
<li>I can explain what an architecturally significant requirement (ASR) is and why it must be elicited in a QAW.</li>
|
||
<li>I can construct a six-part quality attribute scenario with a numeric response measure, also for an AI component.</li>
|
||
<li>I can derive the twelve weights from a utility tree: (H,H) leaves under an attribute give High.</li>
|
||
<li>I can assemble R(a) from weights, workload shape S(a) and hard constraints K(a), treating constraints as knock-out filters.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 2: The Twelve Dimensions – and How Requirements Become Measurable</strong> · 2 lessons lecture + 2 lessons exercise<br>
|
||
This lecture completes the twelve profile dimensions D1–D12, each with its measurement instrument, then builds the demand side R(a): scenarios, QAW, utility tree, workload shape and hard constraints.</p>
|
||
<ul>
|
||
<li>Twelve dimensions: load and speed (D1–D3), correctness and trust (D4–D6), change and delivery (D7–D9), economics and organisation (D10–D11), AI integrability (D12); each admitted only with standard anchoring, discrimination and instrumentation.</li>
|
||
<li>No instrument, no dimension: D1–D6 measure throughput at k× replication, sustained ingest rate, p50/p95/p99 latency, invariant violations (target 0 for ledgers), SLO attainment and blast radius, audit-trail reconstruction time.</li>
|
||
<li>D7–D11 measure change dispersion and boundary violations, time from empty repository to first release, deployment frequency and change failure rate, cost per request, deployments per developer per day.</li>
|
||
<li>D12 needs a queue, a port and a measurement point, instrumented by the eval harness; ISO/IEC 25010:2023 (Safety, Flexibility, Security with resistance) supplies the names without private extensions (assumption A6).</li>
|
||
<li>ASRs are vague and implicit: a Quality Attribute Workshop (QAW) elicits them; the six-part scenario with a response measure makes them testable and needs no extension for AI components (assumption A6).</li>
|
||
<li>The utility tree (ATAM) rates each leaf H/M/L on business importance and achievement difficulty; (H,H) leaves under an attribute make that dimension High – a veto claim in the match.</li>
|
||
<li>R(a) = (w1, …, w12; S(a); K(a)) – weights, measured workload shape, constraints as knock-out filters, never weights; for the advisory platform C10: High on D6, D7, D9, D10, D12.</li>
|
||
<li>Maxim 6. An architecture decision without a response measure is an opinion; with a response measure and a fitness function it is a testable hypothesis.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 2 <em>(added below by the lecturer)</em> · Script: Part I – Sections 2 (The Coordinate System: Twelve Profile Dimensions) and 3 (Constructing the Demand Side: The Requirements Profile R(a)). Section 2: completed this week.</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part I – Sections 2 (The Coordinate System: Twelve Profile Dimensions) and 3 (Constructing the Demand Side: The Requirements Profile R(a)). Section 2: completed this week.</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Bring the raw stakeholder wishes collected at the kickoff – unfiltered and unweighted; this week they become scenarios.</li>
|
||
<li>Have the kickoff outputs in place: team, repository and tooling (including agentic coding tools), domain understanding, first ontology sketch.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> Requirements workshop I: in stakeholder roles the team runs a compressed QAW, refines the top scenarios into the six-part form with numeric response measures and begins the utility tree.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M1 – Requirements and Ontology (weeks 1–3)</p>
|
||
<ul>
|
||
<li>Run a compressed QAW in stakeholder roles (retail customer, compliance officer, operations engineer, product owner): brainstorm, consolidate and prioritise scenarios from your raw stakeholder wishes.</li>
|
||
<li>Refine the top candidates into six-part scenarios, each with a numeric response measure: at least eight scenarios, at least three for the AI components (answer correctness, token cost per request, provider migration).</li>
|
||
<li>Assemble a first utility tree and identify the (H,H) leaves – they become the weights of your requirements profile R(platform) in week 3 (Deliverable A1).</li>
|
||
<li>Keep the domain model and ontology of the investment domain moving – both belong to the M1 requirements dossier.</li>
|
||
</ul>
|
||
<p><em>No deliverable is due this week.</em></p>
|
||
</div>
|
||
<div class="section" id="s2"><h3>Week 3: The Supply Side, the Match, and the Decision Record</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 3
|
||
Section title (Edit section → Section name): Week 3: The Supply Side, the Match, and the Decision Record
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 3 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_03.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I know the seven candidate patterns L, MM, HX, MS, EDA, PF, SL and their signature strength and cost.</li>
|
||
<li>I can distinguish an architectural pattern from an architectural tactic and explain why the framework keeps them apart.</li>
|
||
<li>I can derive a capability rating c_i(p) from tactics, published star ratings and documented production systems.</li>
|
||
<li>I can explain, via tactics, why EDA rates ++ on D7 and MS rates −− on D4.</li>
|
||
<li>I can run the three-stage, non-compensatory fit procedure: knock-outs and shape gate, vetoes, ordinal reading with sensitivity analysis.</li>
|
||
<li>I can defend the C10 mini-match verdict against L, MM and MS and explain why the MS veto relaxes.</li>
|
||
<li>I can explain why a weighted sum over ordinal ratings fails its three preconditions and produces pseudo-precision.</li>
|
||
<li>I can record an architecture decision as a MADR (drivers, options, consequences) and attach a measurement contract.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 3: The Supply Side, the Match, and the Decision Record</strong> · 2 lessons lecture + 2 lessons exercise<br>
|
||
Lecture 3 completes Part I: the supply side C(p) from tactics, the three-stage non-compensatory match run live on C10, and the decision record (ADR/MADR) with its measurement contract.</p>
|
||
<ul>
|
||
<li>Seven candidates form the set P (L, MM, HX, MS, EDA, PF, SL), each with a signature strength and cost; HX composes with the other six rather than competing.</li>
|
||
<li>Patterns are macro-structures that bundle tactics (elementary design decisions on one quality attribute); the chain topology → tactics → responses makes every ++ and −− explainable by construction.</li>
|
||
<li>An ordinal rating c_i(p) is derived from tactics analysis, then published star ratings (deviations footnoted), then documented production systems; C(p) = (c_1(p), …, c_12(p); S(p)) adds the native workload shape.</li>
|
||
<li>The three-stage match fit(a,p) is non-compensatory: knock-outs and the workload-shape gate; vetoes on High dimensions, liftable only by documented mitigations; ordinal reading with sensitivity analysis – a ranking with exclusions.</li>
|
||
<li>Mini-match R(C10) against L, MM, MS: L fails two unmitigated vetoes (−), the MS cost veto relaxes under mitigation (○), the hexagonal modular monolith wins (++) – the project architecture.</li>
|
||
<li>A weighted sum fails three preconditions (cardinal scales, preferential independence, weights as trade-off rates) and yields pseudo-precision; the 7 × 10 matrix is an explication instrument, not a computation.</li>
|
||
<li>An ADR records one decision (title, status, context, decision, consequences): co-located in the repository, brief, immutable. MADR adds decision drivers and considered options – one matrix row in narrative form.</li>
|
||
<li>Every ADR ends with a measurement contract: fitness functions and thresholds as CI gates, automated tests and telemetry alarms, DORA metrics in operation; a breach leads to a superseding ADR.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 3 <em>(added below by the lecturer)</em> · Script: Part I – Sections 4 (Constructing the Supply Side: The Capability Profile C(p)), 5 (The Match: fit(a,p)) and 6 (Recording and Testing the Decision).</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part I – Sections 4 (Constructing the Supply Side: The Capability Profile C(p)), 5 (The Match: fit(a,p)) and 6 (Recording and Testing the Decision).</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Bring the results of requirements workshop I (QAW scenarios and utility tree) – A1 is due at the end of week 3.</li>
|
||
<li>Have R(C10) from Lecture 2 at hand: the worked mini-match runs the advisory platform against three candidates.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> Requirements workshop II: teams finalise R(platform) – weights, workload shape and knock-out constraints – fix the ontology as a contract, and complete the A1 requirements dossier (scenarios, utility tree, R(a)).</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M1 – Requirements and Ontology (weeks 1–3)</p>
|
||
<ul>
|
||
<li>Finalise R(platform) – weights, workload shape and hard constraints (the knock-outs of stage 1).</li>
|
||
<li>Finalise the domain model and fix the ontology of the investment domain as a contract.</li>
|
||
<li>Check the scenario set: at least eight quality attribute scenarios with response measures, at least three for the AI components (answer correctness, token cost per request, provider migration), plus the utility tree.</li>
|
||
<li>Confirm that the project and tooling setup (repository, environment, agentic dev tools) is complete.</li>
|
||
<li>Deliver A1 (end of week 3): the requirements dossier – scenarios, utility tree and R(platform) with weights, workload shape and hard constraints.</li>
|
||
</ul>
|
||
<div style="border-left:4px solid #1b6ec2; background:#eef5fc; padding:8px 12px; margin:10px 0;">📌 <strong>Due this week:</strong> Deliverable A1 (end of week 3): requirements dossier</div>
|
||
</div>
|
||
<div class="section" id="s3"><h3>Week 4: Patterns I – Layered, Modular Monolith, Hexagonal</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 4
|
||
Section title (Edit section → Section name): Week 4: Patterns I – Layered, Modular Monolith, Hexagonal
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 4 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_04.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can derive a capability profile C(p) from a pattern's problem and topology, with a structural reason per cell.</li>
|
||
<li>I know the vocabulary of the three patterns: architecture quantum, technical versus domain partitioning, bounded context, ports and adapters.</li>
|
||
<li>I can explain why L rates ++ on D4, D8, D10 yet pays on every axis of change and scale.</li>
|
||
<li>I can read the MM column against L and show what domain partitioning buys at constant quantum count.</li>
|
||
<li>I can explain why boundary conformance in a modular monolith must be a CI subject, not a diagram convention.</li>
|
||
<li>I know the hexagonal dependency rule: adapters depend on ports, the core depends on nothing outside itself.</li>
|
||
<li>I can explain why an HX port is the anti-corruption layer that makes an LLM component swappable and mockable.</li>
|
||
<li>I can judge which of L, MM or MM+HX carries a requirements profile, using the selection signals.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 4: Patterns I – Layered, Modular Monolith, Hexagonal</strong> · 2 lessons lecture + 2 lessons exercise<br>
|
||
This lecture opens Part II and derives the capability profiles of L, MM and HX inductively – problem, topology, twelve dimensions, engineering consequences, and open-source systems to build and study.</p>
|
||
<ul>
|
||
<li>L partitions a system into horizontal technical layers with a downward dependency rule; the whole system is exactly one architecture quantum – one unit of deployment, scaling and failure.</li>
|
||
<li>L buys the lowest entry cost in the catalogue (++ on D4, D8, D10) and pays on every axis of change and scale – a specific trade, not a defect.</li>
|
||
<li>MM keeps one deployable but partitions its interior by domain: each module owns one bounded context and its data and communicates only through published module APIs or in-process events.</li>
|
||
<li>Against L at constant quantum count, MM's domain cut lifts D7 and D9 from − to + while D4 and D10 stay ++; the price is permanent boundary governance.</li>
|
||
<li>Boundary conformance is a CI subject (ArchUnit, Spring Modulith, Packwerk), not a matter of good intentions; the default: domain partitioning now, distribution only when a measured requirement demands it.</li>
|
||
<li>HX organises dependencies: the core defines technology-neutral ports, adapters plug in, all source-code dependencies point inwards; not a distribution style but a delta profile that composes with the other six.</li>
|
||
<li>HX's delta: ++ on D7 (technology migrations become localised adapter tasks), D9 (hermetic domain tests) and D12 (an imposed anti-corruption layer for LLM components), bought with − on D8.</li>
|
||
<li>L → MM isolates the partitioning axis and HX composes on top: the hexagonal modular monolith won last week's C10 mini-match and is the project's architecture.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 4 <em>(added below by the lecturer)</em> · Script: Part II – Sections 8 (L – Layered Architecture / 3-Tier), 9 (MM – Modular Monolith) and 10 (HX – Hexagonal Architecture / Ports and Adapters).</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part II – Sections 8 (L – Layered Architecture / 3-Tier), 9 (MM – Modular Monolith) and 10 (HX – Hexagonal Architecture / Ports and Adapters).</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Bring the finalised R(platform) from Deliverable A1 (weights, workload shape, knock-out constraints) – this week's exercise shortlists L, MM and MM+HX against it.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> Architecture study I (2 lessons): the teams inspect Apache Fineract and cosmicpython/code for boundaries and ports, shortlist L, MM or MM+HX for the platform core against R(platform) from A1, and draft the C4 context and container diagrams.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)</p>
|
||
<ul>
|
||
<li>Inspect Apache Fineract (34 fineract-* Gradle modules composed into one deployable, plus a custom/ extension directory) and cosmicpython/code (domain/, service_layer/, adapters/, entrypoints/) – find the boundaries, find the ports.</li>
|
||
<li>Apply the two-minute habit first: check licence and maintenance status (last commit, open issues) – one of this week's study objects carries a no-derivatives licence, and finding it yourself is part of the exercise.</li>
|
||
<li>Shortlist candidates for the platform core – which of L, MM or MM+HX carries your requirements profile R(platform) from A1? – and begin evaluating candidate architectures for the deterministic core and the edges.</li>
|
||
<li>Draw the C4 context and container diagrams of your platform draft; the C4-style diagram is part of the architecture dossier (Deliverable A2, end of week 7).</li>
|
||
<li>Do not start production code before the design-review gate at the end of week 7; exploratory spikes are allowed.</li>
|
||
</ul>
|
||
<p><em>No deliverable is due this week.</em></p>
|
||
</div>
|
||
<div class="section" id="s4"><h3>Week 5: Patterns II – Microservices and Event-Driven Architecture</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 5
|
||
Section title (Edit section → Section name): Week 5: Patterns II – Microservices and Event-Driven Architecture
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 5 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_05.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can derive the MS and EDA capability profiles from their tactics and quantum boundaries, cell by cell.</li>
|
||
<li>I can explain why compensation in a saga is not rollback and why D4 = −− is structural for MS.</li>
|
||
<li>I can judge when MS is legitimately forced (D11 measurably binding) and when to avoid it.</li>
|
||
<li>I know the distributed monolith and its measures: lockstep release ratio, cross-service change dispersion, synchronised version bumps.</li>
|
||
<li>I can distinguish the broker and mediator topologies of EDA and name what each gives and takes.</li>
|
||
<li>I can explain EDA's threefold decoupling and why D4, D8 and D9 are the same coin's other side.</li>
|
||
<li>I can explain why EDA is rated ++ on D12: queues absorb what LLMs are worst at.</li>
|
||
<li>I know the seven resilience primitives for distributed edges and the measure attached to each.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 5: Patterns II – Microservices and Event-Driven Architecture</strong> · 2 lessons lecture + 2 lessons exercise<br>
|
||
This lecture derives the capability profiles of the two distributed patterns, MS and EDA, from their tactics and quantum boundaries, and introduces the resilience primitives for distributed edges.</p>
|
||
<ul>
|
||
<li>MS and EDA form the catalogue's distributed half: MS distributes by domain, EDA decouples in time; both multiply quanta and pay D8 = −− before the first feature ships.</li>
|
||
<li>MS – services around business capabilities, one quantum each, database per service – is the only pattern rated ++ on D11: adopt for measured organisational scale, never for traffic alone.</li>
|
||
<li>The bill is structural: D4 = −− because cross-service consistency needs sagas, and compensation is not rollback; D8 and D10 = −− because the premium is platform staffing.</li>
|
||
<li>The distributed monolith is the most common failure outcome, measurable as lockstep release ratio; Monzo and Segment show viability depends on where boundaries run (Maxim 4) and central platform investment.</li>
|
||
<li>EDA connects asynchronously decoupled producers and consumers through a messaging substrate; they share event schemas, never knowledge of each other. Broker topology maximises scaling, mediator topology gives workflow visibility.</li>
|
||
<li>EDA's decoupling is threefold (topology, time, organisation); eventual consistency moves correctness into the design, keeping D4 and D8 at −− and D9 at −; no broker removes the trade.</li>
|
||
<li>EDA is rated ++ on D12: queues absorb LLM latency, rate limits and outages, and the event log doubles as audit journal; EDA takes the project's edges, MM+HX core unchanged.</li>
|
||
<li>The seven resilience primitives – timeout, retry with backoff, circuit breaker, bulkhead, fallback, dead-letter queue, idempotent consumer – are constitutive tactics, each becoming a fitness function in the measurement contract.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 5 <em>(added below by the lecturer)</em> · Script: Part II – Sections 11 (MS – Microservices) and 12 (EDA – Event-Driven Architecture).</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part II – Sections 11 (MS – Microservices) and 12 (EDA – Event-Driven Architecture).</p>
|
||
<p><strong>🧩 Exercise session:</strong> Architecture study II (2 lessons): teams design the edges of their platform – the ingestion queue and resilience against external-API failure – sketch the service contracts and run the matrix pre-filter of the candidate patterns against their A1 requirements profile.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)</p>
|
||
<ul>
|
||
<li>Design the edges of your platform: the ingestion queue for analysis requests, and resilience against external-API failure – timeouts, retries with backoff, circuit breaker, fallback and DLQ on every external call.</li>
|
||
<li>Sketch the service contracts: which events exist, which schemas, who produces and who consumes.</li>
|
||
<li>Run the matrix pre-filter: hold your A1 requirements profile R(platform) against all candidate patterns seen so far and record which survive stage 1 (shape gate) and stage 2 (vetoes) – next week's full three-stage match builds on it.</li>
|
||
<li>Study this week's reference systems: Google's Online Boutique (twelve polyglot services, gRPC contracts) and Home Assistant's homeassistant/core.py (Event, EventBus, async_fire) – read exactly that one file.</li>
|
||
<li>Record the edge design and contracts in the M2 architecture dossier (bounded contexts → service decomposition and contracts); production code starts only after the design-review gate – exploratory spikes are allowed.</li>
|
||
</ul>
|
||
<p><em>No deliverable is due this week.</em></p>
|
||
</div>
|
||
<div class="section" id="s5"><h3>Week 6: Pipelines, Serverless, the View Across – and Your Class (C10)</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 6
|
||
Section title (Edit section → Section name): Week 6: Pipelines, Serverless, the View Across – and Your Class (C10)
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 6 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_06.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can derive C(PF) and C(SL) from their tactics and explain their defining cells (PF's D3, SL's split D10).</li>
|
||
<li>I know the architecture quantum – the joint unit of deployment, scaling and failure – and each pattern's quantum count.</li>
|
||
<li>I can explain the capability table through Maxims 3 and 4: quantum count and partitioning axis.</li>
|
||
<li>I can read the consolidated capability table ordinally – rankings and exclusions, never weighted sums.</li>
|
||
<li>I can explain why agent orchestration is a composition pattern, not an eighth style, and defend “workflows before agents”.</li>
|
||
<li>I can construct the C10 requirements profile: its five High dimensions, three binding scenarios, shape and constraints.</li>
|
||
<li>I can explain why weights, not dimensions, define a class, using the C1/C2 mirror pair.</li>
|
||
<li>I can run the three-stage match for the project platform and record the decision as an ADR draft.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 6: Pipelines, Serverless, the View Across – and Your Class (C10)</strong> · 2 lessons lecture + 2 lessons exercise<br>
|
||
Lecture 6 closes the pattern catalogue with PF and SL, reads all seven columns side by side (Maxims 3 and 4), and opens Part III with C10, your project's class.</p>
|
||
<ul>
|
||
<li>PF: D3 = −− is its definition – makespan and reproducibility, a third consistency semantics (“as of last run”); most deterministically testable pattern, natural home of ingestion, training and evals.</li>
|
||
<li>SL – event-triggered, short-lived, stateless functions; pay per execution, own no capacity. Load shape dominates the profile: D10 = ++/−− inverts (Prime Video) and does not average to ○ (neutral).</li>
|
||
<li>Architecture quantum: independently deployable unit. Maxim 3: one quantum → cheap, simple, consistent, rigid; many → expensive, complex, eventually consistent, elastic. Maxim 4: domain-oriented partitioning, not deployment-unit count, predicts evolvability.</li>
|
||
<li>The consolidated table: no column dominates – a matching problem exists (assumption A2); ordinal reading, never weighted sums; every cell is a default hypothesis, two documented to invert with context.</li>
|
||
<li>Agent orchestration is a composition pattern reusing the catalogue's topologies, not an eighth style; workflows before agents – multi-agent beat single-agent by 90.2 % at 15× the tokens.</li>
|
||
<li>C10 – AI-native advisory platforms, the project's class: Highs D6/D7/D9/D10/D12 (accountability, churn, evals, cost per request, containment); binding scenarios S1–S3; shape hybrid interactive + batch/async; K(a): EU AI Act, GDPR.</li>
|
||
<li>C10 stress-tests the method: inherits C6/C7/C3, adds token budget and eval harness; verdict: hexagonal modular monolith with LLM gateway, PF for ingestion and evals, EDA for job and audit spine.</li>
|
||
<li>C1 and C2 are mirror images across the consistency/availability trade – inverted weights on D1 and D4, verdicts MM+HX core versus EDA+MS hybrid. Weights, not dimensions, define a class.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 6 <em>(added below by the lecturer)</em> · Script: Part II – Sections 13 (PF – Pipes-and-Filters / Batch Pipeline), 14 (SL – Serverless / FaaS), 15 (Stepping Back: What Seven Patterns Generalise To), 16 (Reading the Catalogue as a Whole) and 17 (Outlook: Agent Orchestration as an Emergent Composition Pattern); Part III – Section 28 (C10 – AI-Native Advisory Platforms). Sections 19–20: preview of the C1/C2 mirror pair only; read in full in week 8.</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part II – Sections 13 (PF – Pipes-and-Filters / Batch Pipeline), 14 (SL – Serverless / FaaS), 15 (Stepping Back: What Seven Patterns Generalise To), 16 (Reading the Catalogue as a Whole) and 17 (Outlook: Agent Orchestration as an Emergent Composition Pattern); Part III – Section 28 (C10 – AI-Native Advisory Platforms). Sections 19–20: preview of the C1/C2 mirror pair only; read in full in week 8.</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Bring last week's matrix pre-filter: which candidate patterns survived stage 1 (shape gate) and stage 2 (vetoes) against your A1 requirements profile – the full match builds on it.</li>
|
||
<li>Bring your edge design and service-contract sketch from week 5 (ingestion queue, resilience measures on external calls, events and schemas).</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> The match: each team runs the full three-stage procedure against its A1 requirements profile – knock-out with the shape gate, veto with documented mitigations, ordinal reading with sensitivity check – takes the decision and begins the ADR.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)</p>
|
||
<ul>
|
||
<li>Run the full three-stage match for your platform against your A1 requirements profile R(platform), starting from last week's pre-filter.</li>
|
||
<li>Stage 1, knock-out: apply the hard constraints K(a) and the workload-shape gate (S(a) versus S(p)) – which candidates cannot carry the core?</li>
|
||
<li>Stage 2, veto: hold every High weight against the capability columns – which vetoes fire, and which have documented mitigations?</li>
|
||
<li>Stage 3, ordinal reading: rank the survivors on the High set and run the sensitivity check; then take the decision and begin the ADR (MADR: drivers, options, consequences, confirmation).</li>
|
||
<li>Keep Deliverable A2 in view: architecture dossier + design-review gate at the end of week 7; production code starts only after the gate (exploratory spikes are allowed).</li>
|
||
</ul>
|
||
<p><em>No deliverable is due this week.</em></p>
|
||
</div>
|
||
<div class="section" id="s6"><h3>Week 7: The Fit, Formally – Three Cases, the Procedure, the Matrix</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 7
|
||
Section title (Edit section → Section name): Week 7: The Fit, Formally – Three Cases, the Procedure, the Matrix
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 7 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_07.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can explain why fit(a,p) is non-compensatory and what a weighted sum would have destroyed in C6, C1 and C2.</li>
|
||
<li>I can derive the C6 row from the workload-shape gate: six of seven cells emptied before any rating is scored.</li>
|
||
<li>I can distinguish an operational weakness (repaired by a tactic) from a structural one (made survivable under condition).</li>
|
||
<li>I can judge a flipped ordering under plausible weight variation as a finding (trade-off point), not an error.</li>
|
||
<li>I know that a matrix cell rates a pattern only as the dominant structure of a class's core.</li>
|
||
<li>I can read the matrix by columns and rows: MM as default, MS premium, workload-shaped PF/EDA, HX never negative.</li>
|
||
<li>I know the definition of an architectural fitness function, its scope and cadence classes, and the four DORA metrics.</li>
|
||
<li>I can defend an ADR at the design-review gate: vetoes fired, mitigations documented, what the sensitivity check showed.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 7: The Fit, Formally – Three Cases, the Procedure, the Matrix</strong> · 2 lessons lecture + 2 lessons exercise<br>
|
||
This lecture runs the three-stage match end to end on C6, C1 and C2, states the procedure formally, reads the 7 × 10 matching matrix and introduces the measurement contract.</p>
|
||
<ul>
|
||
<li>C6: the workload-shape gate alone empties six of seven cells before any scoring; only PF proceeds to Stages 2–3 and reaches ++ – run the cheapest test first.</li>
|
||
<li>C1: MS's structural −− on D4 (no cross-service ACID) fires the veto, lifted only to ○ under the Monzo condition; MM's operational D5 weakness is repaired by hot standby (++).</li>
|
||
<li>C2: MS and EDA survive to Stage 3; the sensitivity analysis flips the ordering under plausible variation – a trade-off point, not an error: the class needs both patterns, placed.</li>
|
||
<li>fit(a,p) is non-compensatory: knock-out and shape gate (read per constitutive path), veto on High-weight dimensions unless a documented mitigation exists, holistic ordinal reading with sensitivity analysis – no weighted sum.</li>
|
||
<li>Cell semantics: fit(a,p) rates p only as the dominant structure of the core of a; a − cell is not a prohibition; HX cells read as the core's internal discipline.</li>
|
||
<li>Column-wise: MM is primary or secondary in seven of ten classes (MonolithFirst); MS earns its premium only where read scalability, fault isolation and team scaling coincide (C2; conditionally C5, C8).</li>
|
||
<li>PF and EDA are workload-shaped, HX is never negative, no row or column is uniformly positive (assumption A2); Prime Video, Segment, Shopify, Uber and Stack Overflow sit on cell boundaries.</li>
|
||
<li>Measurement contract: fitness functions (dependency checks, budgets, chaos experiments) and the four DORA metrics as executable invariants – the architecture may change freely as long as the contract stays green.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 7 <em>(added below by the lecturer)</em> · Script: Part IV – Sections 30 (Three Matches, Three Stages), 31 (The Procedure in General), 32 (The Matching Matrix), 34 (Reading the Matrix as a Whole) and 37 (The Measurement Contract). Section 37: introduction only.</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part IV – Sections 30 (Three Matches, Three Stages), 31 (The Procedure in General), 32 (The Matching Matrix), 34 (Reading the Matrix as a Whole) and 37 (The Measurement Contract). Section 37: introduction only.</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Bring last week's exercise results: the three-stage match on your own platform (knock-out → veto → ordinal reading), the decision, and the ADR you began.</li>
|
||
<li>Prepare for the design-review gate: A2 (ADR + C4 + measurement contract) is due at the end of this week.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> The two-lesson exercise slot finalises the solution design (service cut and contracts, walking-skeleton plan, measurement contract) and holds the design-review gate at which each team defends its ADR – the last two-lesson slot before it becomes a one-lesson standup/coaching session from week 8.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M2 – Architecture Decision and Solution Design (weeks 4–7)</p>
|
||
<ul>
|
||
<li>Finalise the service cut and contracts: bounded contexts → service decomposition and the contracts between the deterministic core, the edges and the AI subsystem; record the decision as an ADR with rationale and a C4-style diagram.</li>
|
||
<li>Write the walking-skeleton plan: the thin end-to-end slice you will build first in Sprint 1 (M3: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight, stable API, placeholder UI).</li>
|
||
<li>Set the numbers in the measurement contract: a token-cost budget per request at p95 (family 2, cost budget as a pipeline gate), an eval threshold of pass rate ≥ 95 % on a versioned golden set before rollout, p95 latency ≤ 20 s for the advisory scenario, and zero module-boundary violations (family 1, dependency rules as CI gates, ArchUnit / import-linter style).</li>
|
||
<li>Pass the design-review gate: defend the ADR – which vetoes fired, which mitigations are documented, what the sensitivity check showed.</li>
|
||
<li>Submit Deliverable A2 (end of week 7): the architecture dossier – ADR + C4 diagram + measurement contract. Production code starts only after the gate (exploratory spikes are allowed); from week 8 the exercise slot becomes a one-lesson standup/coaching session and Sprint 1 (M3, walking skeleton) begins.</li>
|
||
</ul>
|
||
<div style="border-left:4px solid #1b6ec2; background:#eef5fc; padding:8px 12px; margin:10px 0;">📌 <strong>Due this week:</strong> Deliverable A2 (end of week 7): architecture dossier (ADR + C4 + measurement contract) + design-review gate</div>
|
||
</div>
|
||
<div class="section" id="s7"><h3>Week 8: Requirements Profiles I – Application Classes C1–C5</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 8
|
||
Section title (Edit section → Section name): Week 8: Requirements Profiles I – Application Classes C1–C5
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 8 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_08.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can define an application class as an ASR bundle and write it as R(a) = (w; S(a); K(a)).</li>
|
||
<li>I can derive a class's High weights from documented challenges and binding scenarios, each H a veto trigger.</li>
|
||
<li>I can place C1–C5 on the map of ten classes by workload shape and consistency semantics.</li>
|
||
<li>I know the binding scenarios, High weights, shape S(a) and constraints K(a) of classes C1 to C5.</li>
|
||
<li>I can explain, with LMAX and Monzo, why R(a) defines a feasible set rather than one pattern.</li>
|
||
<li>I can explain why C2 scales reads from a monolith yet moves to EDA+MS at measured organisational scale.</li>
|
||
<li>I can explain why D8 = H and D10 = H jointly veto premium-priced structures in C3.</li>
|
||
<li>I can explain why cross-module ACID binds C4 to one transactional quantum and makes MS the strongest anti-fit.</li>
|
||
<li>I can explain C5's hybrid consistency as a designed boundary that belongs in an ADR.</li>
|
||
<li>I can judge where an AI component may live in a topology by its latency class, not its accuracy.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 8: Requirements Profiles I – Application Classes C1–C5</strong> · 3 lessons lecture + 1 lesson standup/coaching<br>
|
||
Part III turns to the demand side: the requirements profiles of application classes C1–C5, derived from documented challenges and binding scenarios – every closing verdict a preview for Part IV.</p>
|
||
<ul>
|
||
<li>An application class is an ASR bundle, not an industry label: R(a) = (w; S(a); K(a)) – weights from the (H,H) leaves, S(a) gates the core, K(a) knocks out before scoring.</li>
|
||
<li>A weight is a compressed empirical claim, made auditable per class: documented challenges → binding scenarios with response measures → High weights; an H is a veto trigger, not a coefficient.</li>
|
||
<li>Regulation translates directly into structure (immutable journals, scope zoning); one organisation runs several classes, so the matrix is read per subsystem; classifying a system is a hypothesis, never a verdict.</li>
|
||
<li>The map of ten classes: workload shape × consistency semantics; C1–C5 all interactive – C1/C4 strict ACID, C3 ACID-leaning, C5 split by subsystem, C2 eventual; C1 and C2 form the mirror pair.</li>
|
||
<li>C1 core banking: D4/D5/D6/D7/D9 High, densest K(a); LMAX vs. Monzo – R(a) defines the feasible set, constraints decide within it; AI at the edge: agents propose, deterministic services decide and book.</li>
|
||
<li>C2 social media: 50:1 and the fan-out; D1/D3/D5/D7/D9/D11 High, D4 Low; Instagram scales reads from a monolith at 100 deployments/day – a monolith is an organisational problem, not a read-scaling problem.</li>
|
||
<li>C3 back-office, the modal case: ca. 60 % of life-cycle cost is evolution (D7 = H); D8 = H and D10 = H jointly veto premium-priced structures; verdict MM, workflow engine behind a port.</li>
|
||
<li>C4 ERP: integration is the product – cross-module ACID postings bind the class to one transactional quantum; MM the strongest alignment in the matrix, MS's −− on D4 the strongest anti-fit.</li>
|
||
<li>C5 e-commerce: quality attributes with price tags, 10–50× peaks, hybrid consistency as a designed boundary, PCI DSS v4.0 scope minimisation as structure; Shopify vs. Amazon – team size, not traffic, decides.</li>
|
||
<li>Side by side: D7 High in all five, D8/D10 High only in C3; verdict previews C1 MM+HX, C2 EDA+MS at measured organisational scale, C3/C4/C5 MM – Part IV recomputes every verdict.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 8 <em>(added below by the lecturer)</em> · Script: Part III – Sections 18 (Application Classes as Requirements Profiles), 19 (C1 – Core Banking / Transaction Systems), 20 (C2 – Social Media / Content Platforms), 21 (C3 – Back-Office / Workflow Applications), 22 (C4 – ERP / Enterprise Core Systems) and 23 (C5 – E-Commerce Platforms).</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part III – Sections 18 (Application Classes as Requirements Profiles), 19 (C1 – Core Banking / Transaction Systems), 20 (C2 – Social Media / Content Platforms), 21 (C3 – Back-Office / Workflow Applications), 22 (C4 – ERP / Enterprise Core Systems) and 23 (C5 – E-Commerce Platforms).</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Sprint 1 / M3 starts this week: bring the walking-skeleton plan from your A2 dossier (MarketDataService + minimal ResearchAgent + stable API).</li>
|
||
<li>Make sure Deliverable A2 and the design-review gate are complete – production code starts only after the gate (exploratory spikes are allowed).</li>
|
||
<li>Have the 7 × 10 matching matrix from Lecture 7 at hand: this week derives its rows C1–C5 from the demand side.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> The exercise slot becomes a one-lesson standup/coaching session as the implementation phase begins with Sprint 1 of the walking skeleton (M3); implementation happens mainly in self-study time.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M3 – Walking Skeleton (weeks 8–9)</p>
|
||
<ul>
|
||
<li>Start the walking skeleton (Sprint 1, M3) first thing in the implementation phase: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight, plus a stable API and a placeholder UI that calls it.</li>
|
||
<li>Keep the deterministic core free of LLM calls – agents propose, deterministic services decide and book; this is the line that is graded. Your deterministic services inherit the C3 verdict: ACID, boring on purpose.</li>
|
||
<li>Use a snapshot of market/news data so that demo and grading are reproducible.</li>
|
||
<li>Commit after each milestone and record architectural decisions as ADRs as you go.</li>
|
||
<li>Work towards the week-9 check: the walking skeleton runs end-to-end (M3).</li>
|
||
</ul>
|
||
<p><em>No deliverable is due this week.</em></p>
|
||
</div>
|
||
<div class="section" id="s8"><h3>Week 9: Classes C6–C9 – and Ten Profiles Side by Side</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 9
|
||
Section title (Edit section → Section name): Week 9: Classes C6–C9 – and Ten Profiles Side by Side
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 9 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_09.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can explain why C6 replaces the interactive vocabulary with makespan, batch-window adherence and cost per simulation.</li>
|
||
<li>I can distinguish the third consistency semantics – reproducibility and refresh contracts – from ACID and eventual consistency.</li>
|
||
<li>I know that C7 is an integration product over C1–C5 whose ADR to write is the freshness contract.</li>
|
||
<li>I can explain why C8's hard requirement is declared correctness semantics under failure, not throughput.</li>
|
||
<li>I can judge, per stream and per scenario, when at-least-once plus idempotence is legitimate instead of exactly-once.</li>
|
||
<li>I can explain why C9's binding load is connection fan-out and push, with concurrent-connection count as tiebreaker.</li>
|
||
<li>I can explain each H of C6–C9 as a veto trigger backed by a scenario with a response measure.</li>
|
||
<li>I can read the consolidated requirements table by columns and by rows, including its seventeen footnotes.</li>
|
||
<li>I can name the five cross-class observations, including that D11 High, not scale, forces microservices.</li>
|
||
<li>I can explain why the freshness contract appears twice in the course project's measurement contract.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 9: Classes C6–C9 – and Ten Profiles Side by Side</strong> · 3 lessons lecture + 1 lesson standup/coaching<br>
|
||
This lecture completes the demand side: classes C6–C9 in the same rhythm, then the consolidated requirements table with its seventeen footnotes and five cross-class observations.</p>
|
||
<ul>
|
||
<li>C6 replaces the interactive vocabulary: makespan, batch-window adherence and cost per simulation are the response measures; correctness means bit-level reproducibility from versioned inputs and seeds (Highs D2, D9, D10).</li>
|
||
<li>C6 and C7 define a third consistency semantics beside ACID and eventual: reproducibility (“as of this run”) and freshness by refresh contract (“as of yesterday 24:00”), contracts with response measures.</li>
|
||
<li>C7 is an integration product over C1–C5 (Highs D1, D10); the ADR to write is the freshness contract; tightening it towards real time is a class change into C8 economics.</li>
|
||
<li>The course project inherits C6 (ingestion and eval pipelines) and C7 (analytics); its freshness contract appears twice: as a pipeline fitness function and as a grounding rule for generated answers.</li>
|
||
<li>C8 must keep pace with the world indefinitely (Highs D2, D3, D5); the hard requirement is declared correctness semantics under failure; at-least-once plus idempotence is decided per stream, per scenario.</li>
|
||
<li>AI lens: C7 docks text-to-SQL onto the governed semantic layer, not onto raw tables; C8 rules out per-event LLM calls; models score events in the stream as checkpointed operators.</li>
|
||
<li>C9's binding load is connection fan-out and push (Highs D3, D5); same domain, four structures: scale and business model move the weights at the edges; concurrent-connection count is the tiebreaker.</li>
|
||
<li>In the consolidated requirements table an H is a veto trigger backed by a scenario, an L a licence not to pay; the seventeen footnotes are part of the semantics.</li>
|
||
<li>Five observations: read/write ratio and consistency semantics discriminate most; D11 High, not scale, forces microservices; rollbacks cut dataflows along technical seams; regulation lives in K(a); C10 inherits before it innovates.</li>
|
||
<li>The ten profiles are derivable, not arbitrary: weights trace to binding scenarios, constraints to statutes or contracts, workload shapes to production numbers – the other operand, R(a), is ready.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 9 <em>(added below by the lecturer)</em> · Script: Part III – Sections 24 (C6 – Scientific Simulation / Batch Compute), 25 (C7 – Decision Support / BI Analytics), 26 (C8 – Real-Time / IoT Streaming), 27 (C9 – Collaboration / Messaging) and 29 (Stepping Back: Ten Profiles Side by Side).</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part III – Sections 24 (C6 – Scientific Simulation / Batch Compute), 25 (C7 – Decision Support / BI Analytics), 26 (C8 – Real-Time / IoT Streaming), 27 (C9 – Collaboration / Messaging) and 29 (Stepping Back: Ten Profiles Side by Side).</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Have the walking skeleton ready for the milestone check M3 in the coaching session: it must run end-to-end.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> Coaching session (1 lesson): the teams finish the walking skeleton and the milestone check M3 takes place – the end-to-end thin slice must run.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M3 – Walking Skeleton (weeks 8–9)</p>
|
||
<ul>
|
||
<li>Finish the walking skeleton: the end-to-end thin slice runs – MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight, delivered through the stable API; a placeholder UI calls it.</li>
|
||
<li>Keep the deterministic core free of LLM calls – this is the line that is graded.</li>
|
||
<li>Use a snapshot of market and news data so that demo and grading are reproducible even if the live APIs misbehave.</li>
|
||
<li>Commit after the milestone and record your decisions as ADRs as you go.</li>
|
||
<li>Apply today's lecture: your ingestion and eval pipelines are C6, your analytics are C7 – the skeleton should already show where an Insight's freshness stamp comes from.</li>
|
||
</ul>
|
||
<div style="border-left:4px solid #1b6ec2; background:#eef5fc; padding:8px 12px; margin:10px 0;">📌 <strong>Due this week:</strong> Milestone check (week 9): walking skeleton runs end-to-end</div>
|
||
</div>
|
||
<div class="section" id="s9"><h3>Week 10: The Fit II – Hybrids, Evolution Paths, and the Decision Procedure</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 10
|
||
Section title (Edit section → Section name): Week 10: The Fit II – Hybrids, Evolution Paths, and the Decision Procedure
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 10 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_10.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can explain why hybrids are the normal case and what the unit of fit evaluation is.</li>
|
||
<li>I can explain why fit decays over time (Lehman's laws, assumption A5) and name the three migration strategies.</li>
|
||
<li>I can read the evolution-path diagram: MM is both sanctioned start state and consolidation target.</li>
|
||
<li>I know Maxim 5: buy options on tomorrow's profile via modules and ports, not speculative distribution.</li>
|
||
<li>I can name the eight steps of the decision procedure with the artefact and measurement of each.</li>
|
||
<li>I can distinguish a sensitivity point from a trade-off point and explain what a weight-variation flip means.</li>
|
||
<li>I know Maxim 6: without a response measure a decision is an opinion; with a fitness function, a testable hypothesis.</li>
|
||
<li>I can judge my A2 against the reference run ADR-007: options, vetoes, fitness functions, evolution path.</li>
|
||
<li>I can read a row rationale of the matrix: gate, veto, documented mitigation, primary recommendation, central trade-off.</li>
|
||
<li>I can defend the C10 verdict: a designed hybrid with the determinism boundary – agents propose, deterministic services decide and book.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 10: The Fit II – Hybrids, Evolution Paths, and the Decision Procedure</strong> · 3 lessons lecture + 1 lesson standup/coaching<br>
|
||
This lecture treats fit as a function of time (hybrids, evolution paths), then runs the eight-step decision procedure through ADR-007 and reads the ten matrix rows cell by cell.</p>
|
||
<ul>
|
||
<li>Eight of the ten primary recommendations of Section 33 are compositions; the unit of fit evaluation is the subsystem with its own architecture quantum, recorded in a C4 container diagram.</li>
|
||
<li>Fit is a function of time (Lehman's laws, assumption A5): every recommendation carries a migration strategy – MonolithFirst, Strangler Fig in both directions, sacrificial architecture; MM is start state and consolidation target.</li>
|
||
<li>Maxim 5: choose the pattern for the profile verifiable today and buy options on tomorrow's via module boundaries, ports and a strangler-ready seam – not via speculative distribution.</li>
|
||
<li>AI Lens: for a C10 system's AI layer, sacrificial architecture is the rational default – replaceable behind a port, eval harness as acceptance gate; the deterministic core is designed to last.</li>
|
||
<li>The matrix only pre-filters: eight steps – ASRs, scenarios with numbers, utility tree whose (H,H) leaves are the weights of R(a), matrix shortlist, ATAM-light, ADR, measurement contract, measure in operation.</li>
|
||
<li>Sensitivity point: one decision, large effect on one attribute; trade-off point: opposing effects on several attributes. A weight variation that flips the recommendation calls for stakeholder negotiation, not a formula.</li>
|
||
<li>Steps (vii)–(viii) are the genuinely new obligations. Maxim 6: a decision without a response measure is an opinion; with response measure and fitness function it is a testable hypothesis.</li>
|
||
<li>ADR-007 (reference run, class C10) narrates one matrix row: decision drivers are the utility-tree weights, considered options the matrix shortlist (auditable), the final section the measurement contract (falsifiable).</li>
|
||
<li>In the ten row rationales every cell is traceable to R(a) against C(p) – gate, veto, documented mitigation – plus primary recommendation and central trade-off; the recurring resolution: consistent core, asynchronous edges.</li>
|
||
<li>C10's verdict is a designed hybrid – hexagonal modular monolith core, pipelines, orchestrated agents, EDA spine secondary – governed by the determinism boundary: LLM agents propose, deterministic services decide and book.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 10 <em>(added below by the lecturer)</em> · Script: Part IV – Sections 35 (Hybrids and Evolution Paths), 36 (The Decision Procedure) and 33 (Cell Rationales: The Ten Rows in Detail).</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part IV – Sections 35 (Hybrids and Evolution Paths), 36 (The Decision Procedure) and 33 (Cell Rationales: The Ten Rows in Detail).</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Have your A2 dossier (ADR, C4 container diagram, measurement contract) at hand – the lecture holds it against the reference run ADR-007.</li>
|
||
<li>Make sure the walking skeleton runs end-to-end (M3 check, week 9) before M4 starts this week.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> The exercise slot is one lesson of standup/coaching for milestone M4: implementing the deterministic Performance, Risk and Optimization services with exact tests against the reference vectors.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M4 – Deterministic Core and Resilience (weeks 10–11)</p>
|
||
<ul>
|
||
<li>Implement the Performance, Risk and Optimization services and test them fully against the reference vectors – exact tests, not approximate ones.</li>
|
||
<li>Pin the deterministic services with tests before you trust any agent output.</li>
|
||
<li>Keep the deterministic core free of LLM calls – this is the line that is graded (ADR-007's determinism boundary: agents propose, deterministic services decide and book).</li>
|
||
<li>Commit after the milestone and record architectural decisions as ADRs as you go – a revised decision is a new, superseding ADR.</li>
|
||
<li>Plan the second half of M4: resilience patterns on all external calls and verified graceful degradation follow next week (M4 check end of week 11).</li>
|
||
</ul>
|
||
<p><em>No deliverable is due this week.</em></p>
|
||
</div>
|
||
<div class="section" id="s10"><h3>Week 11: The Fit III – Measurement Contract, Conway's Law, and the Limits of the Theory</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 11
|
||
Section title (Edit section → Section name): Week 11: The Fit III – Measurement Contract, Conway's Law, and the Limits of the Theory
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 11 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_11.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can explain why step (vii) codifies the chosen fit as a measurement contract of executable invariants.</li>
|
||
<li>I can define an architectural fitness function, classify it by scope and cadence, and name the three instrument families.</li>
|
||
<li>I know the four DORA metrics, the coupling finding, and why the evidence is prediction rather than causal proof.</li>
|
||
<li>I can name the four layers of the cascade with their falsification questions and read the C10 reference contract.</li>
|
||
<li>I can explain, using Boehm and Menzies, why the cost-of-change curve is flat within but steep across architecture boundaries.</li>
|
||
<li>I can explain why fitness functions are the operating licence for agents and name the two Axis-B fitness-function types.</li>
|
||
<li>I know which five measurement-contract items my project submission must ship, wired into CI.</li>
|
||
<li>I can apply Conway's law as the third fit dimension: check D11 last but veto on it first.</li>
|
||
<li>I know the four Team Topologies team types, the three interaction modes, and the inverse Conway manoeuvre.</li>
|
||
<li>I can name the six limits of the theory, what compensates each, and state Maxim 9.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 11: The Fit III – The Measurement Contract, Conway's Law, and the Limits of the Theory</strong> · 3 lessons lecture + 1 lesson standup/coaching<br>
|
||
Part IV closes with the measurement contract in depth (fitness functions, DORA, C10 reference contract, cost of change), Conway's law as third fit dimension, and six limits of the theory.</p>
|
||
<ul>
|
||
<li>Step (vii) codifies the chosen fit as a measurement contract of executable invariants: “the architecture may change freely as long as the contract stays green”.</li>
|
||
<li>Fitness functions – objective integrity assessments – are classified by scope (atomic, holistic) and cadence (triggered, continual, temporal); three families: dependency checks as CI gates, performance and cost budgets, chaos experiments.</li>
|
||
<li>The four DORA metrics – tempo: deployment frequency, lead time for changes; stability: change failure rate, failed-deployment recovery time – are not a trade-off: elite performers lead on all four.</li>
|
||
<li>Loosely coupled architectures and teams are the strongest predictor of continuous delivery; the label “microservices” is neither necessary nor sufficient – survey-based prediction, not causal proof.</li>
|
||
<li>The four-layer cascade – design time, delivery, operation, evolution – asks whether the structure is intact, delivering, keeping its runtime promises, ageing; the C10 reference contract instantiates it in eight rows.</li>
|
||
<li>Boehm's cost-of-change escalation (up to one hundred times) is flattened for changes within an architecture (Menzies, 171 projects) but steep for changes of it – the contract, not the diagram, protects the investment.</li>
|
||
<li>Fitness functions are the operating licence for agents (Axis A); Axis B adds two new fitness-function types with old mechanics: eval-harness pass rate (triggered) and token-cost budget per request (continual).</li>
|
||
<li>The fit is three-way – pattern, application class, team structure; check D11 last but veto on it first; Team Topologies and the inverse Conway manoeuvre make Conway's law a design instrument.</li>
|
||
<li>Six limits – ordinal scales, context-dependence, hybrids as the normal case, heterogeneous evidence, the hidden organisation, AI-era volatility – make the matrix a hypothesis, not an authority.</li>
|
||
<li>Maxim 9: the matrix is the argument's skeleton, ATAM is its court of appeal, the ADR is its record, and the fitness function is its parole condition.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 11 <em>(added below by the lecturer)</em> · Script: Part IV – Sections 37 (The Measurement Contract), 38 (The Third Fit Dimension: Conway's Law and Team Topologies) and 39 (Limits of the Theory – Applied to Itself).</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part IV – Sections 37 (The Measurement Contract), 38 (The Third Fit Dimension: Conway's Law and Team Topologies) and 39 (Limits of the Theory – Applied to Itself).</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Arrive with the deterministic core (Performance, Risk, Optimization services) tested against the reference vectors – week 11 completes M4 with resilience and graceful degradation.</li>
|
||
<li>Have your project's measurement contract from the A2 dossier at hand – the lecture shows the C10 reference contract and what your submission must ship.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> One lesson of standup/coaching: the teams complete the resilience patterns on all external calls and verify graceful degradation, closing milestone M4 at the end of the week.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M4 – Deterministic Core and Resilience (weeks 10–11)</p>
|
||
<ul>
|
||
<li>Add resilience patterns to all external calls: timeout, retry, circuit breaker, fallback.</li>
|
||
<li>Verify graceful degradation – the resilience row of the reference contract (kill one instance or broker under load; the SLO holds) is the fitness function that verifies it.</li>
|
||
<li>Finish testing the Performance, Risk, and Optimization services fully against the reference vectors – milestone M4 closes at the end of week 11 with the deterministic core fully tested and resilient.</li>
|
||
<li>Keep the deterministic core free of LLM calls – this is the line that is graded.</li>
|
||
<li>Prepare for the project review: the submission must ship its measurement contract wired into CI – module-boundary check with zero violations (Python: import-linter; Java: ArchUnit or Spring Modulith), including the determinism-boundary rule; an eval harness with a versioned golden set and pass rate ≥ 95 %; a token-cost budget per request as a pipeline gate; a p95 latency budget ≤ 20 s for the advisory scenario; and the ADR (MADR form) whose final section is the contract. Be ready to demonstrate one contract violation being caught by CI.</li>
|
||
</ul>
|
||
<div style="border-left:4px solid #1b6ec2; background:#eef5fc; padding:8px 12px; margin:10px 0;">📌 <strong>Due this week:</strong> Milestone check (end of week 11): deterministic core fully tested and resilient</div>
|
||
</div>
|
||
<div class="section" id="s11"><h3>Week 12: The AI Dimension I – Axis A Evidence, Axis B Foundations</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 12
|
||
Section title (Edit section → Section name): Week 12: The AI Dimension I – Axis A Evidence, Axis B Foundations
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 12 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_12.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can explain assumption A6 – two axes, one method – and distinguish Axis A (tool) from Axis B (component).</li>
|
||
<li>I can reconcile the Copilot RCT (+55.8 %) and the METR RCT (−19 %) with the five moderator variables.</li>
|
||
<li>I know the system-level record – DORA's amplifier finding, GitClear's duplication and churn trend – and the METR perception gap.</li>
|
||
<li>I can explain the verification bottleneck and derive Maxim 7 from it: AI raises the value of architecture.</li>
|
||
<li>I can explain how ADRs, agent instruction files and fitness functions become the control interface and operating licence for agents.</li>
|
||
<li>I know that patterns are examinable and products expire, that MCP is ports-and-adapters, and who answers for merged code.</li>
|
||
<li>I can name the five failures of the synchronously wired sentiment call and their dimensions D3, D10, D12, D7, D6.</li>
|
||
<li>I can distinguish the three AI component types and explain why adding AI is a per-component matching problem.</li>
|
||
<li>I can explain why CACE demands containment and justify each element of the reference architecture (port, gateway, queue, guard).</li>
|
||
<li>I can define the eval harness, name its four evaluation strategies, and place its thresholds in the measurement contract.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 12: The AI Dimension I – Axis A Evidence, Axis B Foundations</strong> · 3 lessons lecture + 1 lesson standup/coaching<br>
|
||
Part V opens as Assumption A6 falls due: the Axis A evidence and its resolution, then the Axis B foundations from the wrongly wired sentiment call to the eval harness.</p>
|
||
<ul>
|
||
<li>Assumption A6 falls due: Axis A (AI as tool) changes how systems are built, Axis B (AI as component) what they contain – two independent axes, one method, nothing new.</li>
|
||
<li>Copilot RCT: +55.8 % on a greenfield task; METR RCT: experts 19 % slower in their own mature codebases, estimating +20 % – the perception gap is the didactic core.</li>
|
||
<li>Neither study is wrong – five moderators reconcile the record; at system level DORA finds AI an amplifier (instability persists); GitClear: duplication 4×, refactoring signature collapsed; adoption up, trust down.</li>
|
||
<li>The verification bottleneck: code generation became cheap; specification, verification and architecture became the binding constraints – AI lowers the cost of producing code, not of taking responsibility for it.</li>
|
||
<li>Maxim 7: AI raises the change rate by an order of magnitude and therefore raises, not lowers, the value of architecture; D7 and D9 gain weight in every requirements profile.</li>
|
||
<li>ADRs and agent instruction files are the control interface, fitness functions the operating licence for agents; whoever merges code answers for it; patterns are examinable, products expire; MCP is ports-and-adapters.</li>
|
||
<li>Wired synchronously, the news-sentiment call fails on latency (D3), cost (D10), non-determinism (D12), drift (D7) and injection (D6) – properties of the wiring, not bugs in the model.</li>
|
||
<li>Three component types (LLM, ML, optimisation) differ where the twelve dimensions measure: adding AI is a per-component matching problem; CACE (changing anything changes everything) means decomposing around the component.</li>
|
||
<li>Reference architecture (ADR-011 made structural): typed port → gateway (routing, semantic cache, stability patterns, cost telemetry) → queue → ontology guard; LLM agents propose, deterministic services decide and book.</li>
|
||
<li>Eval harness (versioned cases, scoring logic, statistical thresholds, executed in CI) replaces exact assertion by statistical acceptance: golden-set regression, LLM-as-judge, domain axioms, online evaluation; thresholds belong in the measurement contract.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 12 <em>(added below by the lecturer)</em> · Script: Part V – Sections 40 (Two Axes, One Method), 41 (Axis A: AI as a Tool Shifts the Economics of the SDLC) and 42 (Axis B: AI as a Runtime Component). Section 42: subsections 42.1–42.5 only.</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part V – Sections 40 (Two Axes, One Method), 41 (Axis A: AI as a Tool Shifts the Economics of the SDLC) and 42 (Axis B: AI as a Runtime Component). Section 42: subsections 42.1–42.5 only.</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Come to the coaching slot ready to start M5: the AdvisorAgent with 2–3 sub-agents behind the gateway (mandatory) and the ontology guard active on all insights.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> One-lesson standup/coaching slot on milestone M5: teams wire the AdvisorAgent and its 2–3 sub-agents into the lecture's reference architecture – typed port → gateway → queue → ontology guard – with every LLM call through the gateway and the ontology guard active on all insights.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M5 – Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12–13)</p>
|
||
<ul>
|
||
<li>Wire the AdvisorAgent to orchestrate 2–3 sub-agents through contracts – every LLM call through the gateway port (ADR-011), no provider SDK import in domain code; this is the mandatory part of the week.</li>
|
||
<li>Activate the ontology guard on all insights: entity resolution against the deterministic store (valid ticker, sector, event type), domain axioms, citation check – reject unresolvable references rather than passing them on.</li>
|
||
<li>Keep the deterministic core free of LLM calls – LLM agents propose, deterministic services decide and book; this is the line that is graded.</li>
|
||
<li>Apply the Axis A discipline: keep AGENTS.md / CLAUDE.md as current as code, let agents draft ADRs that a named team member signs, and merge agent-generated changes only through the CI gate (module-boundary fitness functions, test suite, eval harness for anything touching prompts or the gateway).</li>
|
||
<li>Put a one-page AI policy in the project handbook (permitted tools, provenance labelling, review rules); week 13 turns the eval harness into a CI gate for the M5 check.</li>
|
||
</ul>
|
||
<p><em>No deliverable is due this week.</em></p>
|
||
</div>
|
||
<div class="section" id="s12"><h3>Week 13: Threats, the Shifted Matrix, Agent Orchestration – and Synthesis</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 13
|
||
Section title (Edit section → Section name): Week 13: Threats, the Shifted Matrix, Agent Orchestration – and Synthesis
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 13 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_13.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can pair each risk of the OWASP Top 10 for LLM Applications with its architectural counter-measure.</li>
|
||
<li>I can explain why prompt injection cannot be solved inside the model and why the architecture is the trust boundary.</li>
|
||
<li>I know the EU AI Act's four risk classes and why its obligations enter R(a) as hard constraints K(a).</li>
|
||
<li>I can derive each pattern's D12 rating from the queue, port and measurement point it provides or lacks.</li>
|
||
<li>I can name the five cell shifts AI causes in the matrix and the quality-attribute mechanism behind each.</li>
|
||
<li>I can distinguish a workflow from an agent and explain why autonomy is a dial, not a binary.</li>
|
||
<li>I can map the six workflow topologies onto their classical analogues from Part II.</li>
|
||
<li>I can choose a topology from the task signature and justify it with a token budget and eval threshold.</li>
|
||
<li>I can explain, from the profile sketch and the economics of autonomy, why agent orchestration remains an edge pattern.</li>
|
||
<li>I can state Maxim 8 and explain why Axis A and Axis B are one discipline at two binding sites.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 13: Threats, the Shifted Matrix, Agent Orchestration – and Synthesis</strong> · 3 lessons lecture + 1 lesson standup/coaching<br>
|
||
The last lecture of new material: Axis B completed (threats, regulation), the shifted matrix, agent orchestration as the eighth pattern, synthesis with Maxim 8, and exam orientation.</p>
|
||
<ul>
|
||
<li>The OWASP LLM Top 10 pairs risks with architectural counter-measures; prompt injection is not solvable in the model (same channel), so the architecture, not the model, is the trust boundary.</li>
|
||
<li>EU AI Act obligations (C10 can be high-risk) are quality attributes with legal force; they enter R(a) as hard constraints K(a), never weights: compliance is the same architecture, documented.</li>
|
||
<li>The matrix is shifted, not rewritten: patterns providing the queue, port and measurement point (D12) gain (EDA, PF; HX most); synchronous chains lose (MS); SL is conditional; cost becomes load-bearing.</li>
|
||
<li>The three-level MLOps ladder says how much of D9 and D12 a team can cash in; A6, restated as a falsifiable claim: AI stretches the dimensions, the method is unchanged.</li>
|
||
<li>Agent orchestration is a composition pattern, not a new style; agent = loop + tools + state; workflows follow predefined code paths, agents steer their own process and tool use.</li>
|
||
<li>The six topologies map onto Part II: chain (PF), routing (routing layer/mediator), parallelisation (broker-style fan-out), orchestrator–workers (mediator EDA), evaluator–optimizer (feedback control loop), multi-agent (broker topology); strengths and weaknesses transfer.</li>
|
||
<li>The task-signature table selects the simplest matching topology first; the default rule: workflows before agents, every escalation an ADR with token budget and eval threshold (Maxim 6 applies unchanged).</li>
|
||
<li>Autonomy is a CBAM (cost–benefit) decision (90.2 % better at ~15× the tokens); with −− on D3/D4/D9/D10 in its profile sketch, agent orchestration remains an edge pattern behind a deterministic core.</li>
|
||
<li>Maxim 8: the theory absorbs AI (same assumptions, same procedure, same contract); the two axes are one discipline at two binding sites: cheap, fallible generation contained behind expensive, explicit verification.</li>
|
||
<li>Exam orientation (open book, 60 minutes; focus: architecture reasoning): the map is Maxim 8's one sentence, the four tables, Part V's additions and the spine A1–A6 with the Maxims.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 13 <em>(added below by the lecturer)</em> · Script: Part V – Sections 42 (Axis B: AI as a Runtime Component), 43 (How AI Shifts the Matrix), 44 (Agent Orchestration: The Emergent Eighth Pattern) and 45 (Synthesis: One Theory, Five Parts). Section 42: subsections 42.6–42.7 only.</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> Part V – Sections 42 (Axis B: AI as a Runtime Component), 43 (How AI Shifts the Matrix), 44 (Agent Orchestration: The Emergent Eighth Pattern) and 45 (Synthesis: One Theory, Five Parts). Section 42: subsections 42.6–42.7 only.</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Bring the current state of your M5 work to the coaching session: eval harness as CI gate, cost/latency observability, hardening and any distinction work.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> One lesson of standup and coaching on the closing M5 work: eval harness as a CI gate, token-cost and latency observability, threat model and hardening, caching and batching, optional distinction work; M5 is checked at the end of the week.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M5 – Multi-Agent Orchestration, Evaluation, and Hardening (weeks 12–13)</p>
|
||
<ul>
|
||
<li>Wire the evaluation harness into CI as a gate; report accuracy and failure modes.</li>
|
||
<li>Add observability of token cost and latency per request – cost per request and per feature on a dashboard, enforced as a CI budget; then scale and optimise with caching and batching.</li>
|
||
<li>Write the threat model including prompt injection via news, using the OWASP table as your checklist and the same-channel rule, and apply basic hardening: no LLM output reaches the booking path without the ontology guard, no agent tool performs an irreversible action.</li>
|
||
<li>Record the ADR that justifies your orchestration topology against the task-signature table, with its token budget and eval threshold as the measurement contract.</li>
|
||
<li>Take on optional distinction work (Kür) – autonomous planning, self-repair, model routing, CI/CD, tracing – justifying every topology escalation against the task-signature table and pricing it per the default rule; keep the deterministic core free of LLM calls – this is the line that is graded.</li>
|
||
</ul>
|
||
<div style="border-left:4px solid #1b6ec2; background:#eef5fc; padding:8px 12px; margin:10px 0;">📌 <strong>Due this week:</strong> Milestone check (end of week 13): eval harness in CI + guard + cost observability</div>
|
||
</div>
|
||
<div class="section" id="s13"><h3>Week 14: Synthesis, Presentations, and Architecture Defence</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · Week 14
|
||
Section title (Edit section → Section name): Week 14: Synthesis, Presentations, and Architecture Defence
|
||
Three blocks follow, matching the FHGR section template. Paste each block into the
|
||
corresponding 'Text and media area' (editor → source code view), or all three into one.
|
||
The slide set of lecture 14 is added by the lecturer as a file resource below block 2.
|
||
Generated by src/build_moodle.py from src/content/week_14.json – edit the JSON, not this file.
|
||
========================================================================== -->
|
||
|
||
<!-- BLOCK 1 · Learning objectives -->
|
||
<h4>🎯 Learning objectives</h4>
|
||
<ul>
|
||
<li>I can read the script backwards as one argument, from assumptions A1–A6 to the ADR with a measurement contract.</li>
|
||
<li>I can distinguish the two temptations, denial and exceptionalism, from the position the script defends: absorption.</li>
|
||
<li>I can explain Maxim 8: why AI, on either axis, changes no step from scenarios to ADR.</li>
|
||
<li>I can explain why Axis A and Axis B reach the same conclusion: one discipline at two binding sites.</li>
|
||
<li>I know the examination facts: 50 %, 60 minutes, open book (script and notes on paper), closed internet.</li>
|
||
<li>I can defend my team's architectural trade-offs on A2's artefacts – ADR, C4 diagram, measurement contract.</li>
|
||
</ul>
|
||
|
||
<!-- BLOCK 2 · Theory -->
|
||
<h4>🧑🏫 Theory</h4>
|
||
<p><strong>Lecture 14: Synthesis, Presentations, and Architecture Defence</strong> · 1 lesson synthesis + 3 lessons presentations and defence<br>
|
||
One lesson of synthesis and exam hints with no new material, then three lessons of final presentations, architecture defence and peer reviews (Deliverable A3, milestone M6).</p>
|
||
<ul>
|
||
<li>Two temptations – denial, falsified by adoption data alone (90 % of practitioners by 2025), and exceptionalism, rejected on the evidence – bracket the position defended since Part I: absorption.</li>
|
||
<li>Read backwards, the script is one argument: Part I sets A1–A4 and the twelve dimensions, Parts II–III build capability and requirements profiles, Part IV matches them into an ADR (assumption A5).</li>
|
||
<li>Part V's stress test held (assumption A6). Maxim 8: the theory absorbs AI – tenth class, twelfth dimension, shifted cells, one emergent composition pattern – same assumptions, same procedure, same contract.</li>
|
||
<li>Axis A (cheap generation, verification bottleneck) and Axis B (cheap model output, validation bottleneck) are one discipline at two binding sites: containing cheap, fallible generation behind expensive, explicit verification.</li>
|
||
<li>The written examination: 50 % of the grade, end of semester, 60 minutes, open book (script and own notes on paper), closed internet; focus architecture reasoning – profiles, matching, trade-offs.</li>
|
||
<li>The open-book map: Maxim 8's sentence and four tables – twelve dimensions, consolidated capability table, requirements table, 7 × 10 fit matrix – plus the spine A1–A6 and the Maxims.</li>
|
||
</ul>
|
||
<p>📎 <strong>Materials:</strong> Slide set of Lecture 14 <em>(added below by the lecturer)</em> · Script: No new script sections – the reading for the examination is the whole script, Parts I–V.</p>
|
||
|
||
<!-- BLOCK 3 · Self-study and assignments -->
|
||
<h4>🧑💻 Self-study and assignments</h4>
|
||
<p><strong>📖 Reading before the lecture:</strong> No new script sections – the reading for the examination is the whole script, Parts I–V.</p>
|
||
<p><strong>Also before the lecture:</strong></p>
|
||
<ul>
|
||
<li>Prepare the final presentation with architecture defence (Deliverable A3): present the system and defend your architectural trade-offs.</li>
|
||
<li>Prepare the reflection on where AI helped and where it hurt – in building (A) and in the system (B).</li>
|
||
<li>Bring your questions on the script and the examination for the Q&A in the synthesis lesson.</li>
|
||
</ul>
|
||
<p><strong>🧩 Exercise session:</strong> Three lessons of final presentations, architecture defence and peer reviews (Deliverable A3, milestone M6): each team presents its system, defends its trade-offs and reflects on where AI helped and hurt; slot length per team, presentation order and the peer-review form are to be announced.</p>
|
||
<p><strong>🛠️ Project work this week</strong> · Milestone M6 – Presentation and Architecture Defence (week 14)</p>
|
||
<ul>
|
||
<li>Present the system the mandatory part requires – architecture derived from the ontology with ADRs and a C4-style diagram, fully tested deterministic services, an orchestrated advisor with 2–3 sub-agents, ontology guard and resilience, evaluation harness and observability – as a reproducible demo on a data snapshot, keeping the deterministic core free of LLM calls.</li>
|
||
<li>Defend your architectural trade-offs on A2's artefacts – the ADR, the C4 diagram, the measurement contract; the assessment emphasises architecture and trade-offs, robustness, quality, AI integration and operation.</li>
|
||
<li>Reflect on where AI helped and where it hurt – in building (Axis A: generation cheap, verification the bottleneck) and in the system (Axis B: model output cheap, validation the bottleneck) – and test whether one discipline at two binding sites held in your project.</li>
|
||
<li>Peer-review the other teams' presentations and defences – form, criteria and reviewer assignment to be announced; listen for which High weight of R(a) carried their decision and which veto they had to mitigate.</li>
|
||
<li>Be prepared to show one measurement-contract violation being caught by CI (Lecture 11).</li>
|
||
</ul>
|
||
<div style="border-left:4px solid #1b6ec2; background:#eef5fc; padding:8px 12px; margin:10px 0;">📌 <strong>Due this week:</strong> Deliverable A3 (week 14): final presentation with architecture defence, peer reviews</div>
|
||
</div>
|
||
<div class="section" id="s14"><h3>📘 Lecture script</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · section "Lecture script"
|
||
Section title (Edit section → Section name): 📘 Lecture script
|
||
Paste into one 'Text and media area'. Add the script PDF (skript/AISE502_Vorlesung_Skript.pdf)
|
||
as a file resource directly below it, or replace the [link] placeholder with its URL.
|
||
Generated by src/build_moodle.py – the reading plan is derived from src/content/week_*.json.
|
||
========================================================================== -->
|
||
|
||
<h4>📘 The lecture script: <em>A Theory of Architecture–Application Fit</em></h4>
|
||
<p>The lecture notes <strong>AISE502: AI in Software Engineering II – Lecture Notes, Core Part: A Theory of
|
||
Architecture–Application Fit</strong> (Dr. Florian Herzog, FH Graubünden, Autumn Semester 2026; five parts,
|
||
45 sections, about 212 pages) are the backbone of this module. They develop one coherent theory:
|
||
software architecture is the set of significant, hard-to-reverse decisions, driven by measurable quality
|
||
attributes, made by systematically matching an application's requirements profile against the capability
|
||
profiles of architectural patterns, and validated empirically over the whole software lifecycle.</p>
|
||
<ul>
|
||
<li><strong>Part I – Architecture as a Decision Problem</strong> (Sections 1–7): the decision problem, the
|
||
twelve profile dimensions as the shared coordinate system, the requirements profile R(a), the capability
|
||
profile C(p), the three-stage match fit(a,p), Architecture Decision Records and the measurement of a decision.</li>
|
||
<li><strong>Part II – Capability Profiles: The Seven Architectural Patterns</strong> (Sections 8–17): layered,
|
||
modular monolith, hexagonal, microservices, event-driven, pipes-and-filters and serverless – each developed
|
||
from the real problem that produced it, with its tactics, capability profile and engineering consequences
|
||
(“build it and study it”); stepping back; outlook on agent orchestration.</li>
|
||
<li><strong>Part III – Requirements Profiles: The Ten Application Classes</strong> (Sections 18–29): from core
|
||
banking (C1) to AI-native advisory platforms (C10) – challenges, weighted requirements profiles, hard
|
||
constraints, and what real systems chose.</li>
|
||
<li><strong>Part IV – The Fit: Matching, Decision Procedure, and Measurement</strong> (Sections 30–39): three
|
||
worked matches, the procedure in general, the 7 × 10 matching matrix and its cell rationales, hybrids and
|
||
evolution paths, the decision procedure, the measurement contract (fitness functions, DORA metrics),
|
||
Conway's law and team topologies, and the limits of the theory.</li>
|
||
<li><strong>Part V – The AI Dimension: Tool and Component</strong> (Sections 40–45): AI as a tool in the
|
||
lifecycle (Axis A) and AI as a non-deterministic runtime component (Axis B), how AI shifts the matrix,
|
||
agent orchestration as the emergent eighth pattern, and the synthesis of the theory.</li>
|
||
</ul>
|
||
<p><strong>How the script is used.</strong> Every weekly section names the sections to read before the lecture
|
||
(reading plan below). The project's design deliverables A1 and A2 use its methods – quality attribute scenarios,
|
||
utility tree, R(a), the three-stage match, ADR, measurement contract. And it is the open-book material of the
|
||
written examination: script and own notes on paper, closed internet; the reading for the examination is the
|
||
whole script, Parts I–V.</p>
|
||
<div style="border-left:4px solid #e0a800; background:#fff8e1; padding:8px 12px; margin:10px 0;">⚠️ <strong>Living document – the script can change during the semester.</strong> The notes are
|
||
altered and updated along the lecture: corrections, sharper wording and additional examples are worked in as
|
||
we go, and section or page numbers may shift as a result. The version on this page is always the current one.
|
||
Re-download it after every announced update and discard older copies – including printed ones you intend to
|
||
bring to the examination.</div>
|
||
<p>📄 <strong>Download:</strong> AISE502_Vorlesung_Skript.pdf – [link]</p>
|
||
|
||
<h5>Reading plan: which sections belong to which week</h5>
|
||
<table style="width:100%; border-collapse:collapse; margin:6px 0 12px 0;">
|
||
<tr><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Week</th><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Lecture</th><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Script sections</th></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">1</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 1: Architecture as a Decision Problem</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part I, Sections 1–2 (Section 2: introduced this week, completed in week 2)</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">2</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 2: The Twelve Dimensions – and How Requirements Become Measurable</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part I, Sections 2–3 (Section 2: completed this week)</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">3</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 3: The Supply Side, the Match, and the Decision Record</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part I, Sections 4–6</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">4</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 4: Patterns I – Layered, Modular Monolith, Hexagonal</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part II, Sections 8–10</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">5</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 5: Patterns II – Microservices and Event-Driven Architecture</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part II, Sections 11–12</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">6</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 6: Pipelines, Serverless, the View Across – and Your Class (C10)</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part II, Sections 13–17; Part III, Section 28 (Sections 19–20: preview of the C1/C2 mirror pair only; read in full in week 8)</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">7</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 7: The Fit, Formally – Three Cases, the Procedure, the Matrix</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part IV, Sections 30–32, 34, 37 (Section 37: introduction only)</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">8</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 8: Requirements Profiles I – Application Classes C1–C5</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part III, Sections 18–23</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">9</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 9: Classes C6–C9 – and Ten Profiles Side by Side</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part III, Sections 24–27, 29</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">10</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 10: The Fit II – Hybrids, Evolution Paths, and the Decision Procedure</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part IV, Sections 35–36, 33</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">11</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 11: The Fit III – The Measurement Contract, Conway's Law, and the Limits of the Theory</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part IV, Sections 37–39</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">12</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 12: The AI Dimension I – Axis A Evidence, Axis B Foundations</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part V, Sections 40–42 (Section 42: subsections 42.1–42.5 only)</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">13</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 13: Threats, the Shifted Matrix, Agent Orchestration – and Synthesis</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Part V, Sections 42–45 (Section 42: subsections 42.6–42.7 only)</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">14</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Lecture 14: Synthesis, Presentations, and Architecture Defence</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">–</td></tr>
|
||
</table>
|
||
<p><em>Section 7 (Summary: The Red Line) closes Part I and is not assigned to a particular week; Section 28 (C10)
|
||
is read in week 6 because it is the class of the course project.</em></p>
|
||
</div>
|
||
<div class="section" id="s15"><h3>🛠️ Project exercise</h3>
|
||
<!-- ==========================================================================
|
||
AISE502 · Moodle course page · section "Project exercise"
|
||
Section title (Edit section → Section name): 🛠️ Project exercise
|
||
Paste into one 'Text and media area'. Add the three documents as file resources directly below it
|
||
(project_exercise/project_exercise.pdf, Folien/AISE502_Projekt_Folien.pdf, project_exercise/ui_sketches/),
|
||
or replace the [link] placeholders with their URLs.
|
||
Generated by src/build_moodle.py.
|
||
========================================================================== -->
|
||
|
||
<h4>🛠️ Project exercise: AI-Augmented Portfolio Intelligence Platform</h4>
|
||
<p>Over the whole semester, in teams, you design, build and operate a <strong>modular, AI-augmented analysis
|
||
platform for stock portfolios</strong>. The platform ingests market prices (structured) and company news
|
||
(unstructured), turns news into validated insights with an AI component, computes risk, performance and
|
||
optimisation figures in deterministic services, and exposes everything API-first through an orchestrated
|
||
multi-agent advisor – with a thin dashboard for demonstration only. It is a Software Engineering II project:
|
||
its centre of gravity is <strong>architecture</strong> – how you structure a system so that it meets its quality
|
||
attributes and stays maintainable while one part of it (the news understanding) is non-deterministic, fallible
|
||
and costly. Whether the services ship as one modular monolith or as several deployables is your architecture
|
||
decision (week 6), which you defend in week 14.</p>
|
||
<p>AI appears in two roles: as a <strong>tool</strong> you build the system with (Axis A) and as a
|
||
<strong>component</strong> inside the system (Axis B). Everything the lecture teaches – profiles, matching,
|
||
ADRs, measurement – you apply to this system. The project counts <strong>50 %</strong> of the module grade.</p>
|
||
<div style="border-left:4px solid #c0392b; background:#fdf0ee; padding:8px 12px; margin:10px 0;">❗ <strong>The single most important rule.</strong> The AI agents may only <em>obtain and
|
||
interpret</em> quantitative values through the deterministic services – they must <em>never compute</em> a risk
|
||
number, a return or an allocation themselves. An agent that “estimates” a volatility is an architecture defect.
|
||
This separation of deterministic from non-deterministic system parts is the core engineering lesson of the
|
||
course, and it is graded.</div>
|
||
|
||
<h5>📎 Documents</h5>
|
||
<ul>
|
||
<li><strong>Exercise sheet</strong> – <em>project_exercise.pdf</em> (16 pages): the normative description –
|
||
overview and goals, functional requirements, reference architecture, AI integration rules, mandatory vs.
|
||
distinction, semester plan and milestones, assessment, UI sketches. <strong>Read it in full.</strong> [link]</li>
|
||
<li><strong>Project slides</strong> – <em>AISE502_Projekt_Folien.pdf</em>: the kickoff presentation of the
|
||
project. The slides are the map, the sheet is the territory. [link]</li>
|
||
<li><strong>UI sketches</strong> – low-fidelity sketches of the user journey and the six screens (HTML and
|
||
PNG; also Section 8 of the sheet). [link]</li>
|
||
</ul>
|
||
|
||
<h5>Two phases, six milestones</h5>
|
||
<p><strong>Weeks 1–7 – design phase:</strong> the two-lesson exercise slot produces the requirements, studies
|
||
candidate architectures against the patterns taught in the lecture, and decides and documents your
|
||
architecture. <strong>Weeks 8–13 – implementation phase:</strong> the exercise slot becomes a one-lesson
|
||
standup/coaching session; implementation happens mainly in self-study time. <strong>Week 14:</strong>
|
||
presentations, architecture defence and peer reviews. The project work for each week is listed in the weekly
|
||
sections; the exercise sheet remains the normative source.</p>
|
||
<table style="width:100%; border-collapse:collapse; margin:6px 0 12px 0;">
|
||
<tr><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Milestone</th><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Weeks</th><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Content</th><th style="text-align:left; border-bottom:2px solid #999; padding:4px 8px; vertical-align:top;">Deliverable / check</th></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M1</strong> Requirements and Ontology</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">1–3</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Domain model and ontology; at least eight quality attribute scenarios with response measures (three of them for the AI components); utility tree; R(platform) with weights, workload shape and hard constraints; repository and tooling.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Deliverable A1 (end of week 3): requirements dossier</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M2</strong> Architecture Decision and Solution Design</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">4–7</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Study the reference systems; run the three-stage match; ADR with rationale and C4-style diagram; bounded contexts → services and contracts; measurement contract with numbers (eval pass rate ≥ 95 %, p95 latency ≤ 20 s, token budget, zero boundary violations); walking-skeleton plan.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Deliverable A2 (end of week 7): architecture dossier + design-review gate</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M3</strong> Walking Skeleton</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">8–9</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Thin end-to-end slice: MarketDataService delivers prices, a minimal ResearchAgent produces one validated Insight; stable API and a placeholder UI.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Check (week 9): the skeleton runs end-to-end</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M4</strong> Deterministic Core and Resilience</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">10–11</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Performance, Risk and Optimization services fully tested against the reference vectors; resilience patterns on all external calls; graceful degradation verified.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Check (end of week 11): core fully tested and resilient</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M5</strong> Multi-Agent Orchestration, Evaluation, and Hardening</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">12–13</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Advisor orchestrates 2–3 sub-agents through contracts, every LLM call through the gateway, ontology guard active; evaluation harness as a CI gate; cost and latency observability; topology ADR; threat model incl. prompt injection; optional distinction work.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Check (end of week 13): eval harness in CI + guard + cost observability</td></tr>
|
||
<tr><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;"><strong>M6</strong> Presentation and Architecture Defence</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">14</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Present the system, defend the architectural trade-offs, reflect on where AI helped and hurt (Axis A and B), peer reviews; show one measurement-contract violation caught by CI.</td><td style="border-bottom:1px solid #ddd; padding:4px 8px; vertical-align:top;">Deliverable A3 (week 14): final presentation with architecture defence</td></tr>
|
||
</table>
|
||
|
||
<h5>Deliverables and assessment</h5>
|
||
<ul>
|
||
<li><strong>A1 – requirements dossier</strong> (end of week 3): scenarios, utility tree, R(platform).</li>
|
||
<li><strong>A2 – architecture dossier</strong> (end of week 7): ADR, C4 views, measurement contract –
|
||
followed by the design-review gate. Production code starts only after the gate (exploratory spikes are allowed).</li>
|
||
<li><strong>A3 – final presentation with architecture defence</strong> (week 14), plus peer reviews.</li>
|
||
</ul>
|
||
<p>Evaluation of the project emphasises: <strong>architecture & trade-offs</strong> (decomposition, contracts,
|
||
deterministic/non-deterministic separation, ADRs), <strong>robustness</strong> (resilience, guards, graceful
|
||
degradation), <strong>quality</strong> (tests for the deterministic services, eval harness for AI),
|
||
<strong>AI integration</strong> (anti-corruption layering, ontology guarding), <strong>operation</strong>
|
||
(observability of cost and latency), and the distinction criteria for top marks (sheet, Section 5).
|
||
The other 50 % of the module grade is the written examination (60 minutes, open book, closed internet).</p>
|
||
|
||
<h5>Hints from the sheet</h5>
|
||
<ul>
|
||
<li>Build the walking skeleton first thing in the implementation phase – a thin end-to-end slice de-risks everything that follows.</li>
|
||
<li>Use the design phase fully: a decided architecture with contracts and a measurement contract makes the implementation weeks sufficient; an undecided one does not.</li>
|
||
<li>Pin the deterministic services with tests before you trust any agent output; keep the deterministic core free of LLM calls – this is the line that is graded.</li>
|
||
<li>Use a snapshot of market and news data so that demo and grading are reproducible even if the live APIs misbehave.</li>
|
||
<li>Commit after each milestone; record architectural decisions as ADRs as you go.</li>
|
||
</ul>
|
||
</div>
|
||
</div></body></html>
|