Figure 6.6: Simplified representation of trait and implementation

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Strukturdiagramm / Klassendiagramm mit Rust-spezifischem Stereotypen-Profil.
• Architektur-Kontext: AUTOSAR Adaptive Platform (Explanation of Adaptive Platform Rust Applications, AUTOSAR_AP_EXP_ARARustApplications, Kapitel 6 Modeling Rust applications).
• Technischer Zweck: Definition der formalen Modellierungskonvention zur Repräsentation von Rust-Sprachkonstrukten (Traits, Structs und Implementierungsblöcken) im UML-Metamodell. Schließt die Lücke zwischen klassischer objektorientierter UML-Modellierung (Klassen/Vererbung) und dem kompositions- bzw. traitbasierten Paradigma von Rust für ara-Services und Adaptive Applications.

2. Komponenten, Entitäten & Schnittstellen

• module2::Trait1:
  • Stereotyp: «Trait»
  • Typ/Rolle: Schnittstellendefinition (Verhaltenskontrakt) im Modulpfad bzw. Namensraum module2.
  • Operation: + func1 (öffentliche Funktions-/Methodensignatur des Traits).
• module1::MyStruct2:
  • Stereotyp: «Struct»
  • Typ/Rolle: Konkreter Datentyp (Struktur) im Modulpfad bzw. Namensraum module1.
• Beziehung («impl»):
  • Notation: Gestrichelte gerichtete Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze (UML Interface Realization) von MyStruct2 nach Trait1.
  • Stereotyp: «impl»
  • Semantik: Realisierung des Traits durch die Struktur gemäß Rust-Syntax:

    impl module2::Trait1 for module1::MyStruct2 {
        fn func1(&self) { /* ... */ }
    }

  • Modularität & Orphan Rules: Explizite Trennung in unterschiedliche Module (module1 vs. module2). Modelliert die Rust-Kohärenzregel, wonach ein Trait aus einem fremden Modul/Crate für einen lokalen Typen implementiert werden darf.

3. Dynamisches Verhalten & Sequenzablauf

• Diagrammcharakter: Statisches Strukturmodell; kein dynamischer Laufzeit- oder Sequenzablauf dargestellt.
• Aufrufsemantik:
  • Dispatch: Abhängig von der Instanziierung erfolgt der Aufruf von func1 statisch zur Compile-Zeit via Monomorphisierung (Generics / Trait Bounds) oder dynamisch zur Laufzeit via Trait Objects (&dyn Trait1 / Fat Pointer mit Vtable).
  • Synchronität: Direkter, synchroner Methodenaufruf ohne asynchrone Futures oder Dispatcher-Queues auf Modellebene.

4. Normative Relevanz & Entwickler-Hinweise

• Dokumentenstatus: AUTOSAR_AP_EXP_* ist ein erläuterndes Dokument (Explanatory), definiert jedoch die bindenden Konventionen für die Dokumentation und Modellierung von Rust-APIs innerhalb der Adaptive Platform.
• Entwickler-Richtlinien (Stack- & Applikations-Entwicklung):
  • Modellierungskonvention: Reine Rust-Konzepte dürfen in AUTOSAR-Designs nicht als C++-Klassen («Class») mit Vererbung modelliert werden, sondern müssen strikt über getrennte «Struct»- und «Trait»-Elemente mit einer «impl»-Realisierungsassoziation abgebildet werden.
  • Schnittstellendesign: Traits bilden die primäre Abstraktion für ara-Service-Schnittstellen (Skeleton/Proxy-Muster), Middleware-Adapter und Dependency Injection in Rust-basierten Adaptive Applications.
  • Sichtbarkeit & Modularität: Bei der Code-Generierung aus UML/ARXML-Modellen müssen Modulpfade (::) korrekt in Rust-Modulhierarchien (mod, use, pub) übersetzt werden; Member-Funktionen ohne +-Präfix verbleiben modulintern (pub(crate) bzw. privat).