Analyse und Designverfahren anwenden
Dieser Beitrag ist eine Begriffserklärung zu Analyse- und Designverfahren – inklusive Prüfungsfragen, Kernkomponenten und Tags.
In a Nutshell
Analyse strukturiert das Problem fachlich und grenzt den Scope. Design überführt die Ergebnisse in eine technische Lösung mit klaren Verantwortlichkeiten, Schnittstellen und Qualitätszielen.
Kompakte Fachbeschreibung
Analyse
Ziel: Eindeutigkeit, Testbarkeit, Systemabgrenzung.
Typische Artefakte:
- Use-Case-Beschreibungen
- UML-Diagramme
- Glossar
- Akzeptanzkriterien
Design
Ziel: tragfähige Struktur und Abläufe.
- Strukturmodelle: Klassendiagramm
- Verhaltensmodelle: Sequenz-/Aktivitäts-/Zustandsdiagramme
- Präzisierung: Vor-/Nachbedingungen, ggf. OCL
Prinzipien und Heuristiken:
- GRASP (z.B. Controller, Creator, Low Coupling, High Cohesion)
- SOLID (SRP, OCP, LSP, ISP, DIP)
Qualitätsattribute (Security, Performance, Zuverlässigkeit) werden als nicht-funktionale Anforderungen erfasst und durch Architekturtaktiken adressiert.
Prüfungsrelevante Stichpunkte
- Analyse = „Was?“, Design = „Wie?“
- Akzeptanzkriterien messbar formulieren
- Struktur/Verhalten getrennt modellieren
- GRASP: Verantwortlichkeiten sinnvoll zuweisen
- SOLID nachweisen (IHK-relevant)
- Qualitätsanforderungen als Szenarien
- Traceability: Anforderung → Modell → Test
- Versionierung + Abnahmen
Kernkomponenten
- Anforderungsaufnahme
- Strukturmodell (Klassendiagramm)
- Verhaltensmodell (Sequenz/Aktivität)
- Zustandsmodell (Lifecycle)
- Präzisierung (Vor-/Nachbedingungen/OCL)
- Entwurfsprinzipien (SOLID)
- Verantwortlichkeiten (GRASP)
- Muster (Patterns/Architekturmuster)
- QS (Reviews, Prototypen, TDD)
- Traceability
Praxisbeispiel (Online-Shop: Bestellung)
Analyse:
- Akteur: Kunde
- Use Case: "Bestellung aufgeben"
- Akzeptanzkriterium: Zahlung autorisiert -> Bestellung angelegt
Design (Ausschnitt):
- Klassen: Bestellung, Warenkorb, Zahlung
- Service: BestellungService
- Adapter: ZahlungsdienstAdapter
- Repository: BestellungRepository
Ablauf:
- Summe berechnen
- Zahlung autorisieren
- Bestellung speichern
- Bestätigung senden
Vorteile und Nachteile
Vorteile
- Bessere Kommunikation
- Höhere Testbarkeit
- Weniger Änderungsrisiken
Nachteile
- Initialaufwand
- Risiko der Übermodellierung
- Disziplin bei Pflege/Versionierung nötig
Typische Prüfungsfragen (mit Kurzantwort)
- Analyse vs. Design? Analyse beschreibt das Was, Design konkretisiert das Wie.
- Wozu GRASP? Verantwortlichkeiten sinnvoll zuweisen.
- Wozu SOLID? Wartbarkeit/Testbarkeit verbessern.
- Wie stellt man Konsistenz zwischen Use Case und Modellen sicher? Nachrichten im Sequenzdiagramm entsprechen Operationen im Klassendiagramm.
Lernstrategie
- Use Case + Akzeptanzkriterien schreiben.
- Sequenzdiagramm für Hauptszenario.
- Verantwortlichkeiten (GRASP) zuweisen.
- SOLID-Check + Unit Tests.