661 lines
36 KiB
TeX
661 lines
36 KiB
TeX
% !TEX encoding = UTF-8 Unicode
|
|
% ============================================================================
|
|
% AISE502 -- AI in Software Engineering II
|
|
% Lecture 3 slides, typeset with the official FHGR beamer theme
|
|
% (beamerthemeFHGR.sty, University of Applied Sciences of the Grisons).
|
|
% Slide content is unchanged; only the presentation layer is the FHGR template.
|
|
% ============================================================================
|
|
\documentclass[aspectratio=169]{beamer}
|
|
|
|
\usetheme[showsection, titlebg=pics/theme_pics/titlepage.png]{FHGR}
|
|
|
|
% ============================================
|
|
% PACKAGES
|
|
% The theme already loads tikz, graphicx, xcolor, tabularx, colortbl,
|
|
% listings, hyperref, environ and xparse -- only the extras are needed here.
|
|
% ============================================
|
|
\usepackage[british]{babel}
|
|
\usepackage{booktabs}
|
|
\usepackage{amsmath}
|
|
\usepackage{amssymb}
|
|
\usepackage{tcolorbox}
|
|
\usetikzlibrary{shapes.geometric, arrows.meta, positioning, fit, backgrounds, calc}
|
|
|
|
% ============================================
|
|
% SEMANTIC COLOURS, MAPPED ONTO THE FHGR PALETTE
|
|
% The names used throughout the slides are kept, so no slide text changes;
|
|
% they now resolve to the FHGR brand colours defined by the theme.
|
|
% ============================================
|
|
\colorlet{bankblue}{blue} % FHGR blue (4B92A4)
|
|
\colorlet{bankgreen}{green} % FHGR green (817E65)
|
|
\colorlet{bankred}{red} % FHGR red (C60219)
|
|
\colorlet{codegray}{gray} % FHGR gray (595959)
|
|
\colorlet{backcolour}{linen} % FHGR linen (E1D3B5)
|
|
\definecolor{aiviolet}{HTML}{6B4E71} % muted plum, kept distinct for the AI lens
|
|
|
|
% Attribution labels in English (theme default is German)
|
|
\renewcommand{\source}[1]{\par\hfill {\tiny\color{FHGRDeco} Source:\,\itshape #1}}
|
|
\renewcommand{\imagesource}[1]{\par\hfill {\tiny\color{FHGRDeco} Image source:\,\itshape #1}}
|
|
|
|
% ============================================
|
|
% CUSTOM TCOLORBOXES (same semantics as the script, FHGR colours)
|
|
% ============================================
|
|
\newtcolorbox{keypoint}{
|
|
colback=bankblue!7!white,
|
|
colframe=bankblue,
|
|
title=Key Concept,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{examplebox}[1][]{
|
|
colback=bankgreen!10!white,
|
|
colframe=bankgreen,
|
|
title={Example: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{definitionbox}[1][]{
|
|
colback=linen!40!white,
|
|
colframe=camel!85!black,
|
|
title={Definition: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{thinkbox}{
|
|
colback=lightGray!35!white,
|
|
colframe=darkGray,
|
|
title=Discussion,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{hinweisbox}{
|
|
colback=bankred!5!white,
|
|
colframe=bankred,
|
|
title=Important Note,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{ailinse}[1][]{
|
|
colback=aiviolet!7!white,
|
|
colframe=aiviolet,
|
|
title={AI Lens: #1},
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
\newtcolorbox{projektbox}{
|
|
colback=bankblue!4!white,
|
|
colframe=bankblue!70!black,
|
|
title=Project Link: Portfolio Intelligence Platform,
|
|
fonttitle=\bfseries\small,
|
|
boxrule=0.8pt,
|
|
arc=2pt,
|
|
top=2pt, bottom=2pt, left=4pt, right=4pt
|
|
}
|
|
|
|
% ============================================
|
|
% TITLE METADATA
|
|
% ============================================
|
|
\title[AI in Software Engineering II]{AISE502: AI in Software Engineering II}
|
|
\subtitle{Lecture 3: The Supply Side, the Match, and the Decision Record\\[0.4ex]{\small Script: Part I, Sections 4--6}}
|
|
\author{Dr.\ Florian Herzog}
|
|
\shortname{AISE502}
|
|
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}
|
|
|
|
\begin{document}
|
|
|
|
% ============================================
|
|
% TITLE SLIDE
|
|
% ============================================
|
|
\FHGRTitlePage
|
|
|
|
% ============================================
|
|
% AGENDA
|
|
% ============================================
|
|
\begin{frame}{Agenda}
|
|
\small
|
|
\begin{enumerate}\setlength\itemsep{1pt}
|
|
\item Recap: the demand side is built
|
|
\item The seven candidates: a first look
|
|
\item Tactics: the causal mechanism from structure to quality
|
|
\item Deriving a capability rating $c_i(p)$
|
|
\item The match: what the construction dictates
|
|
\item The three-stage fit procedure
|
|
\item The mechanics on a real case: matching the advisory platform (C10)
|
|
\item Why the weighted sum fails
|
|
\item Recording the decision: ADR and MADR
|
|
\item The measurement contract
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% RECAP
|
|
% ============================================
|
|
\section{Recap}
|
|
|
|
\begin{frame}{Recap: where we are}
|
|
\footnotesize
|
|
\begin{center}
|
|
\small demand $\;\to\;$ \textbf{supply} $\;\to\;$ \textbf{match} $\;\to\;$ \textbf{record} $\;\to\;$ test
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\textbf{Done} (weeks 1--2): twelve dimensions; scenarios with response measures; utility tree; weights, shape, constraints -- $R(a)$, worked for C10 and the back-office tool.
|
|
|
|
\vspace{0.15cm}
|
|
\textbf{Today} -- the remaining three framework elements:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the \textbf{supply side} $C(p)$: seven candidate patterns, rated \emph{by derivation}, not by taste
|
|
\item the \textbf{match} $\mathrm{fit}(a,p)$: three stages, non-compensatory -- run live on your project class C10
|
|
\item the \textbf{record}: ADR/MADR and the measurement contract
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{hinweisbox}
|
|
\footnotesize \textbf{A1 (requirements dossier) is due this week} -- scenarios, utility tree, $R(\text{platform})$ with weights, shape, and constraints.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SEVEN CANDIDATES
|
|
% ============================================
|
|
\section{The Seven Candidates}
|
|
|
|
\begin{frame}{The seven candidates (1/2)}
|
|
\footnotesize
|
|
The set $P$ of the framework -- each in one sentence, with its signature strength and cost:
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}p{2.5cm}p{5.0cm}p{2.6cm}p{2.8cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern (code)} & \textbf{Structure in one sentence} & \textbf{Signature strength} & \textbf{Signature cost} \\
|
|
\midrule
|
|
Layered / 3-tier (L) & one deployable, cut into horizontal \emph{technical} layers & simple and cheap: one build, one database & a typical feature cuts across all layers \\
|
|
Modular monolith (MM) & one deployable, cut into \emph{domain} modules with machine-enforced boundaries & monolith economics with modular evolvability & boundaries erode without governance \\
|
|
Hexagonal (HX) & a domain core behind technology-neutral ports with swappable adapters & hermetic testability; swappable technology & indirection that pays off only under change \\
|
|
Microservices (MS) & many independently deployable services, database per service & team scaling; independent deployment & no ACID across services; highest operating cost \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\scriptsize\textcolor{codegray}{You have met four in production dress: Stack Overflow ran L-style, Monzo runs MS, Prime Video's failed design was SL, Segment's rollback was an MS cut.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The seven candidates (2/2)}
|
|
\footnotesize
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}p{2.5cm}p{5.0cm}p{2.6cm}p{2.8cm}@{}}
|
|
\toprule
|
|
\textbf{Pattern (code)} & \textbf{Structure in one sentence} & \textbf{Signature strength} & \textbf{Signature cost} \\
|
|
\midrule
|
|
Event-driven (EDA) & components communicate through asynchronous events via a broker & decoupling, elasticity, fault isolation & eventual consistency; end-to-end testing hard \\
|
|
Pipes-and-filters (PF) & data flows through a chain or DAG of processing steps & throughput and reproducibility for batch work & not built for interactive latency \\
|
|
Serverless / FaaS (SL) & functions on managed infrastructure: scale-to-zero, per-execution billing & elasticity; zero idle cost & cold starts; cost inverts under sustained load \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{hinweisbox}
|
|
\footnotesize \textbf{HX is not a competitor in the same race.} It organises dependencies \emph{inside} whichever host it is applied to and \textbf{composes} with the other six -- a hexagonal modular monolith is \emph{one} coherent design, not two rival ones.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% TACTICS
|
|
% ============================================
|
|
\section{Tactics}
|
|
|
|
\begin{frame}{Three levels of design vocabulary}
|
|
\begin{definitionbox}[Architectural pattern (style)]
|
|
\small A named, documented \textbf{macro-structure}: a topology of elements, permitted relations between them, and known consequences.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{definitionbox}[Architectural tactic]
|
|
\small An \textbf{elementary design decision} that directly influences the response of \emph{one} quality attribute -- the atomic unit of architectural design. Examples: \emph{heartbeat}, \emph{redundancy} (availability); \emph{use an intermediary}, \emph{defer binding} (modifiability); \emph{introduce concurrency}, \emph{maintain multiple copies} (performance).
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.2cm}
|
|
\small Students routinely conflate the levels -- the framework keeps them apart, because its \textbf{explanatory mechanism lives exactly in the gap} between them.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Patterns are bundles of tactics}
|
|
\begin{keypoint}
|
|
\footnotesize A pattern structurally \textbf{privileges} some tactics while \textbf{impeding} others -- so every pattern helps some quality attributes and hurts others \emph{by construction}, not by accident. The causal chain \textbf{topology $\to$ tactics $\to$ quality attribute responses} makes every $++$ and every $--$ explainable and testable.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{examplebox}[EDA as a tactics bundle]
|
|
\footnotesize An event-driven architecture structurally packages \emph{use an intermediary} (modifiability) and \emph{introduce concurrency} (performance) -- while structurally \emph{impeding} \emph{transactions} (consistency). It helps D7 and hurts D4 by construction.
|
|
\end{examplebox}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize
|
|
And one demarcation for everything that follows: patterns are evaluated \textbf{per subsystem}, not per company logo -- hybrids are the normal case.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Deriving a rating $c_i(p)$: three sources, applied in order}
|
|
\footnotesize
|
|
A rating $c_i(p) \in \{++, +, \circ, -, --\}$ is an \emph{ordinal} claim: how well does the topology structurally support dimension $D_i$?
|
|
|
|
\vspace{0.15cm}
|
|
\begin{enumerate}\setlength\itemsep{3pt}
|
|
\item \textbf{Tactics analysis} -- which tactics does the topology make cheap, which does it impede? The causal core: a $--$ that cannot be traced to a structural impediment is an \emph{assertion}, not a rating.
|
|
\item \textbf{Published ratings} -- Richards \& Ford's star ratings calibrate ours, five-step to five-step ($5\star \to ++$, \dots, $1\star \to --$); \textbf{every deviation is footnoted}. Where no stars exist (HX, SL): primary sources, flagged.
|
|
\item \textbf{Documented production systems} -- calibration points: a rating that contradicts a documented production result must either explain the context difference or \textbf{yield}.
|
|
\end{enumerate}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\footnotesize A capability rating is a \textbf{testable prediction}, not a preference. Supply is constructed with the same rigour as demand.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Micro-derivation 1: why EDA rates $++$ on D7 (evolvability)}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{Tactics analysis:} the broker topology \emph{is} the tactic ``use an intermediary'', built into the macro-structure. A new consumer -- a recommendation engine, an audit feed -- attaches to the event stream \textbf{without touching a single producer}. D7's response measure, \emph{change dispersion}, is structurally minimised: adding functionality is additive, not invasive.
|
|
\item \textbf{Published rating:} Richards \& Ford rate the style's evolvability at five stars $\to$ $++$, no deviation to footnote.
|
|
\item \textbf{Production evidence:} LinkedIn's Kafka ecosystem grew for a decade by attaching new consumers to the same durable log.
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{hinweisbox}
|
|
\footnotesize The rating is a \textbf{trade}, exactly as A2 predicts: the same intermediary that decouples producers from consumers also \emph{impedes transactions and hides the workflow} -- the costs land on D4 and D9.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Micro-derivation 2: why microservices rate $--$ on D4 (consistency)}
|
|
\small
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \textbf{Tactics analysis:} the weakness is \emph{structural}. Database-per-service is constitutive of the pattern -- so \textbf{no ACID transaction spans a service boundary}. An invariant crossing services (order $\to$ stock $\to$ ledger) must be maintained by a \textbf{saga}: a sequence of local transactions with \emph{compensating actions}. Intermediate states are visible; compensation is \emph{not} rollback.
|
|
\item Against D4's response measures (invariant violations: target 0 for ledgers), the topology impedes the transaction tactic \textbf{by construction}. Hence $--$.
|
|
\item \textbf{Production evidence:} a documented mitigation exists but is conditional -- Monzo makes sagas work under \emph{extreme technological homogeneity}.
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\small The matching procedure handles exactly this case: a \textbf{veto} on a High-weight dimension that only a \emph{documented} mitigation can lift.
|
|
\end{frame}
|
|
|
|
\begin{frame}{What $++$ and $--$ look like (selection)}
|
|
\scriptsize
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{2.4cm}p{5.4cm}p{5.3cm}@{}}
|
|
\toprule
|
|
\textbf{Dimension} & \textbf{What $++$ looks like structurally} & \textbf{What $--$ (or the weak end) looks like} \\
|
|
\midrule
|
|
D2 Write scalability & partitioned ingest with elastic consumers (EDA, SL) & one relational database receiving every write (L) \\
|
|
D4 Consistency & one ACID transaction boundary around all state (L, MM) & sagas across service databases (MS); eventual consistency through a broker (EDA) \\
|
|
D5 Availability & bulkheaded services: blast radius one service (MS, EDA) & one process: blast radius $100\,\%$ by construction (L, MM: $-$) \\
|
|
D8 Simplicity \& TTM & one repository, one pipeline, shipping this week (L, PF) & platform engineering before the first feature (MS, EDA) \\
|
|
D9 Testability & hermetic domain tests behind ports (HX) & verification only against an integrated environment (L: $-$); event flows resisting end-to-end tests (EDA: $-$) \\
|
|
D12 AI integrability & a natural queue, port, and measurement point (EDA, HX, PF) & an honest middle: platform timeouts vs.\ minutes-long AI runs (SL: $\circ$) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\footnotesize Note the refused $--$ entries (D6, D12 in the full table): where a weakness is genuinely two-faced or workload-dependent, the honest rating is a \textbf{middle} one -- the supply-side counterpart of A4's ban on vague requirements.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Native workload shape -- and $C(p)$ assembled}
|
|
\small
|
|
Every pattern has a \textbf{native workload shape} $S(p)$ -- a \emph{type}, not a rating:
|
|
|
|
\vspace{0.15cm}
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}ll@{}}
|
|
\toprule
|
|
L, MM, MS & interactive request/response \\
|
|
EDA & streams and asynchronous flows \\
|
|
PF & scheduled batch \\
|
|
SL & event-triggered, short-lived work \\
|
|
HX & inherits its host's shape (composition pattern) \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{definitionbox}[Capability profile $C(p)$]
|
|
\small $C(p) = \bigl(c_1(p), \dots, c_{12}(p);\; S(p)\bigr)$, $c_i(p) \in \{++, +, \circ, -, --\}$: ordinal ratings of structural support for each dimension, justified through \textbf{tactics}, anchored in published star ratings, deviations footnoted -- plus the native shape, which feeds the workload-shape \textbf{gate} of the match.
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.15cm}
|
|
Part II derives all seven profiles in full -- starting next week.
|
|
\end{frame}
|
|
|
|
\begin{frame}{AI Lens: an LLM component stresses D3, D10, and D12}
|
|
\begin{ailinse}[Axis B preview]
|
|
\small Suppose one component is an LLM call. Nothing new is needed -- the coordinate system already carries it:
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \textbf{D3}: LLM calls cost \emph{seconds} where classical calls cost milliseconds -- time behaviour becomes a \emph{structural} concern (queues, asynchronous integration, caching)
|
|
\item \textbf{D10}: per-token pricing makes operating cost a \emph{per-request} attribute -- a bad prompt chain is a cost regression the way an $n{+}1$ query is a latency regression
|
|
\item \textbf{D12}: the pattern either provides the \emph{queue, port, and measurement point} -- or it does not; the seven patterns differ sharply on exactly that
|
|
\end{itemize}
|
|
\end{ailinse}
|
|
|
|
\vspace{0.25cm}
|
|
\small The supply side absorbs AI as \textbf{ratings on existing dimensions} -- assumption A6 at work.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% THE MATCH
|
|
% ============================================
|
|
\section{The Match}
|
|
|
|
\begin{frame}{What the construction dictates}
|
|
\footnotesize
|
|
Three properties of the profiles are \emph{results of their construction} -- and each imposes a requirement on any admissible aggregation:
|
|
|
|
\vspace{0.15cm}
|
|
\begin{enumerate}\setlength\itemsep{3pt}
|
|
\item \textbf{Constraints are knock-outs.} A violated obligation cannot be traded against merit $\to$ eliminate \emph{before} any scoring. The \textbf{workload shape} belongs to the same family: a pattern whose native $S(p)$ contradicts the dominant $S(a)$ cannot carry the class's core.
|
|
\item \textbf{High weights carry vetoes.} A High weight \emph{was defined} as the presence of (H,\,H) leaves -- scenarios whose failure is existential. A pattern structurally weak exactly there fails those scenarios; excellence elsewhere does not un-fail them $\to$ \textbf{non-compensatory} on High-weight dimensions.
|
|
\item \textbf{Everything is ordinal.} Ordinal inputs license ordinal outputs -- \emph{rankings and exclusions, never percentages} -- and every result must be checked for stability under plausible re-weighting.
|
|
\end{enumerate}
|
|
|
|
\vspace{0.15cm}
|
|
These three requirements admit \textbf{essentially one procedure} \dots
|
|
\end{frame}
|
|
|
|
\begin{frame}{The three-stage fit procedure}
|
|
\begin{definitionbox}[Architecture--application fit $\mathrm{fit}(a,p)$]
|
|
\footnotesize An ordinal aggregate on the scale $\{++, +, \circ, -, --\}$, determined by a deliberately \textbf{non-compensatory, three-stage procedure}:
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{Knock-out screening.} Hard constraints $K(a)$ eliminate patterns before any scoring. The \emph{workload-shape gate}: if $S(p)$ does not match the dominant $S(a)$, the cell is capped at $\circ$ (subsystem role) -- $+$ only for a \emph{constitutive} subsystem of a shape-hybrid class; $-$/$--$ where it would harm binding scenarios.
|
|
\item \textbf{Veto rule on High-weight dimensions.} $c_i(p) = --$ on a High dimension caps the fit at $-$; $c_i(p) = -$ caps it at $\circ$ -- \emph{unless a documented mitigation exists} (a tactic or hybrid with production evidence), in which case the cell says so and the cap is lifted.
|
|
\item \textbf{Holistic ordinal reading with mandatory sensitivity analysis.} Survivors are ranked by support of the High set; clustering Medium conflicts can downgrade one step. Result: a \emph{ranking with exclusions}. If it flips under plausible re-weighting, that instability is a genuine \textbf{trade-off point} -- escalate to scenario-based analysis (ATAM).
|
|
\end{enumerate}
|
|
\end{definitionbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Why non-compensatory -- and why the veto can be lifted}
|
|
\footnotesize
|
|
\textbf{Non-compensatory mirrors how architectural failure actually works:} Prime Video's serverless design was \emph{excellent} on elasticity and deployability -- none of that compensated for the cost structure its workload shape imposed.
|
|
|
|
\vspace{0.15cm}
|
|
\textbf{The mitigation clause keeps the rule honest:}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item a veto can be lifted -- but only by a \emph{documented} tactic or hybrid with production evidence
|
|
\item ``pod-sharded replication of the monolith'' (Shopify) or ``event-driven edges around an ACID core'' -- \textbf{never by optimism}
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{examplebox}[Same class -- opposite structures: LMAX and Monzo]
|
|
\footnotesize LMAX runs core trading on \emph{one} deterministic, event-sourced JVM thread ($6$M orders/s); Monzo runs banking on $\sim 2{,}800$ microservices. \textbf{Both} satisfy the class's binding scenarios. Lesson: $R(a)$ alone defines a \emph{feasible set}; the constraints and context in $K(a)$ decide \emph{within} it. A theory pretending to compute a single winner would be falsified by this pair.
|
|
\end{examplebox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The mini-match: $R(\text{C10})$ against L, MM, MS -- stage 1}
|
|
\small
|
|
\textbf{The demand side} (from week 2): High on $\{$D6, D7, D9, D10, D12$\}$; shape \emph{hybrid}; EU AI Act and GDPR in $K$.
|
|
|
|
\vspace{0.25cm}
|
|
\textbf{Stage 1 -- knock-out and shape gate:}
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item $S(\text{C10})$ is hybrid: an interactive advisory dialogue at the core, batch/asynchronous pipelines (indexing, evaluation) beside it
|
|
\item all three candidates are natively \emph{interactive} $\to$ all pass the gate \textbf{for the core} -- the pipelines will be carried by PF- and EDA-shaped \emph{subsystems} in any design
|
|
\item no hard constraint eliminates a candidate outright -- but note for stage 3: the AI Act's logging and oversight duties \emph{favour} structures where every model call flows through \textbf{one auditable path}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The mini-match -- stage 2: vetoes on the High dimensions}
|
|
\footnotesize
|
|
\begin{itemize}\setlength\itemsep{4pt}
|
|
\item \textbf{L (layered):} rates $-$ on High-weighted \textbf{D7} $\to$ cap $\circ$ unless mitigated -- and at C10's extreme change rate of models, prompts, and frameworks \emph{there is none}: technical layers give the non-deterministic component no boundary, no queue, no measurement point. \textbf{D9} is a second $-$ on a High dimension; D12 offers only $\circ$. Two unmitigated vetoes that \emph{cluster} push the stage-3 reading one step below the cap: $\mathbf{-}$.
|
|
\item \textbf{MS (microservices):} rates $--$ on High-weighted \textbf{D10} $\to$ would cap at $-$ -- but here the \emph{mitigation clause earns its keep}: C10's cost concern is \textbf{per-request AI cost} (tokens, GPU), governed at a \emph{gateway} -- orthogonal to distribution. The platform-cost veto relaxes to $\circ$. What stops MS from rising further: synchronous service chains \emph{multiply} seconds-scale LLM latency and failure rates, and the pattern's signature payoff (team scaling) sits on \textbf{Low-weighted} D11 -- for a student-sized team the microservice premium buys nothing.
|
|
\item \textbf{MM (modular monolith):} \textbf{no veto fires at all} -- $+$ or better on every High dimension; its one structural $-$ (D5, blast radius) is Medium-weighted and mitigated by replicated instances.
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The mini-match -- stage 3 and the verdict}
|
|
\footnotesize
|
|
MM leads the High set outright; \textbf{HX inside} raises D9/D12 to $++$ -- the LLM becomes a mockable, swappable adapter on a port.
|
|
|
|
\vspace{0.1cm}
|
|
\begin{center}
|
|
\scriptsize
|
|
\begin{tabular}{@{}p{3.4cm}ccc@{}}
|
|
\toprule
|
|
\textbf{High dimension of C10} & \textbf{L} & \textbf{MM ($+$ HX inside)} & \textbf{MS} \\
|
|
\midrule
|
|
D6 Security \& auditability & $+$ & $+$ & $\circ$ \\
|
|
D7 Evolvability & $-$ \emph{(veto)} & $+$ & $++$ \\
|
|
D9 Testability \& deployability & $-$ \emph{(veto)} & $+$ ($++$ with HX) & $+$ \\
|
|
D10 Operating cost & $++$ & $++$ & $--$ \emph{(veto, relaxed)} \\
|
|
D12 AI integrability & $\circ$ & $+$ ($++$ with HX) & $\circ$ \\
|
|
\midrule
|
|
\textbf{Verdict $\mathrm{fit}(\text{C10},p)$} & $\mathbf{-}$ & $\mathbf{++}$ & $\mathbf{\circ}$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize The \textbf{hexagonal modular monolith} is the primary recommendation -- and it is exactly the architecture of your course project. One profile, three candidates, three stages: a \emph{ranking with exclusions}.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Discussion}
|
|
\begin{thinkbox}
|
|
\small Run the same three candidates against $R(\text{back-office})$ from week 2 -- High on D4, D6, D7, D8, D10. Which veto fires first, and does the verdict change?
|
|
|
|
\vspace{0.2cm}
|
|
Check yourselves: MS now hits \textbf{two unmitigated $--$ vetoes at once} (D8 and D10, both High for this class); L's strengths sit exactly on the class's High set (D4, D8, D10), and only D7 caps it -- liftable by scoping to a small, stable domain. The verdicts become \textbf{L $+$, MM $++$, MS $--$}: the same winner, but a radically re-ordered field.
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Why the obvious alternative fails}
|
|
\small
|
|
Why not score $1$--$5$, multiply by weights, add up ($V = \sum_i w_i \cdot v_i$)? The additive form is licensed only under three conditions -- \textbf{all three fail here}:
|
|
|
|
\vspace{0.15cm}
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{Cardinal (interval) scales} -- but the ratings are ordinal by construction: what would ``microservices score $4.3$ on consistency'' \emph{mean}?
|
|
\item \textbf{Preferential independence} -- violated \emph{by definition}: A2 says the value of ``scalability $= ++$'' depends on what happens to consistency; trade-offs \emph{are} preferential dependence
|
|
\item \textbf{Weights as trade-off rates} -- nobody can state, or defend to an auditor, the rate at which audit-trail quality is exchangeable for deployment frequency
|
|
\end{enumerate}
|
|
|
|
\vspace{0.2cm}
|
|
The AHP repair inherits documented defects: adding an alternative (even a \emph{copy}) can \textbf{reverse the ranking}; Dyer's verdict: ``flawed as a procedure for ranking alternatives''.
|
|
|
|
\vspace{0.15cm}
|
|
\textbf{Kept} from multi-criteria analysis: the \emph{explication discipline} -- criteria on the table, weights argued, options compared. \textbf{Dropped}: the arithmetic pretensions.
|
|
\end{frame}
|
|
|
|
\begin{frame}{Beware pseudo-precision}
|
|
\begin{hinweisbox}
|
|
\small A weighted-sum matrix over ordinal ratings produces numbers -- ``pattern A: $3.87$; pattern B: $3.79$'' -- whose significant digits are \textbf{artefacts of the procedure}, not measurements of anything. Such numbers end discussions that should be had (the $0.08$ gap will not survive any plausible re-weighting) and lend false authority to buried assumptions.
|
|
\end{hinweisbox}
|
|
|
|
\vspace{0.3cm}
|
|
\small The professional habit this module trains is the opposite:
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item report \textbf{rankings with exclusions}, and state the \textbf{veto} behind each exclusion
|
|
\item run the \textbf{sensitivity analysis}
|
|
\item if the recommendation flips under plausible weights, you have found a genuine \textbf{trade-off point} -- a \emph{finding} to escalate to stakeholders, not an error to hide with more decimals
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The status of the matrix}
|
|
\small
|
|
Applying the procedure to all pairs yields the $7 \times 10$ matrix of Part IV. One point governs how every cell is read:
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize The matrix is an \textbf{explication and communication instrument} -- a compressed, teachable heuristic that forces criteria, weights, and assumptions into the open -- \emph{not} a computation that determines decisions. The rigorous method behind every contested cell is the \textbf{ATAM}: scenario walk-throughs, sensitivity points, trade-off points, risks.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.2cm}
|
|
Three honest limits, holding throughout:
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item the scales are \textbf{ordinal} -- no percentages, ever
|
|
\item the ratings are \textbf{context-dependent} -- the serverless cost rating literally \emph{inverts} with load shape
|
|
\item \textbf{hybrids are the normal case} -- the matrix is read \emph{per subsystem}
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% RECORDING THE DECISION
|
|
% ============================================
|
|
\section{Recording the Decision}
|
|
|
|
\begin{frame}{The decision is the primary artefact}
|
|
\small
|
|
A1 says: what we choose is a \textbf{decision} with high reversal cost -- and undocumented decisions \emph{evaporate}:
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item the code shows \emph{what} was built, never \emph{why}
|
|
\item within a few staff rotations the rationale is gone; later changes violate constraints nobody remembers -- which is what teams experience as \textbf{``legacy''}
|
|
\end{itemize}
|
|
|
|
\vspace{0.15cm}
|
|
ISO/IEC/IEEE 42010:2022 draws the normative conclusion: a conformant architecture description \textbf{must} record architecture decisions \emph{and their rationale} (Clause 6.10).
|
|
|
|
\vspace{0.15cm}
|
|
\begin{definitionbox}[Architecture Decision Record (ADR)]
|
|
\footnotesize A short text document -- one to two pages, \textbf{versioned in the code repository}, one decision per file -- with Nygard's structure: \textbf{Title} $\cdot$ \textbf{Status} (proposed / accepted / deprecated / superseded) $\cdot$ \textbf{Context} (the forces at play, value-neutral) $\cdot$ \textbf{Decision} (active voice: ``We will \dots'') $\cdot$ \textbf{Consequences} (positive \emph{and} negative).
|
|
\end{definitionbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Three design choices make the format work -- and MADR extends it}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{Co-location} -- ADRs live in the repository, next to the code they govern, not in a wiki that dies with the project office
|
|
\item \textbf{Brevity} -- one decision, one page: a format cheap enough to be used beats a comprehensive one that is not
|
|
\item \textbf{Immutability} -- a superseded ADR is never edited or deleted; a new ADR supersedes it. The record of \emph{why we changed our minds} is often more valuable than the current answer.
|
|
\end{enumerate}
|
|
|
|
\vspace{0.15cm}
|
|
\textbf{MADR} adds explicit \textbf{decision drivers} and \textbf{considered options} (each with pros and cons), plus an optional \textbf{confirmation} section.
|
|
|
|
\vspace{0.1cm}
|
|
\begin{keypoint}
|
|
\footnotesize MADR is this module's format for a structural reason: \emph{decision drivers $+$ considered options} is exactly \textbf{one row of the matching matrix in narrative long form} -- a completed matrix is the tabular compression of many MADRs.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{ADR-011: the LLM gateway decision (your project, week 6)}
|
|
\begin{tcolorbox}[colback=gray!4!white, colframe=gray!55!black, boxrule=0.6pt, arc=2pt, top=3pt, bottom=3pt, left=6pt, right=6pt]
|
|
\scriptsize\ttfamily
|
|
\textbf{ADR-011: Route all LLM calls through one gateway port}\\[2pt]
|
|
Status: accepted | supersedes ADR-004\\[4pt]
|
|
\textbf{Context:} providers deprecate models on 6--12-month cycles; token costs must be attributable per request; domain logic must stay testable without paid, non-deterministic API calls.\\[4pt]
|
|
\textbf{Drivers:} D7 evolvability -- provider change stays cheap $\cdot$ D9 testability -- hermetic tests $\cdot$ D12 -- per-request cost observability\\[4pt]
|
|
\textbf{Options:} (1) direct provider-SDK calls from domain services $\cdot$ \textbf{(2) one gateway behind a domain-owned port} $\leftarrow$ chosen $\cdot$ (3) per-feature adapters without a shared gateway\\[4pt]
|
|
\textbf{Consequences:} $+$ provider migration is an adapter task; domain tests run against fakes. $-$ one more runtime component; $\sim$20--50\,ms latency; the gateway needs its own SLO.
|
|
\end{tcolorbox}
|
|
|
|
\vspace{0.1cm}
|
|
\footnotesize
|
|
\textbf{Confirmation (measurement contract, in embryonic form):}
|
|
\begin{itemize}\setlength\itemsep{0pt}
|
|
\item static rule: no domain module imports the provider SDK (ArchUnit, CI gate, 0 violations)
|
|
\item eval-harness pass rate $\geq 95\,\%$ on every model/prompt change
|
|
\item token cost per request $\leq$ budget (p95), monitored continually
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Diagrams and the measurement contract}
|
|
\small
|
|
\textbf{C4 -- diagrams for decisions, sparingly:} four zoom levels (system context, container, component, code). For this module, \textbf{container level dominates}: a modular monolith is \emph{one} container with enforced internal boundaries, a microservice system is \emph{many}, an event-driven system inserts a \emph{broker} container between them.
|
|
|
|
\vspace{0.25cm}
|
|
\textbf{The measurement contract} -- the fifth framework element:
|
|
\begin{itemize}\setlength\itemsep{2pt}
|
|
\item every ADR ends with the \textbf{fitness functions and thresholds that would tell us the decision has failed}
|
|
\item static rules as CI gates $\cdot$ scenario response measures as automated tests $\cdot$ cost and latency budgets as telemetry alarms
|
|
\item in operation, the four \textbf{DORA metrics} test whether the delivery-relevant promises hold
|
|
\item on breach: a documented evolution path (Strangler Fig) recorded as a \emph{superseding ADR} -- never a silent rewrite
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{AI Lens: an agent drafts the ADR -- a human owns the decision}
|
|
\begin{ailinse}[Axis A]
|
|
\small ADRs are an ideal task for AI assistance and a \textbf{hard boundary for AI authority}. An agent with access to the repository, the utility tree, and the matrix can \emph{draft} a competent MADR in minutes: enumerate options, fill pros and cons from the capability profiles, propose fitness functions. Use that. But the decision itself is an \textbf{act of accountability}: a nameable person weighs the drivers, accepts the negative consequences, and answers for them later.
|
|
\end{ailinse}
|
|
|
|
\vspace{0.25cm}
|
|
\small Second-order effect: agents \emph{read} ADRs and convention files on every run -- documentation quality is reproduced \textbf{at machine speed, in whichever direction it points}. A precise ADR corpus is leverage; a stale one is automated misdirection.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SUMMARY
|
|
% ============================================
|
|
\section{Summary}
|
|
|
|
\begin{frame}{Summary: Part I is complete}
|
|
\footnotesize
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item \textbf{Supply:} seven candidates; ratings derived from \emph{tactics}, calibrated against published stars, checked against production -- never taste
|
|
\item \textbf{Match:} knock-outs and shape gate $\to$ vetoes on High dimensions (liftable only by documented mitigations) $\to$ ordinal reading with sensitivity analysis; weighted sums fail three preconditions -- the matrix is an \emph{explication instrument}, not a computation
|
|
\item Worked end to end: C10 vs.\ L/MM/MS $\to$ \textbf{hexagonal modular monolith} ($++$) -- your project architecture
|
|
\item \textbf{Record:} MADR -- drivers $+$ options $=$ one matrix row; co-located, brief, immutable
|
|
\item \textbf{Measure:} every ADR ends in a measurement contract; breach $\to$ superseding ADR
|
|
\end{enumerate}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{keypoint}
|
|
\footnotesize The chain to remember: class $\to$ scenarios $\to$ utility tree $\to$ $R(a)$ $\to$ non-compensatory match against $C(p)$ $\to$ ADR $\to$ measurement contract $\to$ operation -- and, because profiles drift, back around.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{This week and next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Exercise this week}}
|
|
\begin{itemize}\small
|
|
\item Requirements workshop II: finalise $R(\text{platform})$ -- weights, workload shape, knock-out constraints
|
|
\item ontology as a contract
|
|
\item \textbf{A1 due: requirements dossier} (scenarios $+$ utility tree $+$ $R(a)$)
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 4}}
|
|
\begin{itemize}\small
|
|
\item Part II begins: \textbf{Layered, Modular Monolith, Hexagonal}
|
|
\item problem $\to$ profile $\to$ engineering $\to$ ``build it and study it''
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}\small
|
|
\item this week: Part I, Sections 4--6
|
|
\item ahead: Part II, L/MM/HX
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% END
|
|
% ============================================
|
|
\FHGRClosingPage[][{\color{white}\parbox{0.9\paperwidth}{\centering Thank you!\\[3ex]
|
|
{\normalsize\mdseries Dr.\ Florian Herzog\\[0.9ex]
|
|
Fachhochschule Graub\"unden, Chur\\[2.4ex]
|
|
{\small AISE502 -- AI in Software Engineering II}}}}]
|
|
|
|
\end{document}
|