Specification of Data and Program Structures

This article is a conceptual explanation of the specification of data and program structures – including exam questions, core components, and tags.

In a Nutshell

Data structures are formally described via models, types, invariants, and schemas. Program structures are specified through interfaces, pre-/postconditions, states, and control flow. The goal is unambiguous, testable, and maintainable software.

Compact Technical Description

Data Specification

• Models: ER model or UML class diagram
• Cardinalities, keys, normalization (up to 3NF)
• Rules as invariants
• Interface data machine-readable: JSON Schema (or DDL/XML Schema)

Program Specification

• Modules/APIs with signatures
• Error contracts
• Design by Contract: precondition, postcondition, invariant
• Behavior: state machines, activity/sequence diagrams
• Specification: OCL (Object Constraint Language)

Specifications serve as the basis for automatic validation, stub generation, and contract tests.

Exam-Relevant Key Points

• Cardinalities/keys correct
• JSON Schema for input validation
• Pre-/postconditions + error cases
• State models for allowed transitions
• Derive test cases (equivalence classes/boundary values)
• Versioning + migration/deprecation
• Security: validation + permissions + audit fields

Core Components

1. Abstract data type + value range
2. Structural model (ER/class)
3. Cardinalities + normal forms
4. Data schema (JSON Schema)
5. API contract + error codes
6. Design by Contract
7. State/process models
8. Quality rules (NFA)
9. Test derivation (contract/property)
10. Versioning/migration concept

Practical Example (Order)

JSON Schema (Excerpt as 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 Invariants (Paraphrased)

context Bestellung inv SummeStimmt:
  gesamt = sum(positionen.preis * positionen.menge)

context Bestellung inv PositiveMengen:
  forAll(positionen, menge > 0)

Service Contract (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

Advantages and Disadvantages

Advantages

• Unambiguous communication
• Automatable validation
• Better testability and fewer integration errors

Disadvantages

• Initial effort
• Maintenance of versions/migrations
• Risk of over-formalization

Typical Exam Questions (with Short Answer)

1. ER model vs. class diagram? ER for data/persistence, class for types + operations.
2. Why invariants? Rules that must always hold.
3. How do tests arise from specification? Preconditions/invariants → equivalence classes/boundary values.
4. How do you version schemas safely? Semver, breaking changes = major, deprecation + migration.

Most Important Sources

1. https://json-schema.org
2. https://www.omg.org/spec/UML