Merge pull request 'Übungen Tag 2 - 5' (#1) from fk/exercises into main
Reviewed-on: #1 Reviewed-by: Florian Herzog <florian.herzog@fhgr.ch>
This commit is contained in:
commit
d82452b764
9
.vscode/mcp.json
vendored
Normal file
9
.vscode/mcp.json
vendored
Normal file
@ -0,0 +1,9 @@
|
||||
{
|
||||
"servers": {
|
||||
"datalake-fhgr": {
|
||||
"url": "https://datalake-fhgr-mcp.aeol.in",
|
||||
"type": "http"
|
||||
}
|
||||
},
|
||||
"inputs": []
|
||||
}
|
||||
Binary file not shown.
Binary file not shown.
@ -649,6 +649,24 @@ Status: accepted | supersedes ADR-004\\[4pt]
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
\section{Excercise}
|
||||
\begin{frame}{This week's exercise: architecture draft}
|
||||
\begin{projektbox}
|
||||
\footnotesize Come up with a architecture draft for your project, considering the patterns discussed earlier.
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item Identify potential system boundaries
|
||||
\item Sketch the main components and their interactions with eachother
|
||||
\item Discuss which architectural patterns are ruled out by your requirements profile $R(a)$ and constraints
|
||||
\item Justify your choices based on the requirements profile and constraints
|
||||
\item Create a UML System Diagram of your proposed components and their interactions
|
||||
\end{itemize}
|
||||
\textbf{Deliverable:} UML System Diagram and documentation justifying your architectural choices
|
||||
\end{projektbox}
|
||||
\vspace{0.15cm}
|
||||
\begin{hinweisbox}
|
||||
\small Not a warm-up: the architecture will be used to implement your project, later modifications are possible but will lead to increased effort and potential reworks.
|
||||
\end{hinweisbox}
|
||||
\end{frame}
|
||||
% ============================================
|
||||
% END
|
||||
% ============================================
|
||||
|
||||
Binary file not shown.
@ -33,6 +33,20 @@
|
||||
\colorlet{backcolour}{linen} % FHGR linen (E1D3B5)
|
||||
\definecolor{aiviolet}{HTML}{6B4E71} % muted plum, kept distinct for the AI lens
|
||||
|
||||
\lstdefinestyle{pythoncode}{
|
||||
language=Python,
|
||||
basicstyle=\ttfamily\scriptsize,
|
||||
keywordstyle=\color{bankblue}\bfseries,
|
||||
stringstyle=\color{bankgreen!70!black},
|
||||
commentstyle=\color{codegray}\itshape,
|
||||
numberstyle=\tiny\color{codegray},
|
||||
showstringspaces=false,
|
||||
columns=fullflexible,
|
||||
frame=single,
|
||||
rulecolor=\color{bankblue!50},
|
||||
backgroundcolor=\color{bankblue!3!white}
|
||||
}
|
||||
|
||||
% 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}}
|
||||
@ -748,20 +762,6 @@ Three readings:
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{This week's exercise: architecture study I}
|
||||
\begin{projektbox}
|
||||
\small
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Inspect} Apache Fineract (34 modules, one deployable) and \texttt{cosmicpython/code} (\texttt{domain/}, \texttt{service\_layer/}, \texttt{adapters/}, \texttt{entrypoints/}) -- find the boundaries, find the ports
|
||||
\item \textbf{Shortlist candidates for the platform core}: which of L / MM / MM$+$HX carries your requirements profile from A1?
|
||||
\item \textbf{Draw the C4 context and container diagrams} of your platform draft
|
||||
\end{itemize}
|
||||
\end{projektbox}
|
||||
|
||||
\vspace{0.3cm}
|
||||
\small While you study the repositories, apply the two-minute habit: \textbf{licence and maintenance status first} -- one of this week's study objects carries a no-derivatives licence, and finding that yourself is part of the exercise.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Summary}
|
||||
\small
|
||||
\begin{enumerate}\setlength\itemsep{2pt}
|
||||
@ -773,6 +773,189 @@ Three readings:
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% WEB SCRAPING TRAINING
|
||||
% ============================================
|
||||
\section{Practical Web Scraping}
|
||||
|
||||
\begin{frame}{Web scraping in practice: Scrapy + BeautifulSoup}
|
||||
\footnotesize
|
||||
\begin{definitionbox}[Goal]
|
||||
Collect article content from the web, select the real text body, clean boilerplate, and store only the content that matters for downstream AI extraction.
|
||||
\end{definitionbox}
|
||||
|
||||
\vspace{0.1cm}
|
||||
A typical pipeline is:
|
||||
\begin{enumerate}\setlength\itemsep{2pt}
|
||||
\item crawl candidate URLs with \textbf{Scrapy}
|
||||
\item fetch and parse HTML with \textbf{BeautifulSoup}
|
||||
\item select likely article containers
|
||||
\item clean noise, boilerplate, navigation, and ads
|
||||
\item normalise to a structured text payload for downstream analysis
|
||||
\end{enumerate}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{examplebox}[Minimal pattern]
|
||||
\footnotesize
|
||||
\texttt{Scrapy} owns the crawl; \texttt{BeautifulSoup} owns DOM selection and text cleanup.
|
||||
\end{examplebox}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{How crawling with Scrapy works}
|
||||
\footnotesize
|
||||
\begin{center}
|
||||
\begin{tikzpicture}[
|
||||
sysbox/.style={rectangle, draw, rounded corners=4pt, align=center, font=\small\sffamily, line width=0.8pt},
|
||||
crawlstep/.style={sysbox, fill=bankblue!15, draw=bankblue, minimum width=2.3cm, minimum height=0.9cm},
|
||||
arr/.style={-{Stealth[length=2.5mm]}, thick, gray!60!black}
|
||||
]
|
||||
\node[crawlstep] (scheduler) at (-5.1,0) {Scheduler};
|
||||
\node[crawlstep] (engine) at (-2.4,0) {Engine};
|
||||
\node[crawlstep] (downloader) at (0.5,0) {Downloader};
|
||||
\node[crawlstep] (spider) at (3.5,0) {Spider};
|
||||
\node[crawlstep] (pipeline) at (6.4,0) {Item pipeline};
|
||||
\draw[arr] (scheduler) -- (engine);
|
||||
\draw[arr] (engine) -- (downloader);
|
||||
\draw[arr] (downloader) -- (spider);
|
||||
\draw[arr] (spider) -- (pipeline);
|
||||
\draw[arr, rounded corners=6pt] (pipeline.south) |- (-0.8,-1.2) -| (engine.south);
|
||||
\node[font=\footnotesize\sffamily, text=gray!60!black, align=center] at (0.7,-1.8)
|
||||
{request queue $\rightarrow$ fetch $\rightarrow$ parse $\rightarrow$ yield items / new URLs};
|
||||
\end{tikzpicture}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item the \textbf{engine} orchestrates the crawl and schedules requests
|
||||
\item the \textbf{downloader} fetches pages and returns HTML responses
|
||||
\item the \textbf{spider} parses links and extracts data from each page
|
||||
\item new URLs are queued; items flow to the \textbf{item pipeline} for cleaning and storage
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}[fragile]{Concrete Scrapy spider example}
|
||||
\scriptsize
|
||||
\begin{lstlisting}[style=pythoncode]
|
||||
import scrapy
|
||||
class NewsSpider(scrapy.Spider):
|
||||
name = "news"
|
||||
start_urls = ["https://example.com/news"]
|
||||
def parse(self, response):
|
||||
for href in response.css("article a::attr(href)").getall():
|
||||
yield response.follow(href, callback=self.parse_article)
|
||||
def parse_article(self, response):
|
||||
yield {
|
||||
"url": response.url,
|
||||
"title": response.css("h1::text").get(default="").strip(),
|
||||
"text": " ".join(response.css("article p::text").getall()),
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\vspace{0.04cm}
|
||||
\begin{keypoint}
|
||||
\scriptsize \texttt{response.follow()} queues URLs; \texttt{yield \{...\}} emits extracted items.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}[fragile]{Scrapy + BeautifulSoup in the item pipeline}
|
||||
\scriptsize
|
||||
\begin{lstlisting}[style=pythoncode]
|
||||
# settings.py
|
||||
ITEM_PIPELINES = {"news.pipelines.SoupPipeline": 300}
|
||||
|
||||
# pipelines.py
|
||||
from bs4 import BeautifulSoup
|
||||
|
||||
class SoupPipeline:
|
||||
def process_item(self, item, spider):
|
||||
soup = BeautifulSoup(item["html"], "html.parser")
|
||||
body = soup.find("article") or soup.find("main") or soup
|
||||
paras = [p.get_text(" ", strip=True) for p in body.select("p")]
|
||||
item["text"] = "\n".join(p for p in paras if len(p) > 20)
|
||||
item.pop("html", None)
|
||||
return item
|
||||
\end{lstlisting}
|
||||
|
||||
\vspace{0.06cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize Spiders crawl pages; pipelines clean each yielded item before storage.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Cleaning strategies for webpage content}
|
||||
\footnotesize
|
||||
\textcolor{bankblue}{\textbf{1. Prefer semantic structure}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item use \texttt{article}, \texttt{main}, \texttt{header}, and ancestor checks
|
||||
\item prefer elements with meaningful labels such as \texttt{aria-label}, \texttt{role="main"}, or heading context
|
||||
\item discard navigation, menus, footers, share bars, cookie banners, and ad containers
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textcolor{bankblue}{\textbf{2. Heuristics for likely article text}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item prefer blocks with \textbf{low link density} and \textbf{high text density}
|
||||
\item reject nodes where most characters belong to links, menus, or repeated widgets
|
||||
\item keep paragraphs with enough text length and sentence structure; drop short nav fragments
|
||||
\end{itemize}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\textcolor{bankblue}{\textbf{3. Use a specialised library}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{trafilatura} is a good recommendation for article extraction from noisy HTML
|
||||
\item it handles readability extraction, metadata, and boilerplate removal better than a raw DOM dump in many news cases
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{How XPath and CSS selectors work}
|
||||
\footnotesize
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textcolor{bankblue}{\textbf{XPath}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item selects nodes by path through the DOM tree
|
||||
\item good for expressing structural rules and ancestor/descendant conditions
|
||||
\item examples:\newline
|
||||
\texttt{//article//p}\newline
|
||||
\texttt{//main//*[not(self::nav)]//p}\newline
|
||||
\texttt{//h1 | //h2}
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textcolor{bankblue}{\textbf{CSS selectors}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item selects elements by tag, class, id, or relationships
|
||||
\item concise for common HTML patterns and faster to read in a team
|
||||
\item examples:\newline
|
||||
\texttt{main article p}\newline
|
||||
\texttt{article > p}\newline
|
||||
\texttt{.content p, .story p}\newline
|
||||
\texttt{a[href*="/news/"]}
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
|
||||
\vspace{0.12cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize XPath is more precise for tree navigation; CSS selectors are often more readable for common markup patterns. In practice, combine both: use CSS for convenience, XPath for hard structural filters.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Selection rule of thumb}
|
||||
\small
|
||||
\begin{enumerate}\setlength\itemsep{3pt}
|
||||
\item Start with \textbf{semantic containers}: \texttt{article}, \texttt{main}, or a labelled section
|
||||
\item Move inward to paragraphs and headings, not to the whole page
|
||||
\item Drop content types that are clearly non-article: nav, footer, sidebar, ad widgets, social blocks
|
||||
\item If the page is noisy, compute textual density and link density and prefer the most article-like region
|
||||
\end{enumerate}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{hinweisbox}
|
||||
\footnotesize There is no universal selector. The best extraction pipeline is always a combination of semantics, heuristics, and validation against a small benchmark of real pages.
|
||||
\end{hinweisbox}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Next week}
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.55\textwidth}
|
||||
@ -798,6 +981,22 @@ Three readings:
|
||||
\end{columns}
|
||||
\end{frame}
|
||||
|
||||
|
||||
|
||||
|
||||
\begin{frame}{This week's exercise: naïve architecture draft}
|
||||
\begin{projektbox}
|
||||
\footnotesize Come up with a naïve architecture draft for your project, considering the scenarios and requirements discussed earlier.
|
||||
\begin{itemize}\setlength\itemsep{1pt}
|
||||
\item Identify potential system boundaries
|
||||
\item Sketch the main components and their interactions with eachother
|
||||
\item Identify potential single points of failure in your architecture
|
||||
\end{itemize}
|
||||
\textbf{Deliverable:} rough sketch of a naïve architecture for your project
|
||||
% Anmerkung FK: Übung ist beabsichtigt wenig zielgerichtet, soll den studierenden verbildlichen wo sie am Anfang der VL stehen und später einen Vergleich ermöglichen mit Anwendung des in der VL erarbeiteten Wissens und Verständnisses %
|
||||
\end{projektbox}
|
||||
\end{frame}
|
||||
|
||||
% ============================================
|
||||
% END
|
||||
% ============================================
|
||||
|
||||
Binary file not shown.
@ -137,7 +137,7 @@
|
||||
\item Sagas vs.\ ACID: why compensation is not rollback
|
||||
\item \textbf{EDA} -- Event-driven architecture: what an intermediary gives and takes
|
||||
\item Resilience primitives for distributed edges
|
||||
\item This week's exercise: architecture study II
|
||||
\item This week's exercise: Ontologies \& JSON Schema
|
||||
\end{enumerate}
|
||||
\end{frame}
|
||||
|
||||
@ -587,18 +587,164 @@ D12 AI integrability & $\circ$ & $++$ & synchronous chains vs.\ absorbing queues
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{This week's exercise: architecture study II}
|
||||
% ============================================
|
||||
% ONTOLOGIES AND JSON SCHEMA
|
||||
% ============================================
|
||||
\section{Ontologies and JSON Schema}
|
||||
|
||||
\begin{frame}{Ontology basics: a data schema for meaning}
|
||||
\footnotesize
|
||||
\begin{definitionbox}[Ontology]
|
||||
An ontology is a shared model of a domain: its \textbf{concepts}, \textbf{properties}, relations, and constraints.
|
||||
\end{definitionbox}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textcolor{bankblue}{\textbf{What it describes}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Classes}: Article, Organisation, Person
|
||||
\item \textbf{Properties}: title, publishedAt, mentions
|
||||
\item \textbf{Relations}: Article \emph{mentions} Organisation
|
||||
\item \textbf{Constraints}: publication date required
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textcolor{bankblue}{\textbf{Why it matters for AI}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item shared vocabulary across sources and prompts
|
||||
\item separates meaning from one input format
|
||||
\item supports parseability and structural correctness
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
|
||||
\begin{hinweisbox}
|
||||
A schema does \textbf{not} ensure factual correctness, only structural validity.
|
||||
\end{hinweisbox}
|
||||
|
||||
\vspace{0.08cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize An ontology is the \textbf{meaning model}; JSON Schema validates one representation of it.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{JSON Schema basics}
|
||||
\footnotesize
|
||||
\begin{definitionbox}[JSON Schema]
|
||||
JSON Schema is a declarative specification for the \textbf{shape and constraints} of JSON data. It can validate instances, document an interface, and guide structured LLM output.
|
||||
\end{definitionbox}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{center}
|
||||
\begin{tabular}{@{}p{3.0cm}p{8.8cm}@{}}
|
||||
\toprule
|
||||
\textbf{Schema concept} & \textbf{Question it answers} \\
|
||||
\midrule
|
||||
\texttt{type} & Is the value an object, array, string, number, boolean, or null? \\
|
||||
\texttt{properties} & Which named fields can an object contain? \\
|
||||
\texttt{required} & Which fields must be present? \\
|
||||
\texttt{items} & What does each element of an array look like? \\
|
||||
\texttt{enum} / \texttt{const} & Which values, or which exact value, are allowed? \\
|
||||
\texttt{format} & Does a string follow a known format such as a date or URI? \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\end{center}
|
||||
|
||||
\vspace{0.12cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize A valid JSON document is not automatically a valid \textbf{domain record}: the schema makes the expected contract explicit.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{JSON Schema: the basic building blocks}
|
||||
\footnotesize
|
||||
\begin{columns}[T]
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textcolor{bankblue}{\textbf{Structure}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \texttt{object} groups named fields
|
||||
\item \texttt{array} repeats a defined item schema
|
||||
\item \texttt{properties} nests objects and relationships
|
||||
\item \texttt{required} distinguishes essential from optional data
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\begin{column}{0.48\textwidth}
|
||||
\textcolor{bankblue}{\textbf{Restrictions}}
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \texttt{minLength}, \texttt{minimum}, and \texttt{pattern}
|
||||
\item \texttt{enum} for controlled vocabularies
|
||||
\item \texttt{additionalProperties: false} for strict extraction
|
||||
\item \texttt{oneOf} / \texttt{anyOf} for alternatives
|
||||
\end{itemize}
|
||||
\end{column}
|
||||
\end{columns}
|
||||
|
||||
\vspace{0.15cm}
|
||||
\begin{examplebox}[A useful extraction contract]
|
||||
\footnotesize Require the article's \texttt{title}, \texttt{source}, and \texttt{publishedAt}; allow an optional array of \texttt{organisations}; restrict \texttt{sentiment} to a small, documented set of values.
|
||||
\end{examplebox}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\small The schema should be \textbf{strict enough to catch omissions} but \textbf{flexible enough} to represent legitimate variation between news outlets.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}[fragile]{Example: a JSON Schema for a financial news article}
|
||||
\scriptsize
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize, columns=fullflexible, frame=single, rulecolor=\color{bankblue!50}, backgroundcolor=\color{bankblue!3!white}]
|
||||
{
|
||||
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
||||
"title": "FinancialNewsArticle",
|
||||
"type": "object",
|
||||
"required": ["title", "source", "publishedAt", "summary"],
|
||||
"properties": {
|
||||
"title": {"type": "string", "minLength": 1},
|
||||
"source": {"type": "string", "minLength": 1},
|
||||
"publishedAt": {"type": "string", "format": "date-time"},
|
||||
"summary": {"type": "string", "minLength": 20},
|
||||
"organisations": {"type": "array", "items": {"type": "string"}},
|
||||
"sentiment": {"enum": ["positive", "neutral", "negative"]}
|
||||
},
|
||||
"additionalProperties": false
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
\begin{keypoint}
|
||||
\footnotesize This contract gives the LLM a target, the validator a test, and the benchmark a consistent unit.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Construct an ontology in four steps}
|
||||
\footnotesize
|
||||
\begin{enumerate}\setlength\itemsep{7pt}
|
||||
\item \textbf{Identify key information}\\
|
||||
Extract the concepts and facts needed to answer the project's questions: article, source, date, organisations, claims, and market impact.
|
||||
\item \textbf{Determine constraints}\\
|
||||
Decide what is required, which types and formats apply, which values are controlled, and what must be rejected as incomplete.
|
||||
\item \textbf{Determine hierarchy (nesting)}\\
|
||||
Group information that belongs together: an article contains a publication record, entities, and possibly structured claims or events.
|
||||
\item \textbf{Compose together}\\
|
||||
Combine concepts, relations, and constraints into one coherent ontology, then express as JSON Schema.
|
||||
\end{enumerate}
|
||||
|
||||
\vspace{0.1cm}
|
||||
\begin{keypoint}
|
||||
\footnotesize Validate the result against three different articles. If the schema cannot represent a legitimate case, the model is unfinished; if it accepts everything, the constraints are too weak.
|
||||
\end{keypoint}
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{This week's exercise: Ontologies \& JSON Schema}
|
||||
\begin{projektbox}
|
||||
\small
|
||||
\begin{itemize}\setlength\itemsep{2pt}
|
||||
\item \textbf{Design the edges} of your platform: the ingestion queue for analysis requests, and \textbf{resilience against external-API failure} -- timeouts, retries with backoff, circuit breaker, fallback, DLQ on every external call
|
||||
\item \textbf{Sketch the service contracts}: which events exist, which schemas, who produces, who consumes
|
||||
\item \textbf{Matrix pre-filter}: hold your A1 requirements profile against all candidate patterns seen so far -- which survive stage 1 (shape gate) and stage 2 (vetoes)?
|
||||
\item \textbf{Identify Required Information}: From the financial news articles you scraped in last weeks exercise
|
||||
\item \textbf{Draft a Json Schema}: Which fields and data types are required to capture the necessary information from the financial news articles
|
||||
\item \textbf{Build a small Benchmark}: Manually extract the information from 3 news articles of different news outlets
|
||||
\item \textbf{Design a Prompt}: Come up with a system prompt for an LLM of your choice to extract the required information from the financial news articles
|
||||
\item \textbf{Evaluate the Prompt}: Run the prompt against the benchmark articles and assess the results
|
||||
\item \textbf{Document}: Document the results and how you derived the prompts
|
||||
\end{itemize}
|
||||
\end{projektbox}
|
||||
|
||||
\vspace{0.25cm}
|
||||
\small Next week you will run the \textbf{full three-stage match} and take the architecture decision -- the pre-filter is its preparation.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}{Summary}
|
||||
|
||||
99
Folien/Zusammenfassung_Vorlesungen_1-14.md
Normal file
99
Folien/Zusammenfassung_Vorlesungen_1-14.md
Normal file
@ -0,0 +1,99 @@
|
||||
# AISE502: Lecture Overview
|
||||
|
||||
## Lecture 1: Architecture as a Decision Problem
|
||||
- Understand architecture as the design, justification, and operation of software structure over time.
|
||||
- Learn the framework elements: demand, supply, matching rule, decision record, and measurement contract.
|
||||
- Distinguish significant, hard-to-reverse architecture decisions from ordinary implementation choices.
|
||||
- Compare production systems and see how architectural strengths depend on context.
|
||||
- Understand the project, assessment, assumptions, and the two AI dimensions.
|
||||
|
||||
## Lecture 2: The Twelve Dimensions and Measurable Requirements
|
||||
- Learn the twelve quality dimensions, including scalability, latency, integrity, availability, security, cost, and AI integrability.
|
||||
- Understand why quality attributes need instruments and measurable response measures.
|
||||
- Turn stakeholder wishes into scenarios and architecturally significant requirements.
|
||||
- Build a utility tree and assign High, Medium, and Low weights.
|
||||
- Assemble a requirements profile from weights, workload shape, and hard constraints.
|
||||
|
||||
## Lecture 3: Supply, Matching, and Decision Records
|
||||
- Survey seven patterns: Layered, Modular Monolith, Hexagonal, Microservices, Event-Driven, Pipes-and-Filters, and Serverless.
|
||||
- Learn how tactics and structural mechanisms produce capability ratings.
|
||||
- Apply the three-stage, non-compensatory fit procedure to an advisory platform.
|
||||
- Understand why High requirements can act as veto conditions rather than being averaged away.
|
||||
- Record architecture choices with ADR/MADR and a measurement contract.
|
||||
|
||||
## Lecture 4: Patterns I
|
||||
- Understand Layered Architecture and the cost of cross-layer changes.
|
||||
- Learn how a Modular Monolith combines one deployment with domain-oriented module boundaries.
|
||||
- Learn Hexagonal Architecture and dependency inversion through a technology-neutral domain core.
|
||||
- Derive quality profiles from topology, tactics, engineering implications, and operations.
|
||||
- Identify anti-patterns, measurable alarms, and suitable application contexts.
|
||||
|
||||
## Lecture 5: Patterns II
|
||||
- Understand Microservices as independently deployable business-capability quanta with service-owned data.
|
||||
- Analyse the benefits and costs of microservices, including team scaling and distributed failure.
|
||||
- Distinguish sagas and compensating actions from genuine rollback.
|
||||
- Understand Event-Driven Architecture as temporal decoupling through an intermediary.
|
||||
- Apply timeouts, retries, circuit breakers, and fallbacks at distributed boundaries.
|
||||
|
||||
## Lecture 6: Pipelines, Serverless, and the C10 Class
|
||||
- Understand Pipes-and-Filters for reproducible and composable batch, data, retrieval, and ML pipelines.
|
||||
- Understand Serverless/FaaS, including scale-to-zero, cold starts, and cost behaviour under sustained load.
|
||||
- Compare all seven patterns and understand why partitioning can be preferable to distribution.
|
||||
- Analyse the AI-native advisory-platform class C10 and its inherited requirements.
|
||||
- Perform an initial match and justify a hexagonal modular monolith with pipeline and event-driven edges.
|
||||
|
||||
## Lecture 7: Formal Fit and the Matching Matrix
|
||||
- Work through examples of the shape gate, veto rule, and holistic ordinal comparison.
|
||||
- Formalise the three-stage fit procedure and its non-compensatory logic.
|
||||
- Interpret individual cells and the complete 7 x 10 matching matrix.
|
||||
- Read the matrix by rows and columns and understand the role of hybrid architectures.
|
||||
- Introduce fitness functions, DORA metrics, and the measurement contract.
|
||||
|
||||
## Lecture 8: Application Classes C1-C5
|
||||
- Learn how application classes package recurring requirements, workload shape, measures, and constraints.
|
||||
- Derive profiles for Core Banking and Social Media, including their contrasting consistency and availability needs.
|
||||
- Analyse Back-Office and ERP systems, where workflow, integration, and governance dominate.
|
||||
- Analyse E-Commerce requirements such as latency, availability, evolvability, and revenue sensitivity.
|
||||
- Compare the five profiles and connect them to the project walking skeleton.
|
||||
|
||||
## Lecture 9: Application Classes C6-C9
|
||||
- Learn the Scientific Simulation profile, including reproducibility, deterministic seeds, batch windows, and compute cost.
|
||||
- Learn Decision Support/BI requirements such as refresh contracts and consistent views.
|
||||
- Analyse Real-Time/IoT Streaming, focusing on ordering, correctness, failure handling, and response measures.
|
||||
- Analyse Collaboration/Messaging, including fan-out, push delivery, tail latency, archiving, and tenancy.
|
||||
- Compare all ten application profiles.
|
||||
|
||||
## Lecture 10: Fit II: Hybrids and Evolution
|
||||
- Understand how fit changes with workload, organisation, constraints, and measured behaviour.
|
||||
- Study hybrids and evolution paths through industry examples and the Strangler Fig pattern.
|
||||
- Learn the eight-step decision procedure from requirements elicitation through measurement and evolution.
|
||||
- Follow a worked project decision ADR and connect it to the architecture dossier.
|
||||
- Examine why “consistent core, asynchronous edges” recurs across application classes.
|
||||
|
||||
## Lecture 11: Fit III: Measurement and Organisational Limits
|
||||
- Define architectural fitness functions as objective, executable integrity checks.
|
||||
- Distinguish dependency checks, performance/cost budgets, and chaos experiments.
|
||||
- Learn the four DORA metrics and the limits of causal interpretation.
|
||||
- Build a layered measurement cascade and a reference measurement contract.
|
||||
- Extend fit analysis to Conway’s Law, Team Topologies, and the limits of the theory.
|
||||
|
||||
## Lecture 12: The AI Dimension I
|
||||
- Separate AI used in the development process from AI used as a runtime component.
|
||||
- Compare productivity experiments and understand how moderator variables reconcile their results.
|
||||
- Understand the verification bottleneck: generated output is cheap, while verification and integration remain binding constraints.
|
||||
- Learn foundations for safe runtime AI integration, including gateways, queues, ontology guards, and explicit contracts.
|
||||
- Treat the evaluation harness as an engineering artefact connected to fitness functions and guardrails.
|
||||
|
||||
## Lecture 13: Threats, AI-Adjusted Fit, and Agent Orchestration
|
||||
- Analyse prompt injection, untrusted model output, excessive agency, and defence-in-depth for LLM systems.
|
||||
- Treat regulatory obligations such as the EU AI Act as hard constraints.
|
||||
- Determine how AI changes the C10 profile, capability matrix, and MLOps requirements.
|
||||
- Understand agent orchestration as an emergent eighth composition pattern and examine its economics.
|
||||
- Synthesise the method using scenarios, tactics, profiles, ADRs, and measurement contracts.
|
||||
|
||||
## Lecture 14: Synthesis, Presentations, and Architecture Defence
|
||||
- Consolidate the semester’s five parts and the central architecture decision method.
|
||||
- Review the two AI axes, twelve dimensions, application classes, capability profiles, fit matrix, ADRs, and measurement contracts.
|
||||
- Prepare for the written examination using the learning objectives, framework map, and main tables.
|
||||
- Present and defend the project architecture, trade-offs, measurements, and role of AI.
|
||||
- Conduct peer reviews and complete the final deliverable.
|
||||
Loading…
x
Reference in New Issue
Block a user