Figure 8.5: Example of Plugin Class Structure

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Klassendiagramm (Strukturdiagramm).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Dokument AUTOSAR_AP_EXP_SWArchitecture (Kapitel 8, Plugin Concept).
• Funktionale Einordnung: Entkopplung standardisierter Plattform-Funktionalität (Functional Clusters wie DM, UCM, IAM oder SM) von herstellerspezifischer Logik (OEM-Erweiterungen). Das Schaubild visualisiert das Strategy/Plugin-Entwurfsmuster zur Laufzeit- oder Linkzeit-Erweiterbarkeit des AP-Stacks, ohne den Plattform-Kerncode zu modifizieren.

2. Komponenten, Entitäten & Schnittstellen

• Domänen / Pakete (Boundaries):
  • Adaptive Platform: Standardisierte Plattformschicht, welche die Schnittstellendefinition und abstrakten Basistypen bereitstellt.
  • Provided by OEM: Herstellerspezifische Domäne für konkrete Implementierungen und Algorithmen.
• Klassen & Signaturen:
  • XYPlugin (Abstrakte Basisklasse / Interface in der Adaptive Platform):
    • + GetID(): String: Eindeutige Kennung/Identifikator der Plugin-Instanz bzw. des Plugin-Typs.
    • + Operation1(): void: Parametrisierte oder zustandsverändernde funktionale Operation.
    • + Operation2(): int: Berechnungs- oder Statusabfrage-Operation mit ganzzahligem Rückgabewert.
  • a::b::PluginA (Konkrete Spezialisierung im C++-Namespace a::b, OEM-Domäne):
    • Realisiert / überschreibt identische Schnittstellenmethoden (GetID, Operation1, Operation2).
  • c::d::PluginB (Konkrete Spezialisierung im C++-Namespace c::d, OEM-Domäne):
    • Realisiert / überschreibt identische Schnittstellenmethoden (GetID, Operation1, Operation2).
• Beziehungen:
  • Generalisierung / Vererbung: a::b::PluginA → XYPlugin und c::d::PluginB → XYPlugin (UML-Generalisierungspfeile mit geschlossener, nicht ausgefüllter Spitze; entspricht C++: public XYPlugin).
  • Kardinalität: 1:n – Ein definierter Plattform-Plugin-Typ kann durch beliebig viele OEM-spezifische Implementierungen spezialisiert werden.

3. Dynamisches Verhalten & Sequenzablauf

• Laufzeit-Bindung & Discovery:
  • Der Functional Cluster lädt das OEM-Plugin zur Initialisierungsphase entweder statisch gebunden oder dynamisch als Shared Object (.so via dynamischem Linker / Factory-Funktion wie CreatePlugin()).
• Identifikation:
  • Plattform ruft synchron GetID() auf, um das Plugin zu verifizieren und im internen Plugin-Registry gegen das Manifest abzugleichen.
• Synchroner Aufrufpfad:
  • Der Plattform-Prozess hält Zeiger/Referenzen auf die Basisklasse (std::unique_ptr<XYPlugin> bzw. Referenz) und delegiert Aufrufe polymorph an Operation1() und Operation2().
• Thread-Kontext & Fehlerpfade:
  • Die Methoden laufen synchron im Thread-Kontext des aufrufenden Functional Clusters ab.
  • Fehlerbehandlung erfolgt nach AP-Vorgaben über standardisierte Fehlertypen (z. B. ara::core::Result bzw. ara::core::ErrorCode), um Plattform-Abstürze durch unhandled Exceptions zu verhindern.

4. Normative Relevanz & Entwickler-Hinweise

• ABI- & C++-Konformität:
  • XYPlugin fungiert als reines C++-Interface (struct / class mit rein virtuellen Methoden = 0 und virtuellem Destruktor virtual ~XYPlugin() = default;).
  • Bei Auslieferung als dynamische Bibliothek (.so) müssen OEM und Plattform-Lieferant denselben Compiler-/Toolchain-Stand und dieselbe ABI nutzen (vtable-Layout, String-Implementierung ara::core::String).
• Namespace-Kapselung:
  • OEM-Plugins müssen in eindeutigen C++-Namespaces gekapselt sein (im Diagramm: a::b und c::d), um Symbolkollisionen beim dynamischen Laden in denselben Adressraum zu vermeiden.
• Manifest-Konfiguration & Deployment:
  • Die Zuordnung der Plugin-ID (GetID()) und des Bibliotheksnamens/Pfads muss im Execution Manifest bzw. dem jeweiligen Cluster-Konfigurationsmanifest des Ziel-Prozesses deklariert werden.