Figure 8.11: Variant 1 - Skeleton Approach

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm mit Subsystem-/Prozessgrenze (Application) und Interaktions-Rahmen (loop).
• Architektur-Kontext: AUTOSAR Adaptive Platform (ara::com Communication Management / Platform Architecture, AUTOSAR_AP_EXP_SWArchitecture, Release R24-11).
• Technischer Zweck: Spezifikation des Lebenszyklus und Nachrichtenaustauschs beim Service-Provider nach dem Skeleton-Ansatz (Variant 1). Das Diagramm modelliert das Zusammenspiel zwischen Applikationslogik, generiertem Service-Skeleton (ServiceImpl) und der zugrundeliegenden Plattform-Infrastruktur (Functional Cluster, z. B. Communication Management Daemon / Service Discovery / IPC-Router).

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Lifelines:
  • Application (äußere Prozessgrenze / Packaging-Boundary): Gekapselter Linux/POSIX-Prozessraum der Adaptive Application.
  • Application (Lifeline): Applikative Kontrolllogik (User Code), welche den Lebenszyklus des Service steuert.
  • Service: ServiceImpl (Lifeline): Konkrete Instanz des generierten Skeletons (ara::com::Skeleton), die das typisierte Service-Interface implementiert.
  • Functional Cluster (Lifeline): Plattform-Infrastrukturkomponente außerhalb des Anwendungsprozesses (typischerweise der ara::com-Plattform-Daemon für SOME/IP- bzw. IPC-Binding).
• Stereotypen:
  • «aapInformative»: Kennzeichnet nicht-normative, herstellerspezifische Interaktionen zwischen dem Skeleton-Framework und dem Functional Cluster. Diese Aufrufe sind Implementierungsdetails der Middleware und nicht Teil der normativen C++-Applikationsschnittstelle.

3. Dynamisches Verhalten & Sequenzablauf

1. Service Announcement (Offer):
   • Die Application ruft synchron Offer(): Result auf ServiceImpl auf (entspricht normativ OfferService()).
   • ServiceImpl signalisiert via notify about offer() («aapInformative») dem Functional Cluster die Service-Verfügbarkeit (Trigger für SOME/IP Service Discovery bzw. lokales IPC-Publishing).
   • Nach Bestätigung durch den Cluster aktiviert das Skeleton lokal die Annahme von Anfragen via enableServiceRequests() («aapInformative»).
   • Result signalisiert der Applikation die erfolgreiche Bereitstellung.
2. Service Operation Execution (loop-Block):
   • Wiederkehrend bei eingehenden Client-Aufrufen leitet der Functional Cluster die Anfrage via request service() («aapInformative») an ServiceImpl weiter.
   • ServiceImpl führt intern die anwendungsspezifische Methode ServiceOperation() aus (Dispatching in den applikativen Servant-Code).
   • Das Ausführungsergebnis wird synchron/asynchron über den Return-Pfad von request service() an den Functional Cluster zur Weiterleitung an den Client übergeben.
3. Service Revocation (StopOffer):
   • Die Application stößt den Shutdown via StopOffer() auf ServiceImpl an (entspricht normativ StopOfferService()).
   • ServiceImpl deaktiviert unverzüglich die Annahme neuer Anfragen über disableServiceRequests() («aapInformative»).
   • Das Skeleton sendet notify about stopoffer() («aapInformative») an den Functional Cluster (Trigger für SOME/IP StopOfferService-Nachricht bzw. IPC-Deregistrierung).
   • Der Aufruf kehrt zur Application zurück; der Service ist offline.

4. Normative Relevanz & Entwickler-Hinweise

• API-Schnittstellenvertrag:
  • Normativ: Ausschließlich OfferService(), StopOfferService() und die Implementierung der Schnittstellen-Operationen (ServiceOperation()) innerhalb der von der generierten Skeleton-Basisklasse abgeleiteten Klasse ServiceImpl.
  • Nicht-normativ: Sämtliche «aapInformative»-Pfade. Entwickler dürfen sich nicht auf konkrete IPC-Mechanismen, Middleware-Daemons oder Signalwege zum Functional Cluster stützen; diese variieren je nach Vendor-Stack (z. B. Shared Memory vs. UNIX Domain Sockets).
• Concurrency & Thread-Modell:
  • ServiceOperation() wird im Kontext des Worker-Thread-Pools der ara::com-Middleware ausgeführt. Entwickler müssen ServiceImpl threadsicher und reentrant implementieren (bzw. entsprechende Serialisierungsmechanismen vorsehen).
• State-Invariante:
  • Der interne Status enableServiceRequests() vs. disableServiceRequests() garantiert, dass keine Requests an die Applikation zugestellt werden, bevor Offer() vollständig durchlaufen ist bzw. nachdem StopOffer() initiiert wurde. Dies verhindert Race Conditions beim Anwendungsstart und geordneten Herunterfahren über das Execution Management (ara::exec).