Figure 8.12: Variant 2 - std::function

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm mit kombinierten Fragmenten (loop) und Schachtelung von Lebenslinien in eine Prozess-/Komponentengrenze (Application).
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Release R24-11, Dokument AUTOSAR_AP_EXP_SWArchitecture (Kapitel 8, Service Implementation Patterns).
• Technischer Zweck: Spezifikation des Entwurfsmusters Variant 2 – std::function zur Bereitstellung und Ausführung von Service-Methoden im ARA-Kontext (im Kontrast zu Variant 1 – Skeleton Approach via Vererbung). Dargestellt wird der Lebenszyklus aus Callback-Registrierung, Service-Ankündigung (Offer), Request-Dispatching via Callable/Funktor und kontrolliertem Service-Rückzug (StopOffer).

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Lebenslinien:
  • Application (äußerer Begrenzungsrahmen): Prozess-/Adressraum-Grenze der Adaptive Application.
  • Application (Lebenslinie innerhalb der Grenze): Anwendungslogik / Client-Code des Service-Providers.
  • :Service (Lebenslinie innerhalb der Grenze): Instanz des generierten Service-Schnittstellenobjekts (Provider-Wrapper / Dispatcher).
  • Functional Cluster (Lebenslinie außerhalb der Grenze): Plattform-Infrastrukturkomponente der Adaptive Platform (z. B. Communication Management Daemon / Binding / Runtime Broker).
• Schnittstellen & Methoden:
  • RegisterCallback(function): Synchrones lokales API zur Injektion eines aufrufbaren Objekts (std::function, Lambda oder Funktionszeiger).
  • Offer(): Result: Synchroner Methodenaufruf zur Veröffentlichung des Service-Angebots; liefert ara::core::Result<void>.
  • executeCallback(): T: Interne Dispatch-Methode der Service-Instanz zur Auswertung und Rückgabe des Ergebnistyps T.
  • operator(): Aufruf-Operator der übergebenen std::function-Instanz zur Übergabe des Methodenkontexts an die Applikationslogik.
  • StopOffer(): Lokale API-Methode zur Rücknahme der Service-Sichtbarkeit.
• Stereotypen:
  • «aapInformative»: Markiert Plattform-interne bzw. stack-spezifische Interaktionen (notify about offer(), enableServiceRequests(), request service(), disableServiceRequests(), notify about stopoffer()), die nicht normativ für die Anwendungs-API, sondern implementationsspezifisch für das Binding zum Functional Cluster sind.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Registrierung & Service-Offer

1. Application ruft synchron RegisterCallback(function) auf :Service auf. Die Callback-Referenz wird im Service-Objekt gebunden.
2. Application initiiert Offer(): Result auf :Service.
3. :Service benachrichtigt die Plattform via notify about offer() («aapInformative» an Functional Cluster).
4. :Service führt die interne Aktivierung enableServiceRequests() aus («aapInformative»).
5. :Service antwortet Application mit dem Ausführungsergebnis Result.

Phase 2: Service Request Handling (loop-Fragment)

1. Ein Service-Konsument triggert über die Middleware eine Anfrage; Functional Cluster leitet request service() («aapInformative») synchron an :Service weiter.
2. :Service stößt intern executeCallback(): T an.
3. :Service invozierte das registrierte Callback über operator() synchron auf der Lebenslinie Application.
4. Application verarbeitet die Nutzdaten und kehrt mit dem Ergebnis (Typ T) zurück.
5. :Service sendet die Antwortnachricht/den Return-Pfad an Functional Cluster zurück.

Phase 3: Deregistrierung & Service-Terminierung

1. Application ruft StopOffer() auf :Service auf.
2. :Service deaktiviert über disableServiceRequests() («aapInformative») die Entgegennahme weiterer Requests.
3. :Service sendet notify about stopoffer() («aapInformative») an Functional Cluster zur Entfernung aus der Service-Registry.
4. :Service kehrt zu Application zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung vs. Vererbung: Entwickler müssen für Service-Provider keine abstrakte Skeleton-Basisklasse ableiten (Variant 1), sondern können Methodenimplementierungen per Komposition (std::function, Funktoren, Member-Funktionszeiger via std::bind oder C++-Lambdas) dynamisch binden. Dies erleichtert Unit-Testing und Mocking.
• Lebenszyklus-Vertrag:
  • RegisterCallback() muss zwingend vor Offer() aufgerufen werden. Ein Offer() ohne vorher registrierten Callback führt im Request-Pfad zu undefiniertem Verhalten (z. B. std::bad_function_call) oder einem standardisierten ARA-Fehlercode.
  • Nach StopOffer() eingehende Service-Requests müssen durch den internen Guard disableServiceRequests() verworfen oder mit Fehler abgewiesen werden.
• Thread-Safety & Reentrancy: Der Aufruf von operator() erfolgt im Thread-Kontext des Service-Dispatchers/Bindings (Functional Cluster). Die in Application bereitgestellte Lambda/Funktion muss reentrant und threadsicher sein, sofern das Service-Binding Multithreading für parallele Client-Requests nutzt.
• Speicher- und Copy-Overhead: Im Gegensatz zu virtuellen Methodenaufrufen (Variant 1) kann std::function je nach Größe des Capture-Objekts Heap-Allokationen (Small Buffer Optimization beachten!) und zusätzliche Indirektionskosten verursachen; für harte Echtzeitpfade auf AP-Targets ist der Footprint des Bindings zu profilieren.