Figure 10.2: Use cases for State Management

1. Diagrammtyp & Architektur-Kontext

UML-Use-Case-Diagramm zur Darstellung der Anwendungsfälle des Functional Clusters State Management innerhalb der AUTOSAR Adaptive Platform. Das Diagramm grenzt den Systemkontext der Plattform und den Teilbereich State Management gegen externe Akteure sowie angrenzende funktionale Cluster ab.

2. Komponenten, Entitäten & Schnittstellen

• Systemgrenzen & Subsysteme:
  • Adaptive Platform: Umfassender Systemrahmen.
  • State Management: Subsystem-/Komponentengrenze, enthält die Kern-Anwendungsfälle.
• Akteure & Komponenten:
  • Adaptive Application: Externer Standard-Akteur (UML-Stickman), der Zustandsänderungen initiiert.
  • Execution Management: Dämonbasiertes Functional Cluster («aapFunctionalCluster», daemon-based), dargestellt als Komponentenbaustein.
  • Platform Health Management: Dämonbasiertes Functional Cluster («aapFunctionalCluster», daemon-based), dargestellt als Komponentenbaustein.
• Anwendungsfälle («aapUseCase»):
  • Change System State: Basis-Anwendungsfall zur Zustandssteuerung.
  • Recover from Supervision Failure: Erweiternder Anwendungsfall zur Fehlerbehandlung und Wiederherstellung nach Überwachungsfehlern.
• Beziehungen & Stereotypen:
  • Adaptive Application initiiert Change System State via Assoziation mit Stereotyp «aapTriggers».
  • Change System State bindet Execution Management über eine Assoziation mit Stereotyp «aapParticipates» ein.
  • Platform Health Management stößt Recover from Supervision Failure via Assoziation mit Stereotyp «aapTriggers» an.
  • Zwischen den Anwendungsfällen besteht eine gerichtete «extend»-Beziehung: Recover from Supervision Failure erweitert den Basis-Anwendungsfall Change System State optional bzw. konditional (gestrichelter Pfeil mit offener Spitze zeigt vom Basisfall Change System State nach unten auf den erweiternden Fall Recover from Supervision Failure).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm zeigt zwei getriggerte Abläufe:

1. Reguläre Zustandsanforderung: Eine Adaptive Application löst den Basisanwendungsfall Change System State aus («aapTriggers»). Das State Management setzt diesen unter Einbindung («aapParticipates») des Execution Management um.
2. Fehlerinduzierter Ablauf: Das Platform Health Management triggert Recover from Supervision Failure («aapTriggers»). Über die «extend»-Beziehung erweitert die Fehlerbehebung das Verhalten bei Systemzustandsänderungen konditional, um auf Überwachungsfehler zu reagieren.

4. Normative Relevanz & Entwickler-Hinweise

Architekturrelevante Festlegung der Interaktion des State Managements:

• Die Zustandssteuerung (Change System State) erfordert zwingend die Mitwirkung des Execution Management («aapParticipates»), welches Prozesse und Funktionsgruppen ausführt und steuert.
• Recover from Supervision Failure erweitert («extend») das Systemzustandsverhalten semantisch als optionale/ereignisgetriebene Funktionserweiterung im Fehlerfall, statt zwingender statischer Teilbestandteil zu sein.
• Die funktionale Anbindung an das Platform Health Management erfolgt über Trigger («aapTriggers»), wobei beide Cluster als Dämonen betrieben werden.