-
Notifications
You must be signed in to change notification settings - Fork 1
Validators
The mRUBiS exemplar provides the following validators to validate the CompArch model after a self-adaptation. Additionally, developers may provide their individual validators by implementing the interface de.mdelab.simulator.Validator.
There exists generic validators that are independent of the system such as mRUBiS that is modeled in CompArch, and that are specific to mRUBiS.
Retrieves all Components of all Tenant architectures ordered by their states (see attribute Component.state and grouped by their tenants. The validation particularly checks for components in state UNKNOWN, which indicates that something is wrong with the life cycle of the component. In this case, an issue is raised by the validator.
Validates for each Tenant architecture if and how many Exceptions are thrown by ProvidedInterfaces. It becomes an issue if the number of exceptions thrown by one provided interface exceeds the given threshold.
Validates for a minimal configuration of each Tenant architecture. A minimal configuration is one where each ComponentType is only instantiated at most once per Tenant, that is, there are no two STARTED Components of the same ComponentType in one Tenant. Otherwise, the same functionality is provided by more than one component, which requires more resources than actually needed. Thus, an issue is raised if one component type is instantiated more than once per tenant.
Validates for each Tenant architecture whether each (configuration) Parameter of a STARTED Component has a value assigned (see attribute Parameter.value). An issue is raised if such a parameter has no value assigned.
Validates each Tenant architecture whether its STARTED Components provide together all given interfaces such that the tenant actually provides the necessary functionality to be operable. An issue is raised for each of the given interfaces that are not provided by a started component in each tenant.
Validates for each Tenant architecture whether each RequiredInterface is connected to a ProvidedInterface STARTED Component within the same Tenant. An issue is raised for each required interface that is not connected or that is connected to a component of another tenant.
Validates a self-adaptation that adjust the life cycle state of a Component (see attribute Component.state), for instance, to start or stop a component. The validation checks whether such a self-adaptation conforms to the life cycle of a component. If not, an issue is identified by this validator.
If a self-adaptation does not follow the life cycle, the state of the component effected by the self-adaptation is set to UNKNOWN.
Validates a self-adaptation whether it replaces a Component with a Component of another ComponentType. Both components provide the same functionality in terms of ProvidedInterfaces but they are realized differently and are therefore of a different type (see reference Component#type).
This validator does not identify any issues but provides information about how a self-adaptation has been performed when changing the structure of the architecture.
Validates for each Tenant architecture whether each RequiredInterface is connected to a ProvidedInterface of a STARTED Component within the same Tenant and whether the connected RequiredInterface and ProvidedInterface are of the same InterfaceType.
It takes into account that in each tenant one required interface is not connected by design; this required interface belongs to the last filter component in the pipe. Thus, this unconnected required interface does cause an issue. In general, each tenant architecture may contain at most one started filter component whose required interface is not connected.
An issue is raised if any of the previously mentioned criteria are not satisfied.
Validates for the minimal configuration of each Tenant architecture in terms of provided interfaces and the number of components providing each interface within one tenant.
Each interface, that is, InterfaceType should only be provided as a ProvidedInterface by exactly one STARTED Component within one Tenant. Otherwise, more than one component providing the same functionality is running and consuming resources.
This holds for each interface except of "de.hpi.sam.rubis.filter.ItemFilter" as there is usually a pipe of more than one filer component deployed so that more than one started component is providing (and requiring) this interface.
An issue is raised if more than one started component within one tenant provides the same service interface.
Validates that each filter Component of a Tenant's pipe is of a different filter ComponentType. (It does not make sense to apply more than one filter of the same type within one pipe since they realize the same functionality).
A filter component is one that has a ProvidedInterface of the InterfaceType with the fully qualified name (see attribute InterfaceType.fqName) "de.hpi.sam.rubis.filter.ItemFilter".
An issue is raised for each additional instance of the same filter ComponentType within the same pipe.
Validates the pipe of filter Components in each Tenant architecture whether the pipe contains any cycle among the filter components or not. An issue is raised if there is a cycle among the filter components of a pipe.
Validates for each Tenant the pipe of filter Components in each Tenant architecture whether the pipe contains at least so many filter components as the given threshold. An issue is raised for each pipe that contains less filters than the given threshold.
Validates for each Tenant architecture the ordering of filter Components in the pipe. The ordering is determined by the individual slope of the selection rate s and local computation time c (i.e., s/c) of each filter of the pipe. A filter component with a bigger slope is located before any other filter component with a smaller slope in the pipe. Thus, the slopes of filter components decreases from the front to the back of the pipe and they determine the ordering of the filter components in the pipe.
An issue is raised for each filter component that is not well located in the pipe with respect to its neighboring filter components.
Validates for each Tenant architecture the average response time for the personalized item search, that is, for the method "getPersonalizedItems(java.lang.String,java.lang.String)" of the interface "de.hpi.sam.rubis.itemmgmt.BrowseCategoriesService" based on the corresponding {@link PerformanceStats} elements. Ideally, the average response time should be around a response time goal and between a lower and an upper boundary.
An issue is raise either when the average response time is above the upper boundary and the pipe contains more than one filter, or when the average response time is below the lower boundary and the pipe does not use all available filters (i.e., unused filters could be added to the pipe).
Validates a self-adaptation of a pipe of filter Components and reacts to the self-adaptation by changing the performance stats in the model as if the self-adaptation impacts the performance of the managed system.
For instance, if filters are added to the pipe, the response time increases; if filters are removed from the pipe, the response time decreases; if a misordering of filters in the pipe is corrected, the response time decreases.
This validator does raise any issue.
Validates the model after a self-adaptation to check whether all filter Components have a MonitoredProperty for the selection rate and a MonitoredProperty for the local computation time. In the case that these properties are missing for a filter component, this validator creates and adds them to the filter.
For instance, if a filter component has been removed, and a new filter component of the same type has been deployed, this new filter component has
no MonitoredProperty. In this case, this validator adds these property elements. Using a real system, the monitored properties are added to the model by monitoring the running system and updating the model.
This validator does not raise any issues.
mRUBiS Exemplar by Thomas Vogel (2018)