Figure 7.4: ApApplicationError - Example Language Binding

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Artefakt- und Codegenerierungs-Diagramm (Build-/Design-Time Transformation Model).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), spezifiziert in AUTOSAR_AP_SWS_LanguageBindingForModeledAPdatatypes (Kapitel 7: Application Error).
• Technischer Zweck: Visualisierung des Mapping-Mechanismus vom formalen Datenmodell (ARXML) auf konkrete C++-Header-Artefakte für anwendungsspezifische Fehlerdomänen (ApApplicationError / ApplicationErrorDomain). Es demonstriert, wie ein Language-Binding-Generator Schnittstellenbeschreibungen auflöst und die daraus resultierenden Fehlerdomänen-Header dateisystemseitig unterhalb der jeweiligen Service-Interface-Verzeichnisbäume emittiert.

2. Komponenten, Entitäten & Schnittstellen

• Eingangsartefakte (ARXML Model Files):
  • ifA.arxml: Modellbeschreibung des Service-Interfaces A.
  • ifB.arxml: Modellbeschreibung des Service-Interfaces B.
  • Beide Interfaces referenzieren methoden- bzw. ereignisspezifische Anwendungsfehler (ApApplicationError), die denselben drei Fehlerdomänen zugeordnet sind: domM (blau), domN (rot) und domP (grün).
• Transformationsknoten:
  • Generator: AUTOSAR AP Language Binding Generator (Model-to-Code Compiler / Toolchain-Komponente), zuständig für die Synthese des C++14/C++17-Language-Bindings.
• Ausgangsartefakte (C++ Header Files):
  • Scope Interface A:
    • src/.../ifA/.../domM_error_domain.h
    • src/.../ifA/.../domN_error_domain.h
    • src/.../ifA/.../domP_error_domain.h
  • Scope Interface B:
    • src/.../ifB/.../domM_error_domain.h
    • src/.../ifB/.../domN_error_domain.h
    • src/.../ifB/.../domP_error_domain.h
• Strukturelle Beziehungen & Kardinalitäten:
  • M:N-Modellbeziehung: Mehrere Service-Interfaces (A, B) teilen sich dieselben Fehlerdomänen (M, N, P).
  • 1:N-Dateisystemabbildung: Bei entkoppelter bzw. interface-getriebener Codegenerierung erzeugt der Generator für jede im ARXML referenzierte Fehlerdomäne eine dedizierte Header-Datei innerhalb des Pfades des jeweiligen Service-Interfaces.

3. Dynamisches Verhalten & Sequenzablauf

• Phasenablauf (Build-Time / Tool-Pipeline):
  1. Modelleinlesung & Parsing: Der Generator konsumiert die ARXML-Beschreibungen ifA.arxml und ifB.arxml.
  2. Referenzauflösung: Identifikation aller assoziierten ApApplicationError-Definitionen und Zuordnung zu ihren übergeordneten ApplicationErrorDomain-Instanzen (domM, domN, domP).
  3. Artefakt-Synthese (Code Emission):
     • Generierung der Klassen abgeleitet von ara::core::ErrorDomain sowie der typisierten Fehler-Enumerationen (ErrorDomain::CodeType).
     • Platzierung der generierten .h-Dateien in den jeweiligen interface-spezifischen Include-Verzeichnissen (.../ifA/... bzw. .../ifB/...).
  4. Redundanz-Charakteristik: Da dieselben Fehlerdomänen (domM, domN, domP) über verschiedene Interfaces instanziiert werden, erzeugt der Generator redundante Dateistrukturen über getrennte Namespace-/Verzeichnispfade.

4. Normative Relevanz & Entwickler-Hinweise

• C++ Language Binding & ara::core Integration:
  • Jede generierte *_error_domain.h deklariert die spezifische Subklasse von ara::core::ErrorDomain (Singleton-Instanz via GetErrorDomain()) und die zugehörigen Fehlercodes zur Kapselung in ara::core::ErrorCode bzw. ara::core::Result<T, E>.
• Include-Pfade & One Definition Rule (ODR):
  • Entwickler und Toolchain-Integratoren müssen sicherstellen, dass die C++-Klassennamen und Header-Guards der Fehlerdomänen nicht kollidieren, wenn ein Anwendungsprozess sowohl ifA als auch ifB konsumiert (Include-Pfad-Isolation vs. gemeinsame Domain-Namespaces).
  • Werden Domänen identisch in globalen Namespaces definiert, führt die getrennte Generierung ohne zentrale Entkopplung zu ODR-Verletzungen zur Link-Time.
• Build-System & Dependency-Management (CMake / Make):
  • Include-Suchpfade (-I) müssen präzise auf die jeweiligen Interface-Strukturen konfiguriert werden.
  • Inkrementelle Builds müssen Dateiänderungen in geteilten ARXML-Domänen auf alle abgeleiteten Interface-Header synchron propagieren.
• Architekturempfehlung:
  • Um Header-Duplikation zu vermeiden, sollten ApplicationErrorDomains im Modell nach Möglichkeit als eigenständige, interface-unabhängige Pakete modelliert und zentral generiert werden, anstatt sie als Artefakte der individuellen ServiceInterface-Generierung zu replizieren.