Figure 8.2: Class Structure of a Plugin

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm / Architektur-Strukturdiagramm mit Paket-/Komponenten-Grenzziehung.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_AP_EXP_SWArchitecture (Kapitel 8, Platform Extensions).
• Technischer Zweck: Definition des Plugin-Musters zur modularen Funktionserweiterung der Adaptive Platform Core-Funktionalität. Es entkoppelt den Plattform-Kern (Adaptive Platform) von hersteller- oder anwendungsspezifischen Implementierungen (Platform Extension 1, Platform Extension 2) über ein einheitliches, polymorphes Schnittstellenmodell.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Kapselungsgrenzen

• Adaptive Platform (Namespace / Subsystem Scope):
  • Kapselt die Basisplattform und definiert den Schnittstellenvertrag.
  • Plugin Interface (Abstrakte Basisklasse / Interface):
    • + GetID(): Konkrete/vordefinierte Methode zur Abfrage des eindeutigen Identifikators des Plugins.
    • + Matches(String): boolean (kursiv / abstrakt): Prädikatfunktion zur Evaluierung, ob das Plugin für einen gegebenen Selektor/Konfigurations-String zuständig ist.
    • + Operation1(): int (kursiv / abstrakt): Domänenspezifische funktionale Operation mit Rückgabewert.
    • + Operation2(): void (kursiv / abstrakt): Domänenspezifische funktionale Prozedur/Aktion ohne Rückgabewert.
• Platform Extension 1 & Platform Extension 2 (Extension Packages):
  • Unabhängige Bereitstellungseinheiten (z. B. Shared Libraries / dynamisch ladbare Binaries).
  • Plugin1 / Plugin2 (Konkrete Implementierungsklassen):
    • Überschreiben und implementieren jeweils die abstrakten Operationen:
      • + Matches(String): boolean
      • + Operation1(): int
      • + Operation2(): void

Beziehungen & Vererbung

• Interface-Realisierung (Plugin1 / Plugin2 ⇢ Plugin Interface):
  • Gestrichelte Linie mit offener Dreiecksspitze (UML-Realisierung/Implementierung).
  • Polymorphe Substitution: Der Plattform-Kern interagiert ausschließlich gegen Plugin Interface, ohne Kenntnis der konkreten Klassen Plugin1 bzw. Plugin2 zur Compile-Zeit.

3. Dynamisches Verhalten & Sequenzablauf

Obwohl statisch modelliert, impliziert die Schnittstellensignatur folgenden Laufzeitablauf im AP-Lifecycle:

1. Plugin-Discovery & Registration: Die Plattform lädt Extensions (typischerweise als dynamische Bibliotheken über Shared-Object-Mechanismen oder statische Registrierungsfabriken).
2. Identifikation: Aufruf von GetID() zur internen Verwaltung und Registrierung im Extension-Manager der Plattform.
3. Dispatch & Selektion: Bei Auftreten einer Anfrage/Verarbeitungsaufgabe iteriert die Plattform über registrierte Instanzen und ruft Matches(identifierString) auf.
4. Synchrone Ausführung: Nach erfolgreichem Match (true) erfolgt der synchrone Methodenaufruf der Fachlogik über Operation1() bzw. Operation2().

4. Normative Relevanz & Entwickler-Hinweise

• C++ API-Vertrag:
  • Implementierung als C++14/C++17-Klassenhierarchie mit virtuellem Destruktor (virtual ~PluginInterface() = default;) und rein virtuellen Methoden (= 0) für Matches, Operation1 und Operation2.
  • ABI-Stabilität beachten: Da Platform Extensions oft separat kompiliert/ausgeliefert werden, muss die ABI der virtuellen Methodentabelle (vtable) zwischen Platform-Core und Extension exakt übereinstimmen (gleiche Toolchain, STL-Version und Compiler-Flags).
• Speicher- & Prozessmodell:
  • Erweiterungen laufen in der Regel im Adressraum des aufrufenden Adaptive Core Prozesses oder werden über das Manifest (Execution Manifest / Platform Health Management) deklarativ verwaltet.
  • Realzeit- und Thread-Safety: Aufrufe von Matches(), Operation1() und Operation2() müssen reentrant bzw. threadsicher ausgelegt sein, falls die Plattform Multithreading-Dispatches initiiert.
• Fehlerbehandlung:
  • Da AUTOSAR AP primär auf ara::core::Result<T> bzw. ara::core::ErrorCode setzt, sollten konkrete Implementierungen von Operation1() und Operation2() deterministisches Fehler-Handling ohne ungefangene C++-Exceptions gewährleisten (AUTOSAR C++14 Coding Guidelines A15-0-0 ff.).