Spezifikation von Daten- und Programmstrukturen
Dieser Beitrag ist eine Begriffserklärung zur Spezifikation von Daten- und Programmstrukturen – inklusive Prüfungsfragen, Kernkomponenten und Tags.
In a Nutshell
Datenstrukturen werden formal über Modelle, Typen, Invarianten und Schemata beschrieben. Programmstrukturen werden über Schnittstellen, Vor-/Nachbedingungen, Zustände und Kontrollfluss präzisiert. Ziel ist eindeutige, testbare und wartbare Software.
Kompakte Fachbeschreibung
Datenspezifikation
- Modelle: ER-Modell oder UML-Klassendiagramm
- Kardinalitäten, Schlüssel, Normalisierung (bis 3NF)
- Regeln als Invarianten
- Schnittstellendaten maschinenlesbar: JSON Schema (oder DDL/XML Schema)
Programmspezifikation
- Module/APIs mit Signaturen
- Fehlerverträge
- Design by Contract: Vorbedingung, Nachbedingung, Invariante
- Verhalten: Zustandsautomaten, Aktivitäts-/Sequenzdiagramme
- Präzisierung: OCL (Object Constraint Language)
Spezifikationen dienen als Basis für automatische Validierung, Stub-Generierung und Contract Tests.
Prüfungsrelevante Stichpunkte
- Kardinalitäten/Schlüssel korrekt
- JSON Schema zur Eingabevalidierung
- Vor-/Nachbedingungen + Fehlerfälle
- Zustandsmodelle für erlaubte Übergänge
- Testfälle ableiten (Äquivalenzklassen/Grenzwerte)
- Versionierung + Migration/Deprecation
- Security: Validierung + Rechte + Auditfelder
Kernkomponenten
- Abstrakter Datentyp + Wertebereich
- Strukturmodell (ER/Klasse)
- Kardinalitäten + Normalformen
- Datenschema (JSON Schema)
- API-Vertrag + Fehlercodes
- Design by Contract
- Zustands-/Prozessmodelle
- Qualitätsregeln (NFA)
- Testableitung (Contract/Property)
- Versions-/Migrationskonzept
Praxisbeispiel (Bestellung)
JSON Schema (Auszug als Text)
type: object
required: id, kundeId, positionen, gesamt
properties:
id: string (pattern ^ORD-[0-9]{6}$)
gesamt: number (minimum 0)
positionen: array (minItems 1)OCL-Invarianten (sinngemäß)
context Bestellung inv SummeStimmt:
gesamt = sum(positionen.preis * positionen.menge)
context Bestellung inv PositiveMengen:
forAll(positionen, menge > 0)Service-Vertrag (Pseudocode)
interface BestellService
legeBestellungAn(warenkorb)
vorbedingung:
warenkorb.positionen nicht leer und warenkorb.gesamt > 0
nachbedingung:
result.status = ANGELEGT und result.gesamt = warenkorb.gesamt
fehlerfälle:
UngültigeDaten, ZahlungAbgelehnt
Vorteile und Nachteile
Vorteile
- Eindeutige Kommunikation
- Automatisierbare Validierung
- Bessere Testbarkeit und weniger Integrationsfehler
Nachteile
- Initialaufwand
- Pflege von Versionen/Migrationen
- Risiko der Überformalisierung
Typische Prüfungsfragen (mit Kurzantwort)
- ER-Modell vs Klassendiagramm? ER für Daten/Persistenz, Klasse für Typen + Operationen.
- Wozu Invarianten? Regeln, die immer gelten müssen.
- Wie entstehen Tests aus Spezifikation? Vorbedingungen/Invarianten → Äquivalenzklassen/Grenzwerte.
- Wie versioniert man Schemata sicher? Semver, Breaking Changes = Major, Deprecation + Migration.