Figure 8.5: Example of Plugin Class Structure
962a5b1aa7b696547fd50c51cacfd8efaa0ab530f2f7895f778c935f811ca1e4
1. Diagrammtyp & Architektur-Kontext
UML-Klassendiagramm zur Darstellung der Plugin-Klassenstruktur in der AUTOSAR Adaptive Platform (AP). Das Diagramm illustriert eine direkte, zweistufige Vererbungsarchitektur zwischen der standardisierten Plattformschicht („Adaptive Platform“) und den herstellerspezifischen Implementierungen („Provided by OEM“) ohne Zwischenschaltung generierter Schnittstellen.
2. Komponenten, Entitäten & Schnittstellen
Das Diagramm gliedert sich in zwei architektonische Ebenen:
- Schicht
Adaptive Platform: Enthält die abstrakte C++-BasisklasseXYPlugin(kursiv dargestellt) mit drei öffentlichen virtuellen Methoden:+ GetID(): String,+ Operation1(): voidund+ Operation2(): int. - Schicht
Provided by OEM: Enthält zwei konkrete C++-Klassen in expliziten Namespaces:a::b::PluginAundc::d::PluginB. Beide Klassen deklarieren und implementieren vollständig alle Methoden der Basisklasse:+ GetID(): String,+ Operation1(): voidsowie+ Operation2(): int. - Beziehungen: Beide OEM-Klassen stehen über eine direkte Generalisierungs-/Vererbungsbeziehung (durchgezogene Linie mit offener/nicht ausgefüllter Dreiecksspitze) in direkter Ableitung von
XYPlugin. Eine Schicht „Generated“ ist nicht vorhanden.
3. Dynamisches Verhalten & Sequenzablauf
Als statisches Klassendiagramm wird kein dynamischer Interaktionsablauf spezifiziert. Die Vererbungshierarchie implementiert klassische C++-Objektpolymorphie: Die Adaptive Platform verwaltet Instanzen von a::b::PluginA bzw. c::d::PluginB über Zeiger oder Referenzen auf den Basistyp XYPlugin. Zur Laufzeit werden Methodenaufrufe für GetID(), Operation1() und Operation2() (mit Integer-Rückgabewert) über die virtuelle Funktionstabelle (vtable) direkt an die jeweilige OEM-Implementierung weitergeleitet.
4. Normative Relevanz & Entwickler-Hinweise
Das Diagramm dient als architektonische Referenz für Plugin-Klassenstrukturen in AUTOSAR AP. Da keine Zwischengenerierung von Interfaces stattfindet, liegt die vollständige Implementierung inklusive der Plugin-ID-Rückgabe (GetID()) sowie beider Operationen (Operation1, Operation2) in der Verantwortung des OEMs. Entwickler müssen die vorgegebenen Namensräume (a::b bzw. c::d) einhalten und sicherstellen, dass die zurückgegebenen IDs systemweit eindeutig sind.