720 lines
31 KiB
TeX
720 lines
31 KiB
TeX
% !TEX encoding = UTF-8 Unicode
|
|
% ============================================================================
|
|
% AISE502 -- AI in Software Engineering II
|
|
% Lecture 1 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 1: Architecture as a Decision Problem\\[0.4ex]{\small Script: Part I, Sections 1--2}}
|
|
\author{Dr.\ Florian Herzog}
|
|
\shortname{AISE502}
|
|
\fullname{Fachhochschule Graub\"unden, Chur -- Autumn Semester 2026}
|
|
|
|
\begin{document}
|
|
|
|
% ============================================
|
|
% TITLE SLIDE
|
|
% ============================================
|
|
\FHGRTitlePage
|
|
|
|
% ============================================
|
|
% AGENDA
|
|
% ============================================
|
|
\begin{frame}{Agenda}
|
|
\begin{enumerate}
|
|
\item The module: aims, assessment, semester plan, project
|
|
\item Four production systems -- two facts
|
|
\item The decision problem
|
|
\item What software architecture is (and is not)
|
|
\item The framework at a glance
|
|
\item The two AI axes of this module
|
|
\item Six load-bearing assumptions (A1--A6)
|
|
\item From questions to dimensions
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SECTION 1: THE MODULE
|
|
% ============================================
|
|
\section{The Module}
|
|
|
|
\begin{frame}{The module in one question}
|
|
\begin{keypoint}
|
|
\emph{How do I design, justify, and operate the structure of a software system so that it meets its quality attributes and remains maintainable for years -- even when individual components (AI) are non-deterministic, fallible, and expensive?}
|
|
\end{keypoint}
|
|
|
|
\vspace{0.4cm}
|
|
This module makes that question \textbf{decidable} -- with a framework of five elements:
|
|
\begin{itemize}
|
|
\item a \textbf{demand side} (what the application requires),
|
|
\item a \textbf{supply side} (what a structure can deliver),
|
|
\item a \textbf{matching rule}, a \textbf{decision record}, and a \textbf{measurement contract}.
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{codegray}{\small Lectures in German -- all materials, the script, and the exam in English.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Learning objectives}
|
|
After this module you can \dots
|
|
\begin{itemize}
|
|
\item explain why architecture selection is a \textbf{matching problem} -- no pattern is good or bad in itself
|
|
\item construct a \textbf{requirements profile} $R(a)$: scenarios with response measures, utility tree, weights
|
|
\item derive the \textbf{capability profile} $C(p)$ of seven architectural patterns from their tactics
|
|
\item run the \textbf{three-stage, non-compensatory match} and defend the result
|
|
\item record decisions as \textbf{ADRs} and attach a \textbf{measurement contract} (fitness functions, DORA)
|
|
\item engineer \textbf{AI components} into a system (Axis B) and use \textbf{AI tools} in the process (Axis A) -- with the same discipline
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Assessment}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\begin{block}{Project (50\,\%)}
|
|
\begin{itemize}
|
|
\item Portfolio Intelligence Platform (group work, all semester)
|
|
\item Requirements dossier (A1, week 3)
|
|
\item Architecture dossier: ADR $+$ measurement contract (A2, week 7)
|
|
\item Implementation (weeks 8--13)
|
|
\item Final presentation with \textbf{architecture defence} (week 14)
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\begin{block}{Written examination (50\,\%)}
|
|
\begin{itemize}
|
|
\item End of semester, 60 minutes
|
|
\item \textbf{Open book:} script and own notes, on paper
|
|
\item \textbf{Closed internet}
|
|
\item Focus: architecture reasoning -- profiles, matching, trade-offs
|
|
\end{itemize}
|
|
\end{block}
|
|
\end{column}
|
|
\end{columns}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The semester at a glance}
|
|
\small
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{1.5cm}p{4.3cm}p{4.2cm}p{2.7cm}@{}}
|
|
\toprule
|
|
\textbf{Weeks} & \textbf{Lectures} & \textbf{Exercise / project} & \textbf{Deliverables} \\
|
|
\midrule
|
|
1--3 & Part I: the framework -- dimensions, scenarios, weights & Kickoff; requirements workshops & \textbf{A1} (week 3) \\
|
|
4--7 & Part II: seven patterns; the match & Architecture study; the match; design & \textbf{A2 $+$ design gate} (week 7) \\
|
|
8--13 & Parts III--V: classes, fit at scale, the AI dimension & Implementation sprints $+$ coaching & Milestones (weeks 9/11/13) \\
|
|
14 & Synthesis, exam preparation & \textbf{Presentations $+$ defence} & \textbf{A3} \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\textbf{Design phase} (weeks 1--7): 2 lessons lecture $+$ 2 exercise -- design first, code later.\\
|
|
\textbf{Implementation phase} (weeks 8--13): 3 lessons lecture $+$ 1 coaching.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The course project}
|
|
\begin{projektbox}
|
|
You will design and build an \textbf{AI-augmented portfolio intelligence platform} (exercise sheet): market prices and company news in; deterministic risk, performance, and optimisation services; an LLM component turning news into validated \texttt{Insight}s; a multi-agent advisor that explains -- API-first. Everything this module teaches -- profiles, matching, ADRs, measurement -- you will apply to \emph{this} system, and defend at the end.
|
|
\end{projektbox}
|
|
|
|
\vspace{0.2cm}
|
|
\textbf{This week (kickoff exercise):}
|
|
\begin{itemize}
|
|
\item form teams; set up repository and tooling (including agentic coding tools)
|
|
\item build domain understanding; sketch a first ontology
|
|
\item collect \emph{raw} stakeholder wishes -- unfiltered, unweighted
|
|
\end{itemize}
|
|
|
|
\vspace{0.05cm}
|
|
\textcolor{codegray}{\small Next week those wishes become \emph{scenarios}; in week 3 they become your requirements profile (deliverable A1).}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SECTION 2: FOUR SYSTEMS, TWO FACTS
|
|
% ============================================
|
|
\section{Four Production Systems -- Two Facts}
|
|
|
|
\begin{frame}{Discussion}
|
|
\begin{thinkbox}
|
|
\begin{itemize}
|
|
\item Which software architectures can you name -- and which is the \emph{best} one?
|
|
\item Is a monolith outdated? Are microservices the professional default?
|
|
\item Netflix and Amazon run microservices. Should your two-person startup?
|
|
\item How would you even \emph{decide} -- and how would you defend the decision a year later?
|
|
\end{itemize}
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Four production systems, four structures}
|
|
\footnotesize
|
|
\begin{center}
|
|
\begin{tabular}{@{}p{2.2cm}p{4.5cm}p{6.4cm}@{}}
|
|
\toprule
|
|
\textbf{System} & \textbf{Structure} & \textbf{Documented outcome} \\
|
|
\midrule
|
|
Stack Overflow & \texttt{.NET} monolith, $\sim 9$ on-premise web servers & $\sim 1.3$ billion page views/month at $\sim 12$\,ms render -- scaled \emph{up}, not \emph{out} \\
|
|
Monzo & $\sim 2{,}800$ Go microservices; one language, one monorepo & retail banking at scale -- viable through extreme technological homogeneity \\
|
|
Segment & $> 140$ microservices, one per analytics destination & public 2018 \textbf{rollback to a monolith}: complexity crushed a small team \\
|
|
Prime Video & serverless orchestration: Step Functions, Lambda, S3 & consolidation into one process cut infrastructure cost by $> 90\,\%$ \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{codegray}{\scriptsize Sources: Craver 2016; Sewell 2024; Noonan 2018; Kolny 2023 -- each described by the system's own engineers.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Reading the four cases}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankgreen}{\textbf{Same problem, opposite structures}}
|
|
\begin{itemize}
|
|
\item Monzo and Stack Overflow both serve millions of users, interactively, at high availability
|
|
\item one does it with $\sim 2{,}800$ deployment units -- the other with essentially \textbf{one}
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankred}{\textbf{Fashionable structure, expensive failure}}
|
|
\begin{itemize}
|
|
\item Prime Video: distributed boundaries in the middle of a tightly coupled data flow
|
|
\item Segment: services cut along \emph{configuration instances}, not domain seams
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.4cm}
|
|
\begin{hinweisbox}
|
|
Neither fact proves monoliths good or microservices bad. Each failure was a \textbf{mismatch} between a workload and a structure -- not a bad pattern.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Two facts -- and the maxim they force}
|
|
\textbf{Fact 1: Structures differ radically for similar-looking problems.}\\
|
|
\textcolor{codegray}{\small The grade portal and Instagram share the same load question -- at different magnitudes.}
|
|
|
|
\vspace{0.3cm}
|
|
\textbf{Fact 2: No structure dominates.}\\
|
|
\textcolor{codegray}{\small For every pattern there is a documented context where it failed expensively -- and one where its unfashionable opposite succeeded at scale (Instagram, Shopify).}
|
|
|
|
\vspace{0.4cm}
|
|
\begin{keypoint}
|
|
\textbf{Maxim 1.} Patterns are neither good nor bad; only the \textbf{fit} between a requirements profile and a capability profile is.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.3cm}
|
|
The decision problem: choose among \textbf{non-dominated} alternatives whose value depends on the \textbf{match} -- knowing the choice is \textbf{expensive to reverse}.
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SECTION 3: WHAT ARCHITECTURE IS
|
|
% ============================================
|
|
\section{What Software Architecture Is}
|
|
|
|
\begin{frame}{What is ``software architecture''?}
|
|
The term has a documented tendency to mean \emph{everything and therefore nothing} (Fowler 2003).
|
|
|
|
\vspace{0.3cm}
|
|
\begin{definitionbox}[Software architecture (ISO/IEC/IEEE 42010:2022)]
|
|
``Fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes.''
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.3cm}
|
|
The standard also creates one \textbf{obligation} this module builds on directly:\\
|
|
a conformant architecture description \textbf{must record architecture decisions \emph{and their rationale}} (Clause 6.10).
|
|
\end{frame}
|
|
|
|
\begin{frame}{Four definition families -- each contributes one element}
|
|
\footnotesize
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{1. Normative (ISO 42010)}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item shared vocabulary: stakeholders, concerns, views
|
|
\item obligation: record decisions $+$ rationale
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\textcolor{bankblue}{\textbf{2. Decision-centric (Booch)}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the \emph{significant} decisions -- significance $=$ \textbf{cost of change}
|
|
\item lost decision knowledge (\emph{knowledge vaporization}) $\to$ erosion
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankblue}{\textbf{3. Social (Fowler/Johnson)}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item the experts' \emph{shared understanding}; ``the important stuff''
|
|
\item perceived \textbf{irreversibility} is the core -- architects work to \emph{remove} it
|
|
\end{itemize}
|
|
|
|
\vspace{0.1cm}
|
|
\textcolor{bankblue}{\textbf{4. Structural-analytic (SEI)}}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item ``the set of structures needed to reason about the system''
|
|
\item functionality is structure-neutral; structure determines \emph{how well}
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.05cm}
|
|
\begin{keypoint}
|
|
Distilled: \emph{architecture is the set of hard-to-reverse structural decisions that determine the quality behaviour of a system.}
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Architecture -- design -- implementation: a cost-of-change boundary}
|
|
\begin{center}
|
|
\footnotesize
|
|
\begin{tabular}{@{}llll@{}}
|
|
\toprule
|
|
\textbf{Level} & \textbf{Example decision} & \textbf{Reversal cost} & \\
|
|
\midrule
|
|
\textcolor{bankred}{Architecture} & monolith vs.\ microservices & months (a migration) & hard to reverse \\
|
|
\textcolor{bankblue}{Design} & choice of logging library & days (behind an interface) & revisable \\
|
|
\textcolor{bankgreen}{Implementation} & a variable name & seconds & trivial \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.3cm}
|
|
\begin{itemize}
|
|
\item The boundary is \textbf{gradual and context-dependent}: a database choice is architectural without a persistence abstraction -- closer to design in a hexagonal system
|
|
\item That is the point: \textbf{good architecture pushes decisions from irreversible towards reversible}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Two refusals -- enforced throughout the module}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankred}{\textbf{No fashion}}
|
|
\begin{itemize}
|
|
\item the dominance claim behind every hype cycle is falsified by the four production cases
|
|
\item no pattern is chosen because it is modern
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.48\textwidth}
|
|
\textcolor{bankred}{\textbf{No taste}}
|
|
\begin{itemize}
|
|
\item a claim that cannot be measured or falsified has no place in an architectural decision
|
|
\item ``elegant'' is not an argument -- a response measure is
|
|
\end{itemize}
|
|
\end{column}
|
|
\end{columns}
|
|
|
|
\vspace{0.4cm}
|
|
\begin{hinweisbox}
|
|
Every judgement in this module must trace to a \textbf{measurable} property of a \textbf{documented} context.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SECTION 4: THE FRAMEWORK
|
|
% ============================================
|
|
\section{The Framework at a Glance}
|
|
|
|
\begin{frame}{The framework: five elements}
|
|
\begin{definitionbox}[Architecture--application fit]
|
|
\footnotesize
|
|
\begin{enumerate}
|
|
\item \textbf{Requirements profile} $R(a) = \bigl(w_1, \dots, w_{12};\; S(a);\; K(a)\bigr)$ -- priority weights (High/Medium/Low), workload shape, hard constraints: the \emph{demand side}
|
|
\item \textbf{Capability profile} $C(p) = \bigl(c_1, \dots, c_{12};\; S(p)\bigr)$ -- ordinal ratings $\{++, +, \circ, -, --\}$ plus native workload shape: the \emph{supply side}
|
|
\item \textbf{Fit} $\mathrm{fit}(a,p)$ -- an ordinal, \emph{non-compensatory} match, computed by rules, not arithmetic
|
|
\item \textbf{Architecture Decision Record (ADR)} -- the permanent, auditable record of decision $+$ rationale
|
|
\item \textbf{Measurement contract} -- fitness functions and thresholds under which the decision is continuously tested
|
|
\end{enumerate}
|
|
\end{definitionbox}
|
|
|
|
\vspace{0.1cm}
|
|
\small Both profiles range over the \textbf{same twelve dimensions} -- introduced today, completed next week.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The framework as a pipeline -- and the map of the script}
|
|
\begin{center}
|
|
\resizebox{0.94\textwidth}{!}{%
|
|
\begin{tikzpicture}[
|
|
node distance=0.9cm and 1.0cm,
|
|
sysbox/.style={rectangle, draw, rounded corners=4pt, text width=3.2cm, minimum height=1.3cm, align=center, font=\small\sffamily, line width=0.8pt},
|
|
core/.style={sysbox, fill=bankblue!20, draw=bankblue},
|
|
comp/.style={sysbox, fill=bankgreen!15, draw=bankgreen},
|
|
meas/.style={sysbox, fill=violet!15, draw=aiviolet},
|
|
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black},
|
|
farr/.style={-{Stealth[length=2.5mm]}, thick, dashed, bankred}
|
|
]
|
|
\node[core] (klass) {Application class\\ \scriptsize (Part III)};
|
|
\node[core, right=0.9cm of klass] (profil) {Requirements profile $R(a)$\\ \scriptsize scenarios, utility tree};
|
|
\node[core, right=0.9cm of profil] (match) {Matching $\mathrm{fit}(a,p)$\\ \scriptsize against $C(p)$ (Parts II, IV)};
|
|
\node[comp, below=1.4cm of match] (adr) {Architecture decision\\ \scriptsize ADR with rationale};
|
|
\node[meas, left=0.9cm of adr] (fitness) {Measurement contract\\ \scriptsize fitness functions in CI/CD};
|
|
\node[meas, left=0.9cm of fitness] (ops) {Operation\\ \scriptsize DORA, SLOs, Lehman trends};
|
|
\draw[arr] (klass) -- (profil);
|
|
\draw[arr] (profil) -- (match);
|
|
\draw[arr] (match) -- (adr);
|
|
\draw[arr] (adr) -- (fitness);
|
|
\draw[arr] (fitness) -- (ops);
|
|
\draw[farr] (ops.north) -- node[midway, right=2pt, font=\scriptsize\sffamily, text=bankred, align=left] {profile drift (A5):\\ re-measure, evolve, supersede} (klass.south);
|
|
\end{tikzpicture}%
|
|
}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\small Demand is matched against supply; the match ends in a \textbf{recorded decision} with a \textbf{measurement contract} -- and operation continuously tests whether the decision's promises hold. The dashed edge is not decoration.
|
|
\end{frame}
|
|
|
|
\begin{frame}{The two AI axes of this module}
|
|
\begin{ailinse}[Where AI enters -- twice]
|
|
\begin{itemize}
|
|
\item \textbf{Axis A -- AI as a tool in the development process:} assistants and agents generate code, tests, documentation -- changing \emph{how} we make and guard architectural decisions.
|
|
\item \textbf{Axis B -- AI as a runtime component of the system:} an LLM, an ML model, an optimiser \emph{inside} the architecture -- bringing non-determinism, seconds-scale latency, per-call cost -- changing \emph{what} we must decide about.
|
|
\end{itemize}
|
|
\end{ailinse}
|
|
|
|
\vspace{0.3cm}
|
|
\begin{itemize}
|
|
\item Both axes are treated systematically in Part V of the script
|
|
\item Until then, \textcolor{aiviolet}{\textbf{AI Lens}} boxes flag where each axis touches the classical material
|
|
\item Your project lives on \textbf{both} axes: you build an AI-native system, using AI tools
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SECTION 5: SIX ASSUMPTIONS
|
|
% ============================================
|
|
\section{Six Load-Bearing Assumptions}
|
|
|
|
\begin{frame}{Six load-bearing assumptions}
|
|
The framework rests on six assumptions -- each anchored in established literature, each justifying \textbf{one element} of the framework.
|
|
|
|
\vspace{0.3cm}
|
|
\begin{center}
|
|
\small
|
|
\begin{tabular}{@{}llp{5.4cm}@{}}
|
|
\toprule
|
|
& \textbf{Assumption (short)} & \textbf{Justifies} \\
|
|
\midrule
|
|
A1 & architecture $=$ hard-to-reverse decisions & the ADR (element 4) \\
|
|
A2 & everything is a trade-off & the matching problem (element 3) \\
|
|
A3 & quality attributes drive architecture & the twelve dimensions \\
|
|
A4 & requirements $=$ measurable scenarios & the demand-side method (element 1) \\
|
|
A5 & a decision is a tested hypothesis & the measurement contract (element 5) \\
|
|
A6 & AI extends the space, not the method & D12 $+$ eval harness -- nothing else \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.2cm}
|
|
\textcolor{codegray}{\small The next three slides give each assumption its evidence.}
|
|
\end{frame}
|
|
|
|
\begin{frame}{A1 -- Decisions. \quad A2 -- Trade-offs.}
|
|
\small
|
|
\textbf{A1 -- Architecture is the set of significant, hard-to-reverse design decisions.}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item significance measured by \textbf{cost of change}; ``decisions you wish you could get right early''
|
|
\item lost decision knowledge is a documented cause of erosion $\to$ every decision becomes an \textbf{ADR}
|
|
\end{itemize}
|
|
|
|
\vspace{0.25cm}
|
|
\textbf{A2 -- Everything in software architecture is a trade-off} \textcolor{codegray}{(First Law, Richards \& Ford)}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item \dots and if you think you have found something that is not, \emph{you have not yet identified the trade-off}
|
|
\item the star ratings show it: microservices lead overall yet one star on cost and simplicity; layered is the exact mirror -- \textbf{dominance does not occur} $\to$ a matching problem exists
|
|
\item corollary: a proposal claiming \emph{only benefits} is incomplete \emph{by assumption}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{A3 -- Quality attributes. \quad A4 -- Scenarios.}
|
|
\small
|
|
\textbf{A3 -- Quality attributes, not functionality, drive architecture.}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item functionality is largely \textbf{structure-neutral}; structure determines \emph{how well}: performance, availability, modifiability, security
|
|
\item non-functional properties can rarely be refactored in afterwards
|
|
\item $\to$ the coordinate system consists of quality attributes -- never feature lists
|
|
\end{itemize}
|
|
|
|
\vspace{0.25cm}
|
|
\textbf{A4 -- Requirements are architecturally usable only as measurable scenarios.}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item ``the system shall be scalable'' decides nothing and tests nothing
|
|
\item decision-relevant only as a six-part scenario with a \textbf{response measure} -- number and unit
|
|
\item empirically, such requirements are vague and implicit -- they must be \emph{elicited} (next week: QAW, utility tree)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{A5 -- A tested hypothesis. \quad A6 -- AI absorbed.}
|
|
\small
|
|
\textbf{A5 -- An architecture decision is a hypothesis, continuously tested over the life cycle.}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item Lehman: change continually or decay; maintenance $\approx 40$--$80\,\%$ of life-cycle cost $\to$ design-time fit \textbf{decays}
|
|
\item re-measure: fitness functions in CI/CD, the four DORA metrics; change \emph{within} an architecture is cheap -- change \emph{of} it stays steep (Segment, Prime Video)
|
|
\end{itemize}
|
|
|
|
\vspace{0.3cm}
|
|
\textbf{A6 -- AI components extend the quality attribute space but do not change the method.}
|
|
\begin{itemize}\setlength\itemsep{1pt}
|
|
\item non-deterministic, fallible, latency-heavy, priced per call, subject to drift -- yet ISO/IEC 25010:2023 already carries the vocabulary (Safety, Flexibility, Security/resistance)
|
|
\item AI is \textbf{absorbed}: one new dimension (D12) $+$ one new test artefact (eval harness) -- \emph{the method stays}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Maxim 2}
|
|
\begin{keypoint}
|
|
\textbf{Maxim 2.} Because everything is a trade-off (A2) and quality drives structure (A3), architecture selection is \textbf{matching}; because decisions are costly to reverse (A1) and decay over time (A5), the match must be \textbf{documented} and \textbf{continuously measured}.
|
|
\end{keypoint}
|
|
|
|
\vspace{0.4cm}
|
|
\begin{center}
|
|
\large
|
|
demand $\;\to\;$ supply $\;\to\;$ match $\;\to\;$ record $\;\to\;$ test
|
|
\end{center}
|
|
|
|
\vspace{0.3cm}
|
|
\centering\small\textcolor{codegray}{This chain is the red line of the whole script -- every part instantiates one link at scale.}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SECTION 6: FROM QUESTIONS TO DIMENSIONS
|
|
% ============================================
|
|
\section{From Questions to Dimensions}
|
|
|
|
\begin{frame}{Imagine you are on the on-call rota \dots}
|
|
Forget frameworks for a moment. You are responsible -- personally -- for a system real people use. These questions \emph{will} find you:
|
|
|
|
\vspace{0.2cm}
|
|
\small
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \emph{The grade-release portal: what happens at 08:00 on publication day, when the whole semester refreshes the same page at once?}
|
|
\item \emph{An e-banking transfer: can the same payment ever be booked twice -- or disappear halfway?}
|
|
\item \emph{One component crashes at noon: does the whole application go dark, or does one widget show a spinner while everything else keeps working?}
|
|
\item \emph{The regulator calls: ``prove to us, step by step, what happened to this one transaction.'' How long does that take you?}
|
|
\item \emph{A new feature request arrives: how many places in the code must change -- one module, or seventeen?}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{\dots and the questions keep coming}
|
|
\small
|
|
\begin{itemize}\setlength\itemsep{3pt}
|
|
\item \emph{Two students must ship a working MVP in one semester: does the structure let them -- or does it demand a platform team they do not have?}
|
|
\item \emph{The monthly cloud bill triples: which part of the structure is spending the money, and what was it doing at 03:00?}
|
|
\item \emph{The team grows from three to thirty: do releases get faster -- or does everyone now wait for everyone else?}
|
|
\item \emph{Product adds a feature whose core is an LLM call: it takes eight seconds, costs money on every single request, and is sometimes confidently wrong. Where does that live in the architecture?}
|
|
\end{itemize}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{hinweisbox}
|
|
Every one of these questions has ended budgets, products, or careers.
|
|
\end{hinweisbox}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Three observations turn the list into a method}
|
|
\begin{enumerate}\setlength\itemsep{3pt}
|
|
\item \textbf{The questions recur} -- across wildly different systems: the grade portal and Instagram share the first question, merely at different magnitudes.
|
|
\item \textbf{None of them asks \emph{what} the system does} -- functionality is structure-neutral (A3); every question is about \emph{how well}, \emph{at what cost}, \emph{under which failure}.
|
|
\item \textbf{Each can be answered with a number} -- requests per second, double bookings per million, per cent of functionality lost, hours to an audit trail, modules touched per feature, cost per request \dots
|
|
\end{enumerate}
|
|
|
|
\vspace{0.2cm}
|
|
\begin{keypoint}
|
|
The twelve profile dimensions D1--D12 are exactly this: the recurring questions -- \textbf{grouped, named, and equipped with defined measures}. Nothing more mysterious than that.
|
|
\end{keypoint}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The twelve dimensions: five groups (preview)}
|
|
\small
|
|
\begin{center}
|
|
\begin{tabular}{@{}llp{6.6cm}@{}}
|
|
\toprule
|
|
\textbf{Group} & \textbf{Dimensions} & \textbf{The underlying question} \\
|
|
\midrule
|
|
Load and speed & D1, D2, D3 & does the structure survive its own success? \\
|
|
Correctness and trust & D4, D5, D6 & can it be trusted -- with money, uptime, history? \\
|
|
Change and delivery & D7, D8, D9 & what does the \emph{next} change cost? \\
|
|
Economics and organisation & D10, D11 & what does it cost to run -- and can teams work in parallel? \\
|
|
The new dimension & D12 & how cheaply can it host a slow, fallible, per-call-priced AI component? \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{center}
|
|
|
|
\vspace{0.15cm}
|
|
\begin{itemize}
|
|
\item Next week: all twelve, one by one -- each with its question, its vocabulary, and its \textbf{measurement instrument}
|
|
\item Both profiles -- demand $R(a)$ and supply $C(p)$ -- will be vectors over \emph{these} twelve dimensions
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Discussion}
|
|
\begin{thinkbox}
|
|
Pick an app you use daily.
|
|
\begin{itemize}
|
|
\item Which \textbf{three dimensions} dominate it?
|
|
\item On which dimension would its operator accept a \emph{bad} rating without losing sleep?
|
|
\item Compare with your neighbour -- where you disagree, you have found a \textbf{weight} discussion. Next week's utility tree resolves exactly that.
|
|
\end{itemize}
|
|
\end{thinkbox}
|
|
\end{frame}
|
|
|
|
% ============================================
|
|
% SUMMARY
|
|
% ============================================
|
|
\section{Summary}
|
|
|
|
\begin{frame}{Summary}
|
|
\small
|
|
\begin{enumerate}\setlength\itemsep{2pt}
|
|
\item Four production systems: structures differ radically, none dominates -- failures were \textbf{mismatches}
|
|
\item \textbf{Maxim 1:} patterns are neither good nor bad; only the \emph{fit} is
|
|
\item Architecture $=$ the \textbf{hard-to-reverse structural decisions} that determine quality behaviour
|
|
\item The framework: $R(a)$ (demand) $\to$ $C(p)$ (supply) $\to$ $\mathrm{fit}(a,p)$ $\to$ \textbf{ADR} $\to$ \textbf{measurement contract}
|
|
\item AI enters twice: \textbf{Axis A} (tool in the process), \textbf{Axis B} (component in the system)
|
|
\item Six assumptions A1--A6 carry the framework; the twelve dimensions are \textbf{recurring engineering questions} -- grouped, named, measurable
|
|
\item \textbf{Maxim 2:} match, then document, then measure
|
|
\end{enumerate}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Next week}
|
|
\begin{columns}[T]
|
|
\begin{column}{0.55\textwidth}
|
|
\textcolor{bankblue}{\textbf{Lecture 2 -- the twelve dimensions, completed}}
|
|
\begin{itemize}
|
|
\item D1--D12 one by one: question, vocabulary, instrument
|
|
\item why exactly these twelve (ISO/IEC 25010:2023)
|
|
\item six-part quality attribute scenarios
|
|
\item ASR, Quality Attribute Workshop
|
|
\item the utility tree: from scenarios to \textbf{weights}
|
|
\end{itemize}
|
|
\end{column}
|
|
\begin{column}{0.42\textwidth}
|
|
\textcolor{bankblue}{\textbf{Reading}}
|
|
\begin{itemize}
|
|
\item this week: script Part I, Sections 1--2
|
|
\item ahead: Part I, Section 3
|
|
\end{itemize}
|
|
|
|
\vspace{0.3cm}
|
|
\textcolor{bankblue}{\textbf{Exercise}}
|
|
\begin{itemize}
|
|
\item kickoff: teams, repo, domain, ontology sketch, raw stakeholder wishes
|
|
\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}
|