Metriken für AUTOSAR-Architekturen und logische Funktionsnetze
Was ist ein gute Software- oder Funktionsnetzarchitektur? Einen Ansatz zur Bewertung liefern Metriken, die Kennzahlen zu den jeweiligen Modellen stellen. Diese lassen sich auf AUTOSAR-Modelle und Funktionsnetzarchitekturen anwenden.
- Andreas Graf
Eine der in der Literatur verbreiteten Kennzahlen ist die Provided Service Utilization (PSU) beziehungsweise deren Gegenstück, die Required Service Utilization. Bei Betrachtung der PSU wird für einen "Diensteanbieter" s in der Architektur der Quotient aus der Anzahl der tatsächlich verwendeten Dienste durch die Anzahl der insgesamt von diesem angebotenen Dienste gebildet. Also
PSU(s) = (PS_used(s))/(PS_total(s)).
Ein Wert von 1.0 gibt dabei an, dass alle angebotenen Dienste verwendet werden, ein Wert von 0.0 zeigt, dass keiner der Dienste benutzt wird. Werte unter 1.0 können ein Hinweis auf mögliches Verbesserungspotenzial oder Probleme sein.
Um die Metriken auf AUTOSAR oder Funktionsnetzarchitekturen (wie EASTADL) zu übertragen, sind die Konzepte "Diensteanbieter" und "Dienst" im jeweiligen Meta-Modell zu identifizieren. Für AUTOSAR sind offensichtliche Kandidaten die Softwarekomponenten (SwComponentType) und die Softwarekomponenten-Prototypen (SwComponentPrototype), das heißt die "inneren" Auftreten eines Komponententyps in einer Composition-Type. Als Dienste lassen sich zum Beispiel die Ports betrachten (auch eine feingranulare Beobachtung auf Ebene der pro Port versendeten Datenelemente wäre möglich). Ob als Anbieter die SwComponentTypes oder die SwComponentPrototypes untersucht werden, macht dabei einen Unterschied.
(Bild: itemis)
In Abbildung 1 wären PSU(p1) = 1.0 (der Port op ist verbunden) und PSU(p2) = 0.0 (für diesen Prototyp ist der Port nicht verbunden). PSU(ACI1O1_A) = 1.0, da es hier nur darauf ankommt, ob ein Port irgendwo verbunden ist [–-] sodass sich sehr unterschiedliche Werte ergeben können.
Verfolgung der Komponenten
Die Ermittlung, ob ein Port verbunden ist, ist dabei etwas kniffliger als im obigen Beispiel. Die "Delegations-Konnektoren", die die Ports der SwComponentPrototypes weiterleiten, erzeugen zusätzliche Komplexität. Dass ein Port über einen DelegationConnector im Modell verbunden ist, gilt nicht als Endverbindung für die Berechnung des PSU: SwCompositionTypes dienen nur zur Weiterleitung und besitzen kein eigenes Verhalten. Das heißt, von einem Port ausgehend müssen alle möglichen Verbindungen verfolgt werden, um zu sehen, ob der Endpunkt eine Softwarekomponente ist, die die Daten tatsächlich verwertet (das heißt kein SwCompositionType), ob er nicht verbunden ist oder bis auf oberste Ebene delegiert wird.
Da wir auch Teilarchitekturen bewerten wollen, betrachten wir eine Delegation bis zur obersten Ebene als "verbunden" – es existieren aber auch andere Ansätze, die einen Port in diesem Fall nicht als verbunden ansehen.
Nützlicher Nebeneffekt: Usability
Die Berechnung der verbundenen Ports liefert auch ein nützliches Feature für den Anwender: In komplexen Modellen ist es oft schwierig zu überblicken, wo die Elemente, die über einen Port versendet werden, letztlich landen. Das lässt sich nun mit dieser Berechnung leicht ermitteln.
PSU und CPSU
Jetzt lässt sich der PSU verschiedener SwComponentTypes und SwComponentPrototypes berechnen.
(Bild: itemis)
So gilt für obige Abbildung: PSU(In0Out3) == 0.666. Mit der gleichen Berechnungsmethode lässt sich der CPSU errechnen, der für ein gesamtes Teilsystem den Quotienten verbundener Ports/Gesamtzahl der Ports aller enthaltener SwComponentPrototypes (über alle Ebenen) ermittelt. Ein Wert < 1.0 weist dabei auf viele unverbundene Ports hin. Für Abbildung 2 gilt CPSU = 0.5. Wichtig ist es dabei, bei der Ermittlung der relevanten SwComponentPrototypes diejenigen herauszufiltern, die SwCompositionTypes darstellen – diese dienen ja nur zur Weiterleitung und würden die Kennzahl durch Doppelzählung eines Ports verfälschen.
RSU, Funktionsnetzarchitekturen und Produktlinien
Für die Berechnung des RSUs gelten die gleichen Methoden wie für den PSU. Auch ist man bei der Berechnung der Metriken nicht auf Software-Architekturen beschränkt. Die Metrikberechnung für logische Funktionsnetzarchitekturen läuft zum Beispiel analog. In unserer Implementierung haben wir die Ermittlung der Ports und Prototypes noch mit einem Variantenmodell gekoppelt, sodass die Metriken für verschiedene Produktlinien eines Modells berechnet und "offene Enden" so ermittelt werden können. ()
