139 lines
11 KiB
TypeScript
139 lines
11 KiB
TypeScript
|
||
import { Exercise } from '../types';
|
||
|
||
export const swaExercises3: Exercise[] = [
|
||
{
|
||
id: 'swa-3-1-backend-a',
|
||
title: '3.1 - SWA - Technische Architektur Backend (Teil 1)',
|
||
parts: [
|
||
{
|
||
id: '3-1-a',
|
||
prompt: 'Nennen Sie vier Aufgaben eines Backends.',
|
||
solution: '1. Funktionalität über APIs exponieren\n2. Geschäftslogik implementieren\n3. Daten verwalten und persistieren\n4. Sicherheit gewährleisten (Authentifizierung & Autorisierung)',
|
||
points: 4,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-1-b',
|
||
prompt: 'Erläutern Sie die Unterscheidung: „spezifiziertes und unspezifiziertes Verhalten" im Fehlerfall. Geben Sie konkrete Beispiele an.',
|
||
solution: 'Spezifiziertes Verhalten ist Teil der API-Definition und für den Client erwartbar (z.B. CustomerNotFoundException). Unspezifiziertes Verhalten ist unerwartet und resultiert aus Programmierfehlern (z.B. NullPointerException).',
|
||
points: 5,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-1-c',
|
||
prompt: 'Wo sollte unspezifiziertes Verhalten in der Architektur behandelt werden?',
|
||
solution: 'Unspezifiziertes Verhalten (z.B. NullPointerException) sollte in einer zentralen Sicherheitsfacade an der Grenze des Backends behandelt werden. Diese fängt die Fehler ab, loggt sie und transformiert sie in eine generische Fehlermeldung (z.B. HTTP 500 Internal Server Error), um keine Implementierungsdetails nach außen preiszugeben.',
|
||
points: 4,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-1-d',
|
||
prompt: 'Zeichnen Sie die traditionelle 3-Schichten-Architektur eines Backends in Mermaid-Syntax.',
|
||
solution: '```mermaid\ngraph TD\n A[Facade Layer] --> B[Logic Layer]\n B --> C[Data Access Layer]\n```',
|
||
points: 4,
|
||
type: 'mermaid'
|
||
}
|
||
],
|
||
explanation: '### Lösungserklärung\n\n**Aufgaben des Backends**: Das Backend führt die Kernlogik aus, verwaltet Daten und stellt Funktionalität über APIs bereit.\n\n**Fehlerverhalten**: **Spezifizierte Fehler** (z.B. "Benutzer nicht gefunden") sind Teil des API-Vertrags. **Unspezifizierte Fehler** (Bugs) dürfen nie direkt zum Client durchdringen. Eine **Sicherheitsfacade** fängt sie ab und gibt eine generische Meldung zurück.\n\n**Architekturmuster**:\n- **Traditionelle Schichtenarchitektur**: Strikte Top-Down-Abhängigkeiten (UI → Logik → Daten). Einfach zu verstehen, aber oft starr.\n\n### Quellen\n*Folien 3.1, Seite 4-27*'
|
||
},
|
||
{
|
||
id: 'swa-3-1-backend-b',
|
||
title: '3.1 - SWA - Technische Architektur Backend (Teil 2)',
|
||
parts: [
|
||
{
|
||
id: '3-1-e',
|
||
prompt: 'Zeichnen Sie die typische Schichten-Architektur eines Backends nach der Use Case Driven Schichtenarchitektur.',
|
||
solution: '```mermaid\ngraph TD\n A[Service-Schicht] --> B[Use Case-Schicht]\n B --> C[DAO-Schicht]\n C --> D[Entity-Schicht]\n```',
|
||
points: 4,
|
||
type: 'mermaid'
|
||
},
|
||
{
|
||
id: '3-1-f',
|
||
prompt: 'Welche Abhängigkeiten sind zwischen den Schichten von zwei Komponenten (A und B) in einer Use Case Driven Architektur erlaubt und welche sollten vermieden werden?',
|
||
solution: 'Erlaubt sind horizontale Abhängigkeiten auf der Service- und Use Case-Ebene (z.B. Service A ruft Service B auf). Zu vermeiden sind direkte Abhängigkeiten auf die unteren Schichten einer anderen Komponente (z.B. Service A ruft DAO B auf), da dies die Kapselung und Datenhoheit der Komponente B verletzen würde.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-1-g',
|
||
prompt: 'Vergleichen Sie klassische Schichtenarchitektur und Hexagonale Architektur hinsichtlich ihrer Abhängigkeitsrichtungen und Flexibilität.',
|
||
solution: 'Klassische Schichtenarchitektur: Die Abhängigkeiten verlaufen streng von oben nach unten (Top-Down). Die Flexibilität ist mittel, da Änderungen an unteren Schichten (z.B. DB) obere Schichten beeinflussen können.\n\nHexagonale Architektur: Die Abhängigkeiten verlaufen immer von außen nach innen. Der Kern bleibt technologieunabhängig. Dies bietet hohe Flexibilität, da technische Adapter (z.B. für DB, UI) leicht ausgetauscht werden können, ohne den Kern zu ändern.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-1-h',
|
||
prompt: 'Wozu dient ein DTO und was bedeutet die Abkürzung? Geben Sie außerdem ein Beispiel an für einen Use Case "Bestellung anzeigen".',
|
||
solution: 'DTO steht für Data Transfer Object. Es ist ein reiner Datencontainer für den Datentransfer zwischen Schichten oder Systemen, um Entkopplung zu schaffen.\nBeispiel für `OrderDetailsDTO`:\n```json\n{\n "orderId": "O-123",\n "customerName": "Max Mustermann",\n "orderDate": "2023-10-27",\n "totalAmount": 99.98,\n "items": [\n { "productId": "P-456", "productName": "Laptop", "quantity": 1, "unitPrice": 99.98 }\n ]\n}\n```',
|
||
points: 6,
|
||
type: 'text',
|
||
}
|
||
],
|
||
explanation: '### Lösungserklärung\n\n**Architekturmuster**:\n- **Use Case Driven Architektur**: Eine Variante, die die Logik-Schicht in spezifische Anwendungsfälle (Use Cases) unterteilt.\n- **Hexagonale Architektur** (Ports & Adapters): Kehrt die Abhängigkeiten um. Äußere Adapter (UI, DB) hängen vom Kern (Logik) ab. Der Kern bleibt unabhängig von der Technologie, was die Austauschbarkeit und Testbarkeit massiv verbessert.\n\n**Data Transfer Object (DTO)**: Ein DTO ist ein Objekt nur zum Transport von Daten. Es entkoppelt die Schnittstelle von der internen Implementierung (z.B. Datenbank-Entities). Dies macht die Architektur flexibler und robuster gegenüber Änderungen.\n\n### Quellen\n*Folien 3.1, Seite 4-27*'
|
||
},
|
||
{
|
||
id: 'swa-3-3-integration-a',
|
||
title: '3.3 - SWA – Integrationstechnologien (Teil 1)',
|
||
parts: [
|
||
{
|
||
id: '3-3-a',
|
||
prompt: 'Nennen Sie die zwei grundsätzlichen Muster für die Standardintegration zwischen zwei Systemen und beschreiben Sie jeweils zwei charakteristische Eigenschaften.',
|
||
solution: '1. Synchrone Integration: Der Aufrufer wartet auf eine Antwort. Eigenschaften: engere Kopplung, direkte Rückmeldung.\n2. Asynchrone Integration: Der Sender schickt eine Nachricht und wartet nicht. Eigenschaften: losere Kopplung, höhere Resilienz bei Ausfällen.',
|
||
points: 4,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-3-b',
|
||
prompt: 'Welche HTTP-Methoden werden bei REST APIs typischerweise für CRUD-Operationen (Create, Read, Update, Delete) verwendet?',
|
||
solution: '- Erstellen (Create): POST\n- Lesen (Read): GET\n- Vollständige Aktualisierung (Update): PUT\n- Löschen (Delete): DELETE\n(Partielle Aktualisierung: PATCH)',
|
||
points: 4,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-3-c',
|
||
prompt: 'Definieren Sie beispielhafte REST-API Endpunkte (Methode, URL, Statuscodes) für eine Kundenverwaltung.',
|
||
solution: '- GET /customers (200 OK): Alle Kunden lesen\n- GET /customers/{id} (200 OK / 404 Not Found): Einen bestimmten Kunden lesen\n- POST /customers (201 Created): Einen neuen Kunden erstellen\n- PUT /customers/{id} (200 OK / 204 No Content): Einen Kunden vollständig aktualisieren\n- DELETE /customers/{id} (204 No Content): Einen Kunden löschen',
|
||
points: 5,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-3-d',
|
||
prompt: 'Erläutern Sie den Begriff EDA (Event Driven Architecture).',
|
||
solution: 'EDA (Event Driven Architecture) ist ein Architekturmuster, bei dem die Kommunikation und der Ablauf durch Ereignisse (Events) gesteuert werden. Komponenten (Producer, Consumer) sind lose über einen Event-Broker gekoppelt und kommunizieren asynchron. Dies fördert Skalierbarkeit und Resilienz.',
|
||
points: 5,
|
||
type: 'text',
|
||
}
|
||
],
|
||
explanation: '### Lösungserklärung\n\n**Integrationsmuster**: **Synchron** (z.B. REST-Aufruf) bedeutet, der Aufrufer wartet auf eine Antwort. **Asynchron** (z.B. Messaging) bedeutet, der Sender schickt eine Nachricht und wartet nicht.\n\n**REST**: Ein Architekturstil, der HTTP-Methoden für CRUD-Operationen auf Ressourcen nutzt. Die URL-Struktur (`/customers/{id}`) identifiziert die Ressource, die Methode (`GET`, `POST`, etc.) die Operation.\n\n**EDA (Event Driven Architecture)**: Ein Paradigma, das auf asynchroner Kommunikation durch **Events** basiert. Es führt zu extrem loser Kopplung und ist die Grundlage für viele moderne Microservice-Systeme.\n\n### Quellen\n*Folien 3.3, Seite 5-42*'
|
||
},
|
||
{
|
||
id: 'swa-3-3-integration-b',
|
||
title: '3.3 - SWA – Integrationstechnologien (Teil 2)',
|
||
parts: [
|
||
{
|
||
id: '3-3-e',
|
||
prompt: 'Wozu dient das Protokoll AMQP und was sind seine Vorteile?',
|
||
solution: 'AMQP (Advanced Message Queuing Protocol) ist ein offenes, plattformunabhängiges Protokoll für den asynchronen Nachrichtenaustausch.\n\nVorteile:\n- Interoperabilität zwischen verschiedenen Systemen und Sprachen.\n- Zuverlässige Nachrichtenübermittlung (mit Queues, Bestätigungen etc.).\n- Flexibles Routing von Nachrichten (z.B. Publish/Subscribe).',
|
||
points: 5,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-3-f',
|
||
prompt: 'Ein E-Commerce-System soll mit einem Zahlungsdienstleister integriert werden. Welche Integrationsart (synchron/asynchron) und Technologie (REST/Messaging) würden Sie empfehlen und warum?',
|
||
solution: 'Eine kombinierte Lösung ist oft am besten:\n- Synchrone Integration via REST für die initiale Zahlungsautorisierung, da der Kunde eine sofortige Rückmeldung benötigt.\n- Asynchrone Integration via Messaging (AMQP) für nachgelagerte Prozesse wie die finale Buchungsbestätigung oder Benachrichtigungen. Dies entkoppelt die Systeme und erhöht die Resilienz, falls der Zahlungsdienstleister temporär nicht sofort antwortet.',
|
||
points: 6,
|
||
type: 'text',
|
||
},
|
||
{
|
||
id: '3-3-g',
|
||
prompt: 'Warum wird Systemintegration in Projekten häufig unterschätzt? Nennen Sie zwei Faktoren, die sie komplex machen.',
|
||
solution: 'Systemintegration wird oft unterschätzt, weil sie mehr als nur das Verbinden von zwei APIs ist.\n\nKomplexe Faktoren sind:\n1. Heterogene Systemlandschaften: Unterschiedliche Technologien, Plattformen und Datenformate müssen überbrückt werden.\n2. Fehlerbehandlung und Konsistenz: Robuste Strategien für den Umgang mit Ausfällen und die Sicherstellung der Datenkonsistenz über Systemgrenzen hinweg sind schwierig zu implementieren.',
|
||
points: 5,
|
||
type: 'text',
|
||
},
|
||
],
|
||
explanation: '### Lösungserklärung\n\n**AMQP**: Ein standardisiertes Protokoll für asynchrones Messaging, das von Brokern wie RabbitMQ implementiert wird. Es sorgt für Interoperabilität und zuverlässige Nachrichtenübermittlung.\n\n**Komplexität der Integration**: Die Herausforderung liegt oft im Detail: unterschiedliche Datenmodelle, die gemappt werden müssen; komplexe Fehlerbehandlungsstrategien für den Fall, dass ein System nicht erreichbar ist; und die Gewährleistung von Datenkonsistenz über verteilte Systeme hinweg.\n\n### Quellen\n*Folien 3.3, Seite 5-42*'
|
||
}
|
||
];
|