Figure 6.3: Enumeration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Metamodell-Typdefinition (Stereotyp «enumeration»).
• Architektur-Kontext & Zweck: Spezifikationsdokument AUTOSAR_AP_EXP_ARARustApplications (AUTOSAR Adaptive Platform, R23-11/R24-11), Kapitel 6 (Data Types). Das Diagramm definiert das UML-Modellierungsmuster zur Abbildung algebraischer Datentypen (Sum Types / Tagged Unions) für das offizielle AUTOSAR Rust Language Binding (ara). Im Gegensatz zu klassischen C/C++-Enums (enum class über skalaren Ganzzahldatentypen) erlaubt Rust Varianten mit typisierter Daten-Nutzlast (Payload), die für serviceorientierte Schnittstellen (ara::com Events, Fields, Methods) typ- und speichersicher modelliert werden.

2. Komponenten, Entitäten & Schnittstellen

• Entität:
  • Enumeration1: Typdefinition mit Stereotyp «enumeration».
• Kompartimente und Varianten-Semantik:
  • Literalkompartiment (Mitte):
    • Variant1: Unit-Variante (feldlos). Repräsentiert einen reinen Zustand bzw. eine klassische Diskriminante ohne assoziierte Nutzdaten.
  • Attribut-/Payload-Kompartiment (Unten):
    • + Variant2(String): Tupel-Variante mit Sichtbarkeit public (+), die eine Nutzlast vom Typ String (im AUTOSAR-Kontext ara::core::String bzw. sprachspezifisch alloc::string::String) kapselt.
    • + Variant3(u8, u8): Tupel-Variante mit Sichtbarkeit public (+), die eine 2-Tupel-Nutzlast aus zwei vorzeichenlosen 8-Bit-Ganzzahlen (u8, u8) kapselt.
• Beziehungen & Vererbung:
  • Keine Vererbungs- oder Assoziationshierarchien. Das Muster modelliert geschlossene Typpolymorphie innerhalb einer eigenständigen Datenstruktur.

3. Dynamisches Verhalten & Sequenzablauf

• Klassifikation: Nicht zutreffend (rein statische Datenstruktur- und Typdefinition).
• Laufzeit- & Speicheraspekte:
  • Memory-Layout: Die Speicherbelegung zur Laufzeit richtet sich nach $\text{size}(\text{Discriminant}) + \max(\text{size}(\text{Payload})) + \text{Padding}$.
  • Dispatching & Pattern Matching: Auswertung auf Konsumenten-/Produzentenseite erfolgt zwingend über erschöpfendes Pattern Matching (match) der Diskriminante.
  • Middleware-Serialisierung: Bei Übertragung via ara::com (z. B. SOME/IP- oder IPC-Binding) erfolgt das Mapping auf eine SOME/IP Union (Typ-Selektor-Feld gefolgt von der serialisierten Payload der aktiven Variante).

4. Normative Relevanz & Entwickler-Hinweise

• Generiertes Rust-API (Generator-Target): Der AUTOSAR-Generator übersetzt dieses Modell direkt in eine idiomatische Rust-Enum-Definition:

  pub enum Enumeration1 {
      Variant1,
      Variant2(String),
      Variant3(u8, u8),
  }

• Auswirkungen auf Applikations-Entwickler:
  • Compile-Time Safety: Durch das statische Typsystem von Rust wird unvollständiges Branching via Compiler-Fehler bei nicht abgedeckten Varianten verhindert (Exhaustiveness Checking).
  • Heap- vs. Stack-Allokation: Während Variant1 und Variant3 vollständig auf dem Stack alloziert und trivial kopierbar (Copy/Clone) sind, bedingt Variant2(String) dynamisches Speichermanagement. Im sicherheitskritischen Echtzeitkontext (ASIL) sind deterministische Allokatoren bzw. Kapazitätsbeschränkungen für String-Typen einzuhalten.
• Protokoll- & Serialisierungs-Einschränkungen:
  • Auf Netzwerkebene muss die Serialisierungsschicht den Varianten-Tag konsistent zum AUTOSAR Data Transformation Layer auflösen.
  • Rückwärtskompatibilität bei Schnittstellenerweiterungen: Das Hinzufügen neuer Varianten erfordert applikationsseitig die Berücksichtigung von Non-Exhaustive-Mustern oder Versionssprüngen im Service-Interface-Deployment.