Yandrik/swa-dojo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: split large exercise blocks into smaller ones

Browse Source
This commit is contained in:
Yandrik
2025-07-10 13:01:53 +02:00
parent 8d39486d67
commit 4da8446f37
7 changed files with 148 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

42
data/swa_exercises.1.ts
View File

@ -1,10 +1,9 @@
import { Exercise } from '../types';
export const swaExercises1: Exercise[] = [
{
id: 'swa-1-1-einfuehrung',
title: '1.1 - SWA - Einführung',
id: 'swa-1-1-einfuehrung-a',
title: '1.1 - SWA - Einführung (Teil 1)',
parts: [
{
id: '1-1-a',
@ -20,7 +19,7 @@ export const swaExercises1: Exercise[] = [
points: 4,
type: 'text',
},
{
{
id: '1-1-c',
prompt: 'Wozu dienen Sichten in der Softwarearchitektur?',
solution: 'Sichten beleuchten unterschiedliche Aspekte der Architektur. Sie dienen dazu:\n- Zuständigkeiten zu trennen (z.B. Entwickler vs. Betreiber).\n- Die Architektur aus unterschiedlichen Perspektiven zu zeigen (z.B. statische Struktur vs. dynamisches Verhalten).\n- Für unterschiedliche Stakeholder verständlich zu sein.',
@ -34,6 +33,13 @@ export const swaExercises1: Exercise[] = [
points: 4,
type: 'text',
},
],
explanation: '### Lösungserklärung\n\n**Softwarearchitektur** ist die grundlegende Organisation eines Systems. Sie definiert die Bausteine, deren Beziehungen und die Prinzipien, die den Entwurf leiten. Zur Kommunikation werden verschiedene **Sichten** (Perspektiven) verwendet.\n\n**Ziele & Aufgaben** ist es, **Leitplanken** für Entwickler zu bieten, um Komplexität zu managen und ein gemeinsames Verständnis zu schaffen.\n\n**Architekturerosion**: Wenn die Architektur nicht aktiv gepflegt wird, verfällt die Struktur. Dies führt zum Aufbau technischer Schulden, die zukünftige Änderungen erschweren.\n\n### Quellen\n*Folien 1.1, Seite 22-66*'
},
{
id: 'swa-1-1-einfuehrung-b',
title: '1.1 - SWA - Einführung (Teil 2)',
parts: [
{
id: '1-1-e',
prompt: 'Erläutere das Big-ball-of-Mud Antipattern.',
@ -55,13 +61,20 @@ export const swaExercises1: Exercise[] = [
points: 4,
type: 'text',
},
{
{
id: '1-1-h',
prompt: 'Wie kommt man zu einer „guten" Architektur?',
solution: 'Man erreicht eine gute Architektur durch einen methodischen Prozess:\n- Verständnis erlangen (Anforderungen, Randbedingungen, Risiken)\n- Entwurf: Strukturen schaffen (Bausteine, Ablauf), fachlich beginnen und technisch verfeinern\n- Konzepte für technische Querschnittsthemen entwickeln (Persistenz, UI, etc.)\n- Bedarfsgerechte, kontinuierliche Kommunikation und Dokumentation\nEs gibt keine "Silberkugel", sondern man verwendet Methoden und Heuristiken.',
points: 5,
type: 'text',
},
],
explanation: '### Lösungserklärung\n\n**Architekturerosion & Technische Schulden**: Ein Endzustand der Architekturerosion ist der **"Big Ball of Mud"**, ein System ohne erkennbare Struktur. **Symptome** dafür sind Starrheit, Zerbrechlichkeit, Unbeweglichkeit und Zähigkeit. Ein **guter Architekturprozess** ist methodisch und iterativ, um dem entgegenzuwirken.\n\n### Quellen\n*Folien 1.1, Seite 22-66*'
},
{
id: 'swa-1-1-einfuehrung-c',
title: '1.1 - SWA - Einführung (Teil 3)',
parts: [
{
id: '1-1-i',
prompt: 'Wie funktioniert Architektur im agilen vs. klassischen Software-Entwicklungsprozess?',
@ -69,7 +82,7 @@ export const swaExercises1: Exercise[] = [
points: 5,
type: 'text',
},
{
{
id: '1-1-j',
prompt: 'Erläutere das LRM = Least Reasonable Moment – Prinzip und wie es in agilen Projekten helfen kann. Nenne ein konkretes Beispiel.',
solution: 'Das LRM (Least Reasonable Moment) ist ein Prinzip aus der Lean-Software-Entwicklung, das besagt, dass wichtige architektonische Entscheidungen so spät wie möglich getroffen werden sollten, um:\n- Mehr Informationen zu sammeln\n- Unsicherheiten zu reduzieren\n- Flexibilität zu bewahren\n\nBeispiel: Bei einem neuen E-Commerce-System muss das Team zwischen relationalen und NoSQL-Datenbanken wählen. Durch Warten auf den LRM können sie mehr Informationen über Datenmodelle und Leistungsanforderungen sammeln, bevor sie eine endgültige Entscheidung treffen.',
@ -91,11 +104,11 @@ export const swaExercises1: Exercise[] = [
type: 'text',
}
],
explanation: '### Lösungserklärung\n\n**Softwarearchitektur** ist die grundlegende Organisation eines Systems. Sie definiert die Bausteine, deren Beziehungen und die Prinzipien, die den Entwurf leiten. Zur Kommunikation werden verschiedene **Sichten** (Perspektiven) verwendet.\n\n**Ziele & Aufgaben** ist es, **Leitplanken** für Entwickler zu bieten, um Komplexität zu managen und ein gemeinsames Verständnis zu schaffen. Ein **guter Architekturprozess** ist methodisch und iterativ.\n\n**Architekturerosion & Technische Schulden**: Wenn die Architektur nicht aktiv gepflegt wird, verfällt die Struktur (**Erosion**). Dies führt zum Aufbau **technischer Schulden**, die zukünftige Änderungen erschweren und verteuern. Ein Endzustand davon ist der **"Big Ball of Mud"**, ein System ohne erkennbare Struktur. **Symptome** dafür sind Starrheit, Zerbrechlichkeit, Unbeweglichkeit und Zähigkeit.\n\n**Prozesse**: Im **klassischen** Vorgehen wird die Architektur vorab detailliert geplant (**Big Design Up Front**). Im **agilen** Prozess entsteht sie **evolutionär**. Entscheidungen werden nach dem **LRM-Prinzip** (Least Reasonable Moment) so spät wie möglich getroffen, um auf Basis maximaler Informationen zu entscheiden.\n\n**Rolle des Architekten**: Die Architektin ist nicht nur für den technischen Entwurf zuständig, sondern agiert als Kommunikatorin und Vermittlerin zwischen verschiedenen **Stakeholdern** (Fachbereich, Entwicklung, Management, Betrieb).\n\n### Quellen\n*Folien 1.1, Seite 22-66*'
explanation: '### Lösungserklärung\n\n**Prozesse**: Im **klassischen** Vorgehen wird die Architektur vorab detailliert geplant (**Big Design Up Front**). Im **agilen** Prozess entsteht sie **evolutionär**. Entscheidungen werden nach dem **LRM-Prinzip** (Least Reasonable Moment) so spät wie möglich getroffen, um auf Basis maximaler Informationen zu entscheiden.\n\n**Rolle des Architekten**: Die Architektin ist nicht nur für den technischen Entwurf zuständig, sondern agiert als Kommunikatorin und Vermittlerin zwischen verschiedenen **Stakeholdern** (Fachbereich, Entwicklung, Management, Betrieb).\n\n### Quellen\n*Folien 1.1, Seite 22-66*'
},
{
id: 'swa-1-2-anforderungen',
title: '1.2 - SWA - Anforderungen & Kontext',
id: 'swa-1-2-anforderungen-a',
title: '1.2 - SWA - Anforderungen & Kontext (Teil 1)',
parts: [
{
id: '1-2-a',
@ -125,7 +138,14 @@ export const swaExercises1: Exercise[] = [
points: 5,
type: 'text',
},
{
],
explanation: '### Lösungserklärung\n\n**Anforderungsanalyse**: Eine Anforderung muss präzise sein, damit eine gute Architektur entworfen werden kann. Unklarheiten führen zu Fehlentwicklungen.\n\n**Qualitätsszenarien**: Ein Werkzeug, um nicht-funktionale Anforderungen konkret und messbar zu machen. Das Schema (Quelle, Stimulus, etc.) stellt sicher, dass alle relevanten Aspekte bedacht werden.\n\n**ISO/IEC 9126**: Ein Standard zur Klassifizierung von Softwarequalität, der hilft, Diskussionen über Qualität zu strukturieren.\n\n**Randbedingungen & Risikofaktoren**: **Randbedingungen** sind harte Fakten, die die Architektur von außen beeinflussen (z.B. Gesetze, bestehende IT-Infrastruktur). **Risikofaktoren** sind potenzielle Probleme, die aktiv gemanagt werden müssen (z.B. die Unerfahrenheit des Teams mit einer neuen Technologie).\n\n### Quellen\n*Folien 1.2, Seite 15-58*'
},
{
id: 'swa-1-2-anforderungen-b',
title: '1.2 - SWA - Anforderungen & Kontext (Teil 2)',
parts: [
{
id: '1-2-e',
prompt: 'Erstellen Sie ein Systemkontextdiagramm für ein einfaches Online-Shopsystem in Mermaid-Syntax. Berücksichtigen Sie Kunden, ein externes Zahlungssystem und ein externes Versandsystem.',
solution: '```mermaid\ngraph TD\n subgraph Systemkontext Online-Shop\n A[Online-Shop] -- Bestelldaten --> B(Kunde)\n B -- Bestellung/Zahlung --> A\n end\n\n A -- Zahlungsanfrage --> C{Zahlungssystem}\n C -- Zahlungsbestätigung --> A\n\n A -- Versandauftrag --> D(Versandsystem)\n D -- Sendungsstatus --> A\n```',
@ -133,6 +153,6 @@ export const swaExercises1: Exercise[] = [
type: 'mermaid',
}
],
explanation: '### Lösungserklärung\n\n**Anforderungsanalyse**: Eine Anforderung muss präzise sein, damit eine gute Architektur entworfen werden kann. Unklarheiten führen zu Fehlentwicklungen.\n\n**Qualitätsszenarien**: Ein Werkzeug, um nicht-funktionale Anforderungen konkret und messbar zu machen. Das Schema (Quelle, Stimulus, etc.) stellt sicher, dass alle relevanten Aspekte bedacht werden.\n\n**ISO/IEC 9126**: Ein Standard zur Klassifizierung von Softwarequalität, der hilft, Diskussionen über Qualität zu strukturieren.\n\n**Randbedingungen & Risikofaktoren**: **Randbedingungen** sind harte Fakten, die die Architektur von außen beeinflussen (z.B. Gesetze, bestehende IT-Infrastruktur). **Risikofaktoren** sind potenzielle Probleme, die aktiv gemanagt werden müssen (z.B. die Unerfahrenheit des Teams mit einer neuen Technologie).\n\n**Systemkontextdiagramm**: Zeigt das System als Blackbox und definiert seine Grenzen, indem es alle externen Akteure und die Datenflüsse zwischen ihnen darstellt. Dies schafft ein grundlegendes Verständnis darüber, was Teil des Systems ist und was nicht.\n\n### Quellen\n*Folien 1.2, Seite 15-58*'
explanation: '### Lösungserklärung\n\n**Systemkontextdiagramm**: Zeigt das System als Blackbox und definiert seine Grenzen, indem es alle externen Akteure und die Datenflüsse zwischen ihnen darstellt. Dies schafft ein grundlegendes Verständnis darüber, was Teil des Systems ist und was nicht.\n\n### Quellen\n*Folien 1.2, Seite 15-58*'
}
];