152 lines
13 KiB
TypeScript
152 lines
13 KiB
TypeScript
import { Exercise } from '../types';
|
|
|
|
export const swaExercises2: Exercise[] = [
|
|
{
|
|
id: 'swa-2-1-datenmodell',
|
|
title: '2.1 - SWA - Fachliches Datenmodell',
|
|
parts: [
|
|
{
|
|
id: '2-1-a',
|
|
prompt: 'Was sollte ein fachliches Datenmodell beinhalten und welche Notation wird typischerweise verwendet?',
|
|
solution: 'Ein fachliches Datenmodell sollte aus fachlicher Sicht (nicht Implementierungssicht) erstellt werden und die relevanten Konzepte, Beziehungen und Regeln der Domäne darstellen.\n\nEs enthält typischerweise:\n- Klassen, die fachliche Konzepte darstellen\n- Attribute mit fachlichen Datentypen (keine technischen Typen wie int, string)\n- Assoziationen zwischen den Klassen mit Kardinalitäten\n\nAls Notation wird oft ein UML-Klassendiagramm verwendet.',
|
|
points: 6,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-1-b',
|
|
prompt: 'Worin besteht der Unterschied zwischen Entitäten und fachlichen Datentypen (Value Types)? Geben Sie jeweils ein Beispiel an.',
|
|
solution: 'Entitäten haben eine eindeutige Identität und einen Lebenszyklus (z.B. Kunde mit Kundennummer). Fachliche Datentypen (Value Types) modellieren nur Werte ohne eigene Identität (z.B. ISBN, Adresse, Datum).',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-1-c',
|
|
prompt: 'Worin besteht der Unterschied zwischen technischen und fachlichen Schlüsseln? Geben Sie außerdem jeweils ein Beispiel an.',
|
|
solution: 'Technische Schlüssel werden aus technischen Gründen hinzugefügt, haben keine fachliche Bedeutung und werden oft automatisch generiert (z.B. ID = 42389). Fachliche Schlüssel haben eine fachliche Bedeutung und sind oft für Menschen lesbar (z.B. Kundennummer = "K-12345").',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-1-d',
|
|
prompt: 'Nach welchen Kriterien sollte man ein fachliches Datenmodell bewerten?',
|
|
solution: 'Ein gutes fachliches Datenmodell sollte:\n- Fachliche Konzepte korrekt abbilden\n- Fachliche (keine technischen) Datentypen verwenden\n- Sinnvolle Beziehungen mit korrekten Kardinalitäten darstellen\n- Verständlich für Fachexperten sein\n- Konsistent in der Namensgebung und redundanzfrei sein',
|
|
points: 6,
|
|
type: 'text',
|
|
}
|
|
],
|
|
explanation: '### Lösungserklärung\n\n**Fachliches Datenmodell**: Dies ist ein zentrales Artefakt, um die Domäne zu verstehen. Es fokussiert auf das **Was** (fachliche Konzepte), nicht das **Wie** (technische Implementierung). Es ist eine Kommunikationsgrundlage zwischen Fachexperten und Entwicklern.\n\n**Entitäten vs. Fachliche Datentypen (Value Objects)**\n- **Entitäten** sind Objekte, die durch ihre **eindeutige Identität** definiert werden. Ein Kunde bleibt derselbe Kunde, auch wenn sich seine Adresse ändert.\n- **Fachliche Datentypen** (Value Objects) haben **keine Identität**. Sie werden durch ihre Werte definiert. Eine Adresse "Musterstraße 1" ist identisch mit jeder anderen Adresse "Musterstraße 1".\n\n**Technische vs. Fachliche Schlüssel**\n- **Fachliche Schlüssel** sind Identifikatoren aus der Domäne (z.B. ISBN). Nachteil: Sie können sich ändern.\n- **Technische Schlüssel** (Surrogatschlüssel) sind künstliche IDs ohne fachliche Bedeutung (z.B. eine auto-inkrementierte Zahl). Vorteil: Sie sind stabil.\n\n### Quellen\n*Folien 2.1, Seite 4-29*'
|
|
},
|
|
{
|
|
id: 'swa-2-3-canvas',
|
|
title: '2.3 - SWA - Architecture Inception Canvas',
|
|
parts: [
|
|
{
|
|
id: '2-3-a',
|
|
prompt: 'Was ist das primäre Ziel eines Canvas im Kontext der Softwareentwicklung?',
|
|
solution: 'Das primäre Ziel eines Canvas ist, ein komplexes Thema (wie eine Geschäfts- oder Architektur-Idee) in klar abgegrenzte Bereiche aufzuteilen und visuell zu strukturieren. Es dient als Werkzeug zur Kommunikation und Analyse, um schnell Klarheit zu schaffen und die Zusammenarbeit im Team zu fördern.',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-3-b',
|
|
prompt: 'Was ist das Architecture Inception Canvas?',
|
|
solution: 'Das Architecture Inception Canvas ist ein strukturiertes Framework zur frühzeitigen Erfassung architekturrelevanter Informationen. Es dient als gemeinsame Grundlage für Architekturentscheidungen und hilft dabei, den Kontext und die wesentlichen Einflussfaktoren eines Projekts schnell zu verstehen.',
|
|
points: 6,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-3-c',
|
|
prompt: 'Erklären Sie drei der Kategorien des Architecture Inception Canvas und geben Sie für jede Kategorie ein konkretes Beispiel an.',
|
|
solution: '1. Functional Overview: Beschreibt die wichtigsten funktionalen Anforderungen. Beispiel: "Benutzer können Produkte suchen, in den Warenkorb legen und Bestellungen aufgeben".\n2. Quality Goals: Die drei wichtigsten Qualitätsziele für die Architektur. Beispiel: "Das System muss bei 10.000 gleichzeitigen Nutzern eine Antwortzeit unter 1 Sekunde gewährleisten".\n3. Technical Constraints: Technische Anforderungen, die die Freiheit einschränken. Beispiel: "Das System muss mit der bestehenden Oracle-Datenbank kompatibel sein".',
|
|
points: 7,
|
|
type: 'text',
|
|
}
|
|
],
|
|
explanation: '### Lösungserklärung\n\n**Zweck des Canvas**\nEin Canvas ist ein Kommunikations- und Analysewerkzeug. Das **Architecture Inception Canvas** im Speziellen hilft Teams, zu Beginn eines Projekts schnell ein gemeinsames Verständnis ("Big Picture") für die wichtigsten architektonischen Treiber zu entwickeln. Es strukturiert die Diskussion und stellt sicher, dass wesentliche Aspekte nicht übersehen werden.\n\n**Ausgewählte Kategorien**\n- **Functional Overview:** Fasst den Kern dessen zusammen, was das System tun soll.\n- **Quality Goals:** Zwingt das Team zur Priorisierung der wichtigsten nicht-funktionalen Anforderungen (Qualitätsziele), die die Architektur maßgeblich beeinflussen.\n- **Technical Constraints:** Listet nicht verhandelbare technische Randbedingungen auf, die den Lösungsraum von vornherein einschränken.\n\n### Quellen\n*Folien 2.3, Seite 2-6*'
|
|
},
|
|
{
|
|
id: 'swa-2-5-sichten-a',
|
|
title: '2.5 - SWA - Entwurf der Sichten (Teil 1)',
|
|
parts: [
|
|
{
|
|
id: '2-5-a',
|
|
prompt: 'Welche Sichten gibt es nach Starke und was zeigen sie?',
|
|
solution: 'Nach Gernot Starke gibt es vier Sichten:\n1. Kontextabgrenzung: Zeigt die Systemgrenzen und Beziehungen zu Nachbarsystemen.\n2. Bausteinsicht: Zeigt die statische Struktur des Systems mit seinen Komponenten.\n3. Laufzeitsicht: Zeigt das dynamische Verhalten und Zusammenspiel der Bausteine.\n4. Verteilungssicht: Zeigt die technische Infrastruktur und das Mapping der Software darauf.',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-5-b',
|
|
prompt: 'Erklären Sie den Unterschied zwischen T-Architektur und A-Architektur.',
|
|
solution: 'T-Architektur (Technische Architektur) befasst sich mit dem technischen Rahmen und wiederverwendbaren Querschnittskonzepten (z.B. Logging, Authentifizierung).\n\nA-Architektur (Anwendungsarchitektur) befasst sich mit dem Entwurf der fachlich getriebenen, systemspezifischen Bausteine (z.B. Kundenverwaltung, Bestellprozess).',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-5-c',
|
|
prompt: 'Nennen Sie drei wichtige Eigenschaften einer Komponente.',
|
|
solution: '1. Versteckt Implementierung (Information Hiding): Die interne Realisierung ist nach außen nicht sichtbar.\n2. Bietet Schnittstellen: Definierte Schnittstellen ermöglichen die kontrollierte Kommunikation.\n3. Klar definierte Verantwortlichkeit: Jede Komponente hat einen spezifischen, klar abgegrenzten Zweck.',
|
|
points: 4,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-5-d',
|
|
prompt: 'Was versteht man unter "loser" vs. "enger" Kopplung zwischen Komponenten? Welche ist zu bevorzugen und warum?',
|
|
solution: 'Lose Kopplung bedeutet, dass Komponenten nur wenige Details voneinander kennen und über stabile Schnittstellen interagieren. Enge Kopplung bedeutet, dass Komponenten viele Details voneinander kennen. Lose Kopplung ist zu bevorzugen, da sie die Wartbarkeit, Testbarkeit und Flexibilität des Systems verbessert.',
|
|
points: 5,
|
|
type: 'text',
|
|
}
|
|
],
|
|
explanation: '### Lösungserklärung\n\n**Architektursichten** sind verschiedene Perspektiven auf ein System. Die vier Sichten nach Starke (Kontext, Baustein, Laufzeit, Verteilung) sind ein Standard, um Architektur umfassend zu beschreiben.\n\nDie **Bausteinsicht** ist die statische "Landkarte" des Systems. Sie zeigt **Komponenten**, die idealerweise eine klare **Verantwortlichkeit** haben, ihre Implementierung verstecken (**Information Hiding**) und über definierte **Schnittstellen** kommunizieren. Das Ziel ist **lose Kopplung** (wenig Abhängigkeiten) und **hohe Kohäsion** (alles in einer Komponente gehört eng zusammen). Hierbei unterscheidet man **A-Architektur** (fachlich) von **T-Architektur** (technisch).\n\n### Quellen\n*Folien 2.5, Seite 3-55*'
|
|
},
|
|
{
|
|
id: 'swa-2-5-sichten-b',
|
|
title: '2.5 - SWA - Entwurf der Sichten (Teil 2)',
|
|
parts: [
|
|
{
|
|
id: '2-5-e',
|
|
prompt: 'Skizzieren Sie sinnvolle Abhängigkeiten zwischen den Komponenten eines E-Commerce-Systems (OrderManagement, CustomerManagement, ProductCatalog, Payment, Shipping).',
|
|
solution: 'Sinnvolle Abhängigkeiten wären:\n- OrderManagement → CustomerManagement (benötigt Kundendaten)\n- OrderManagement → ProductCatalog (benötigt Produktdaten)\n- OrderManagement → Payment (nutzt Zahlungsabwicklung)\n- OrderManagement → Shipping (nutzt Versandabwicklung)\n\nDie Abhängigkeiten zeigen von der zentralen Prozesskomponente (OrderManagement) auf die unterstützenden, stabileren Komponenten.',
|
|
points: 6,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-5-f',
|
|
prompt: 'Nennen Sie drei Regeln für gutes API-Design.',
|
|
solution: '1. Präzise und selbsterklärende Namen: Methodennamen und Parameter sollten ihre Funktion klar beschreiben.\n2. Geheimnisprinzip wahren: Die API sollte das "Was" beschreiben, nicht das "Wie". Keine Implementierungsdetails preisgeben.\n3. Klare Fehlerbeschreibung: Exceptions und Fehlerfälle sollten aussagekräftig und dokumentiert sein.',
|
|
points: 5,
|
|
type: 'text',
|
|
},
|
|
{
|
|
id: '2-5-g',
|
|
prompt: 'Erstellen Sie ein Sequenzdiagramm (Laufzeitsicht) für einen einfachen Bestellprozess in Mermaid-Syntax. Beteiligt sein sollen ein Client, ein OrderService und ein PaymentService.',
|
|
solution: '```mermaid\nsequenceDiagram\n participant Client\n participant OrderService\n participant PaymentService\n\n Client->>OrderService: createOrder(orderDetails)\n activate OrderService\n OrderService->>PaymentService: processPayment(paymentDetails)\n activate PaymentService\n PaymentService-->>OrderService: paymentSuccessful\n deactivate PaymentService\n OrderService-->>Client: orderConfirmation\n deactivate OrderService\n```',
|
|
points: 6,
|
|
type: 'mermaid',
|
|
},
|
|
{
|
|
id: '2-5-h',
|
|
prompt: 'Beurteilen Sie kritisch: Ein Entwicklungsteam argumentiert: "Wir brauchen keine expliziten Sichten - unser Code ist gut strukturiert und selbsterklärend."',
|
|
solution: 'Diese Aussage ist kritisch zu betrachten. Selbst gut strukturierter Code zeigt nur Implementierungsdetails, aber kein "Big Picture". Sichten bieten eine höhere Abstraktionsebene, die für die Kommunikation mit verschiedenen Stakeholdern (Nicht-Entwickler), die Einarbeitung neuer Teammitglieder und für grundlegende Architekturentscheidungen unerlässlich ist.',
|
|
points: 6,
|
|
type: 'text',
|
|
}
|
|
],
|
|
explanation: '### Lösungserklärung\n\nEin gutes **API-Design** ist entscheidend für lose Kopplung. Es sollte präzise, selbsterklärend und stabil sein.\n\nDie **Laufzeitsicht** (z.B. als **Sequenzdiagramm**) zeigt das dynamische Zusammenspiel der statischen Bausteine zur Erfüllung eines Anwendungsfalls. Sie validiert, ob die Bausteinsicht funktioniert.\n\nAuch bei gutem Code sind **explizite Sichten** unverzichtbar. Sie bieten eine Abstraktionsebene über dem Code, die für Kommunikation und das Verständnis des Gesamtsystems ("Big Picture") notwendig ist.\n\n### Quellen\n*Folien 2.5, Seite 3-55*'
|
|
},
|
|
{
|
|
id: 'swa-2-5-sichten-c',
|
|
title: '2.5 - SWA - Entwurf der Sichten (Teil 3)',
|
|
parts: [
|
|
{
|
|
id: '2-5-i',
|
|
prompt: 'In welcher Reihenfolge geht man bei der Sichtenerstellung am besten vor?',
|
|
solution: 'Eine empfohlene, iterative Reihenfolge ist:\n1. Start mit Kontextabgrenzung (definiert die Systemgrenzen).\n2. Erste Verfeinerung in einer Bausteinsicht (Grobentwurf).\n3. Plausibilisierung durch eine Laufzeitsicht (funktioniert der Entwurf für wichtige Szenarien?).\n4. Weitere Verfeinerung der Bausteinsicht und der anderen Sichten im Wechsel.',
|
|
points: 5,
|
|
type: 'text',
|
|
}
|
|
],
|
|
explanation: '### Lösungserklärung\n\nDie **Erstellung der Sichten erfolgt iterativ**, oft beginnend mit dem Kontext, dann der Bausteinsicht und der Laufzeitsicht im Wechsel, um den Entwurf zu validieren und zu verfeinern.\n\n### Quellen\n*Folien 2.5, Seite 3-55*'
|
|
}
|
|
];
|