Issues for mRUBiS

For the mRUBiS example, we defined four types of issues to be addressed by self-healing and three types of issues to be addressed by self-optimization. The definition of the issue types is based on the CompArch metamodel.

Additionally, developers may define individual issue types by providing injectors, that is, implementations of the interface de.mdelab.simulator.Injector<T>. The type parameter T refers to the type of the architectural element of a CompArch model, to which the issue will be injected. For instance, if we consider a component crash as an issue type, then the architectural element type is the Component. Thus, an injector requires a target type to which an issue type will be injected and a behavior that actually injects the issue to the target.

In the following, we describe the issue types and the potential adaptation strategies to address them.

Issue Types for the Self-Healing Case

Each issue type is a critical failure (CF) of the architecture, which should be handled by self-healing. The four issue types or critical failures we defined for the self-healing case are as follows:

CF1: Component Crash

A STARTED Component has crashed and therefore, its life cycle state (see Component.state) has been set to UNKNOWN.

• Injector: de.mdelab.simulator.mrubis.injectors.CF1_Injector
• Target: Component to be crashed
• Suitable strategies: AS1, AS2, AS3, AS4

CF2: Exception Occurrence

The usage of a ProvidedInterface of a STARTED Component by a STARTED Component has caused multiple Exceptions, that is, the number of Exceptions that are attached to the ProvidedInterface are above the given threshold.

• Injector: de.mdelab.simulator.mrubis.injectors.CF2_Injector
• Target: ProvidedInterface throwing the exceptions
• Suitable strategies: AS1, AS2, AS3, AS4

Additionally, there exists another injector that only adds so many Exceptions that the given threshold is not reached, which does not cause a CF2 but requires checking if and how many exceptions exist for a provided interface (see de.mdelab.simulator.mrubis.injectors.NoCF2_Injector).

CF3: Component Destruction

A STARTED Component has been destroyed (severe crash) and completely removed. This includes the removal of all elements that are directly and transitively contained in the Component. These are the Parameters, RequiredInterfaces, Connectors of the required interfaces, MonitoredProperties, PerformanceStats, and Exceptions of the provided interfaces.

• Injector: de.mdelab.simulator.mrubis.injectors.CF3_Injector
• Target: Component to be removed
• Suitable strategies: AS3, AS4

CF4: Continuing Issues

A Component is affected by CF1 or CF2 in three consecutive runs of the feedback loop. This indicates severe issues with the Component because each individual run of the feedback loop was not able to heal the issues effectively.

There is no injector for this CF since it is realized by a combination of CF1 and CF2 injections, which is specified by the simulation scenario.

• Suitable strategies: AS1, AS2, AS3, AS4

CF5: Connector Loss/Crash

A Connector between two STARTED Components has been lost and therefore been removed from the architecture. As a consequence, required interfaces are not connected.

• Injector: de.mdelab.simulator.mrubis.injectors.CF5_Injector
• Target: Connector to be removed.
• Suitable strategies: AS5

Issue Types for the Self-Optimization Case

Each issue type is a performance issue (PI) of the architecture, which should be handled by self-optimization. The four performance issues we defined for the self-optimization case are as follows:

PI1: Non-Optimal Ordering of Filter Components

Changes the performance of a filter Component so that this component is not located any more at its optimal position in the pipe of filter components.

The performance of a filter Component is changed by updating the value of the MonitoredProperty for the selection rate or the value of the MonitoredProperty for the local computation time of the filter component.

• Injector: de.mdelab.simulator.mrubis.injectors.PI1_Injector
• Target: Tenant that will be affected by the change.
• Suitable strategies: AS6

PI2: Increased Average Response Time

The average response time of the personalized search for items exceeds a given threshold. Accordingly, this injector changes the PerformanceStats of the personalized search within the given Tenant.

• Injector: de.mdelab.simulator.mrubis.injectors.PI2_Injector
• Target: Tenant that will be affected by the change.
• Suitable strategies: AS7

PI3: Reduced Average Response Time

The average response time of the personalized search for items is below a given threshold. Accordingly, this injector changes the PerformanceStats of the personalized search within the given Tenant.

• Injector: de.mdelab.simulator.mrubis.injectors.PI3_Injector
• Target: Tenant that will be affected by the change.
• Suitable strategies: AS8