Figure 9.78: Users of the Registry interfaces

1. Diagrammtyp & Architektur-Kontext

UML-Komponentendiagramm zur Darstellung der statischen Abhängigkeiten und Schnittstellennutzer innerhalb der AUTOSAR Adaptive Platform-Architektur. Das Diagramm modelliert die funktionale Komponente Registry und die von ihr bereitgestellte interne Schnittstelle sowie die funktionalen Cluster der Plattform, die als Klienten auf diese Schnittstelle zugreifen.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert eine zentrale Schnittstellenkomponente sowie elf nutzende und bereitstellende Cluster:

• Bereitgestellte Schnittstelle:
  • Manifest Accessor: Stereotypisiert als «aapInternal,aapNativeInterface», fungiert als nativer Zugriffspunkt auf Manifestinformationen.
  • Bereitgestellt durch die funktionale Komponente Registry (Stereotyp «aapFunctionalCluster») über eine Realisierungsbeziehung (gestrichelte Linie mit geschlossener, nicht ausgefüllter Dreiecksspitze).
• Nutzende Funktionale Cluster (Stereotyp «aapFunctionalCluster» bzw. abgekürzt «aapFunctionalClust...»), jeweils über eine gerichtete Abhängigkeit «use» (gestrichelter Pfeil mit offener Pfeilspitze) an Manifest Accessor angebunden:
  • Obere Reihe / daemon-basiert bzw. Library-basiert:
    • Communication Management
    • Network Management
    • Time Synchronization (daemon-based)
    • Update and Configuration Management (daemon-based)
    • Cryptography (daemon-based)
    • Diagnostic Management (daemon-based)
    • Execution Management (daemon-based)
    • Platform Health Management (daemon-based)
  • Untere Reihe:
    • Persistency
    • Identity and Access Management
    • Log and Trace

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm zeigt eine rein statische Nutzungs- und Realisierungsstruktur ohne Sequenzabläufe, Nachrichtenflüsse oder Zustandsübergänge. Die funktionale Komponente Registry realisiert die interne Schnittstelle Manifest Accessor. Zur Laufzeit greifen die zehn abhängigen funktionalen Cluster synchron über native Aufrufe («aapNativeInterface») auf die Funktionen von Manifest Accessor zu, um Manifest- und Konfigurationsdaten abzufragen.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest Accessor ist als plattforminterne Schnittstelle («aapInternal») deklariert; sie ist nicht für Standard-Anwendungsapplikationen bestimmt, sondern dient ausschließlich der plattforminternen Cluster-Interaktion.
• Die Interaktion erfolgt als native Programmierschnittstelle («aapNativeInterface»), typischerweise über C++-APIs innerhalb desselben Prozesskontexts oder IPC-Bindings.
• Sowohl Bibliothekscluster als auch daemon-basierte Cluster (daemon-based) hängen direkt von Manifest Accessor ab, was die Schnittstelle zu einer zentralen Basisabhängigkeit für das Bootstrapping und die Konfiguration der funktionalen Cluster macht.