-
Notifications
You must be signed in to change notification settings - Fork 1
Validators for mRUBiS
Besides the generic validators, the exemplar provides the following validators for the mRUBiS architecture described by a CompArch model. These validators are specific to mRUBiS.
Additionally, developers may provide their individual validators by implementing the interface de.mdelab.simulator.Validator.
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 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)