DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_EXP_SWArchitecture FIG-22406760d8cd075d 438 × 444 px 1 Release(s)

Figure 8.8: Example of Plugin Class Structure

SHA-256 Inhalts-Fingerabdruck: 22406760d8cd075d2ed93105885590cbd058697d625906980b365427f1b36467
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

UML-Klassendiagramm zur Darstellung des architektonischen Plugin-Erweiterungsmusters in der AUTOSAR Adaptive Platform (AP). Das Diagramm veranschaulicht die Schichtenarchitektur und Verantwortlichkeitsteilung zwischen standardisierter Plattformbasis („Adaptive Platform“), generierten Zwischenschnittstellen („Generated“) und herstellerspezifischen Implementierungen („Provided by OEM“) zur flexiblen, typisierten Einbindung kundenspezifischer Funktionalitäten in Adaptive Applications oder funktionale Cluster.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm gliedert sich in drei Schichten bzw. Namensräume:

  • Schicht Adaptive Platform: Enthält die abstrakte Basisklasse bzw. das Basis-Interface XYPlugin (kursiv gesetzt) mit den öffentlichen Operationen + GetID(): String zur Identifikation des Plugins und + Operation1(): void als funktionaler Schnittstelle.
  • Schicht Generated: Beinhaltet zwei generierte Schnittstellen «interface» PluginA und «interface» PluginB, welche jeweils die Methode + GetID(): String spezifizieren. Beide Schnittstellen realisieren die Basisklasse XYPlugin über eine Interface-Realisierungsbeziehung (gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze).
  • Schicht Provided by OEM: Beinhaltet die konkreten Klassen PluginA und PluginB, welche die fachliche Methode + Operation1(): void implementieren. Beide Klassen implementieren jeweils über eine Realisierungsbeziehung (gestrichelte Linie mit offener Dreiecksspitze) die korrespondierende Schnittstelle «interface» PluginA bzw. «interface» PluginB aus der Schicht Generated.

3. Dynamisches Verhalten & Sequenzablauf

Als statisches Strukturdiagramm modelliert die Abbildung keinen zeitlichen Ablauf. Das zugrunde liegende Entwurfsmuster impliziert folgendes Laufzeit- und Instanziierungsverhalten: Der Codegenerator erzeugt basierend auf dem Modell bzw. Manifest die typspezifischen Interfaces PluginA und PluginB mit fest vorgegebenen Identifikatoren (GetID()). Zur Laufzeit instanziiert das Adaptive-Platform-Modul die OEM-Implementierungsklassen polymorph über den gemeinsamen Vertrag von XYPlugin. Der Aufrufer innerhalb der Plattform traversiert die Schnittstelle und ruft GetID() zur Identifikation bzw. Operation1() zur Ausführung herstellerspezifischer Logik auf.

4. Normative Relevanz & Entwickler-Hinweise

Das Diagramm besitzt erläuternden Charakter innerhalb der AUTOSAR Adaptive Platform Architekturleitfäden (AUTOSAR_AP_EXP_SWArchitecture). Das Design entkoppelt Plattform- und OEM-Anteile: Plattformcode greift ausschließlich auf die abstrakte Schnittstelle XYPlugin zu. Der OEM muss lediglich die fachliche Methode Operation1(): void implementieren, während die Identifikatoren über generierte Schnittstellen vorkonfiguriert werden, was manuelles Hardcodieren von Plugin-IDs vermeidet und Konsistenz sicherstellt.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Provided by OEM | Generated | Adaptive Platform | XYPlugin | + GetID(): String + Operation1(): void | «interface» | PluginA | + GetID(): String | «interface» | PluginB | + GetID(): String | PluginA | + Operation1(): void | PluginB | + Operation1(): void

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_EXP_SWArchitecture S. 38 8.8 Figure 8.8: Example of Plugin Class Structure