Utility Function for mRUBiS

For mRUBiS and the two case studies, self-healing and self-optimization, we provide utility functions that are discussed below. The concept of utilty function in context of the exemplar is discussed here.

Self-Healing Utility Function

The utility function to compute the utility of mRUBiS for the self-healing case is implemented by the class de.mdelab.simulator.mrubis.utility.MRubisSelfHealingUtilityFunction.

It defines the utility of mRUBiS as the sum of the utilities of all Tenants. The utility of a Tenant is the sum of the utilities of all STARTED Components of this tenant. The utility of a component c is c.type.reliability x c.criticality x c.connectivity while the connectivity of a component is the number of Connectors associated to the RequiredInterfaces and ProvidedInterfaces of this component. However, if a required interface of the component is not connected (there is no connector), the connectivity is zero. Thus, the utility of a component takes into account how reliable it is, how critical it is, and how the degree of connectivity to other components as an indicator for its importance.

Consequently, the utility of mRUBiS is decreased to the extent a component adds value to the utility if the component...

• is not STARTED but especially in state UNKNOWN. This happens when a CF1 occurs. To address the issue that a self-adaptation just deploys and starts arbitrary many components to increase the utility, the hard constraint that each ComponentType should only be instantiated once to a deployed and started component for each Tenant must be satisfied. This constraint is checked by the simulator when validating the model using the various validators.
• throws too many Exceptions. This corresponds to a CF2.
• has been removed from mRUBiS and therefore does not exist anymore. This corresponds to a CF3.
• loses its connectivity, that is, if one of its required interface is not associated to a connector. This corresponds to CF5.

In this context, CF4 does not directly cause a decrease of the utility since it only refers to situations where a CF1 or CF2 occurs, which are already addressed by the utility function.

Self-Optimization Utility Function

The utility function to compute the utility of mRUBiS for the self-optimization case is implemented by the class de.mdelab.simulator.mrubis.utility.MRubisSelfOptimizationUtilityFunction.

The utility of mRUBiS is computed in the same way as for the self-healing case (see previous section). Thus, the utility is higher the more filter components are deployed and running in each tenant (i.e., longer pipes of filter components have a higher utility than shorter pipes). This utility is decreased by this utility function if there is are performance issues (PIs) in the model:

• For each filter Component that is not at its optimal position in the pipe of filters (PI1), the overall utility is decreased by the half of the utility of this filter Component.
• For each Tenant in which the average response time of the personalized search is above a given threshold (PI2), the overall utility of the tenant is reduced by 20%.
• If there is a PI3, that is, the average response time of the personalized search is below the lower threshold in a tenant, the overall utility is not reduced since the performance is better than desired. However, there might be potential for improving the utility by adding filter Components to the tenant if the pipe does not already have the maximum size (maximum size means that all available filter types are instantiated and used). Adding filters increases the response time of the personalized search, which might resolve a PI3, and increases the overall utility to the amount of the utilities enabled by the added filters (see the previous section on how the utility of an individual component is calculated).