Both in AUTOSAR and EAST-ADL we are defining architectures – be it on the software level or on the function level. But when is an architecture a good architecture? How to find flaws? One approach to assess the quality are architecture metrics. In the research project IMES we have implemented a set of metrics both for the EAST-ADL and AUTOSAR models. The metrics calculation is based on the Eclipse projects ARTOP and EATOP.
One of the often-mentioned metrics in literature are “Provided Service Utilization” (PSU) and its counter-part, the “Required Service Utilization” (RSU). PSU measures the degree of utilization of a “service provider” by dividing the number of actually used service by the total number of offered services:
A metric of 1.0 indicates that all offered services are being used, a metric of 0.0 indicates that none of the services is being used. Values below 1.0 are indicators for potential architectural issues.
To apply the PSU concepts to AUTOSAR or EAST-ADL, the elements “service provider” and “service” have to be identitfied in the meta-models. In AUTOSAR, obvious candidates for providers are the SwComponentTypes and SwComponentPrototpyes. Candidates for services are the ports (it is also possible to work with the data elements of a port, resulting in a finer granularity of the metric). Picking SwComponentTypes or SwComponentPrototpyes for “provider” results in subtle differences:
In the above model, the metrics for the prototypes are PSU(p1)=1.0 (Port op is connected) and PSU(p2) = 0.0 (not connected). For the component types, PSU(ACI1O1_A)=1.0, since it is only relevant if the port is connected at all.
Deciding if a port is actually connected is more complex than in the simple example above. Delegation connectors just “forward” the ports without functionality – that has to be taken into account. A port being connected through a delegation does not count as a connected port for the metrics calculation. Starting from a port, all transitive connections have to be followed to see if the port is finally connected to a software component that actually consumes data (i.e., not a SwCompositionType), or if it is delegated to the highest level or not delegated at all.
Since we also want to calculate metrics for partial architectures, we define a delegation to the root level as “connected”, but there are other approaches that define such a delegation as “unconnected”.
Side Effect for Usability
The algorithm for finding connected ports has a nice side effect: It can be offered to the user as an extra functionality. In complex models, it is often difficult to track the actual destination of data elements through a port. The algorithm makes that easy.
PSU and CPSU
In the model above, PSU(In0Out3)==0.666. The same algorithms can be used to calculate the CPSU that indicates the ratio of (connected ports/total ports) of all ports of all SwComponentPrototypes of a subsytem. A metric < 1.0 indicates that the system has unconnected ports. In the above model, CPSU = 0.5. It is important to identify prototypes that are only composition types, since they are only structural and should not be used for metrics calculation by counting ports more than once.
RSU, EAST-ADL and variants
The calculation of RSU is analogous to the PSU calculation. And the metrcis calculation is not restricted to software architectures. Metrics for EAST-ADL analysis functions and design functions can be calculated in the same way. In fact, our implementation is working on an abstract component / service model that maps to Artop and EATOP implementations, so that we can actually use the same code for both meta-models.
In addition, it can be combined with the variant / featuremodels, so that metrics for entire product lines can be calculated and “loose ends” can be found.