Figure 9.38: Mapping of CryptoProviders and CryptoKeySlots to RPortPrototypes

1. Diagrammtyp & Architektur-Kontext

UML-Klassendiagramm aus der AUTOSAR Adaptive Platform Spezifikation (AUTOSAR_TPS_ManifestSpecification). Das Diagramm stellt das Metamodell für das Deployment und Mapping von Kryptographie-Ressourcen dar. Es gliedert sich in zwei Hauptpakete: das obere Paket Application Design, welches die abstrakte Schnittstellen- und Port-Architektur auf Software-Design-Ebene abbildet, und das untere Paket Deployment, welches die konkrete Zuordnung von kryptographischen Schlüsselplätzen (CryptoKeySlots) und Anbietern (CryptoProviders) zu Ausführungsprozessen und Port-Prototypen auf Zielsystemebene definiert.

2. Komponenten, Entitäten & Schnittstellen

Das Paket Application Design umfasst folgende Entitäten:

• PortInterface (Spezialisierung von ARElement, AtpBlueprint, AtpBlueprintable, AtpType).
• CryptoInterface: Abstrakte Generalisierung für Krypto-Schnittstellen, erbt von PortInterface.
• CryptoKeySlotInterface: Erbt von CryptoInterface und deklariert die Attribute allocateShadowCopy: Boolean [0..1], cryptoAlgId: String [0..1], cryptoObjectType: CryptoObjectTypeEnum [0..1], slotCapacity: PositiveInteger [0..1] sowie slotType: CryptoKeySlotTypeEnum [0..1].
• CryptoProviderInterface: Erbt von CryptoInterface.
• RPortPrototype (Spezialisierung von AbstractRequiredPortPrototype): Referenziert über die Assoziation requiredInterface mit Stereotyp «isOfType» und Redefinition {redefines atpType} eine PortInterface-Instanz (Kardinalität 0..1).

Das Paket Deployment umfasst:

• CryptoKeySlot (spezialisiert Identifiable): Besitzt identische Attribute wie CryptoKeySlotInterface (allocateShadowCopy, cryptoAlgId, cryptoObjectType, slotCapacity, slotType).
• CryptoProvider (spezialisiert Identifiable): Aggregiert per Komposition («atpSplitable») Schlüsselplätze über die Rolle keySlot mit Kardinalität 0..*.
• CryptoKeySlotToPortPrototypeMapping (spezialisiert UploadablePackageElement): Bildet eine Zuordnung zwischen Schlüsselplatz, Port und Prozess ab. Es referenziert über die Rolle keySlot genau einen CryptoKeySlot (1), über process genau einen Process (1) und über portPrototype mit Stereotyp «instanceRef» genau einen RPortPrototype (1).
• CryptoProviderToPortPrototypeMapping (spezialisiert UploadablePackageElement): Verbindet Krypto-Provider, Port und Prozess. Es referenziert über cryptoProvider genau einen CryptoProvider (1), über process genau einen Process (1) und über portPrototype («instanceRef») genau einen RPortPrototype (1).
• Process (spezialisiert AbstractExecutionContext): Verfügt über die Attribute functionClusterAffiliation: String [0..1], numberOfRestartAttempts: PositiveInteger [0..1] und preMapping: Boolean [0..1].
• Documentation (spezialisiert ARElement): Ist über die Assoziation cryptoProviderDocumentation (Kardinalität 0..1) an CryptoProvider angebunden.

3. Dynamisches Verhalten & Sequenzablauf

Statisches Metamodell ohne dynamische Verhaltens- oder Sequenzdiagrammelemente. Es beschreibt deklarative Modellierungsbeziehungen zur Konfigurations- und Generierungszeit für das AUTOSAR-Manifest. Aus den definierten Assoziationen ergibt sich, dass eine Applikation zur Laufzeit über einen RPortPrototype auf kryptographische Dienste zugreift, wobei das Deployment-Mapping zur Konfigurationszeit festlegt, welcher konkrete CryptoKeySlot bzw. CryptoProvider im Kontext des jeweiligen Betriebssystem-Prozesses (Process) instanziiert und dem Port zugeordnet wird.

4. Normative Relevanz & Entwickler-Hinweise

Normativ verbindliche Spezifikation der Manifest-Klassen zur Konfiguration des Krypto-Subsystems der AUTOSAR Adaptive Platform. Für Manifest-Modelleure und Code-Generatoren ist bindend:

• Jedes CryptoKeySlotToPortPrototypeMapping muss obligatorisch genau einen RPortPrototype, genau einen CryptoKeySlot und genau einen Process verknüpfen (Kardinalitäten jeweils strikt 1).
• Jedes CryptoProviderToPortPrototypeMapping muss obligatorisch genau einen RPortPrototype, genau einen CryptoProvider und genau einen Process verknüpfen (Kardinalitäten jeweils strikt 1).
• Ein CryptoProvider kann 0 bis beliebig viele CryptoKeySlot-Instanzen besitzen (0..*), die splitbar («atpSplitable») modelliert werden dürfen.
• Die Referenzen auf RPortPrototype sind als Instanz-Referenzen («instanceRef») ausgeführt, da sie aus der Deployment-Ebene in die Deklarationsebene des Applikationsdesigns hinein verweisen.