Transient Effects Analysis
| Name | Transient Effects Analysis |
|---|---|
| Contacts | Christian Stier (http://sdq.ipd.kit.edu/people/christian stier/) |
| State | Stable |
| Is Stand-alone Analysis? | No |
| Extends Analyses | SimuLizar |
| Extends Metamodels | Annotations, New Notation Elements, New Views |
| Code Location | https://github.com/PalladioSimulator/Palladio-Analyzer-SimuLizar |
| Update Site | https://sdqweb.ipd.kit.edu/eclipse/palladiosimulator/nightly/ |
| JIRA | https://jira.palladio-simulator.com/projects/SIMULIZAR/ |
Short Summary
Enables the consideration of transient effects in the analysis of self-adaptive software systems. Transient effects subsume interdependencies between reconfiguration duration, quality impact of reconfigurations, and system utilization. The use of the extension, e.g., enables the accurate evaluation of reconfigurations that cause resource demand when executed.
Documentation
The transient effects analysis relies on a systematic modeling of transient effects as parametrized, executable instances of the Adaptation Action metamodel. Please refer to our publication and the dissertation by Christian Stier for details on the Adaptation Action metamodel design and analysis approach.
Analysis Design and Use
The transient effect analysis was designed to enable software architects to evaluate the effect and dependency of reconfiguration performance with self-adaptive software systems. It adheres to and follows the definition of actions as subsumed by the modeling concept Strategies, Tactics, Action (S/T/A). S/T/A structures reconfigurations as a hierarchy of strategies (top), tactics, and actions (bottom). An action is a reconfiguration operation supported by the execution environment of the software system. An example action is the execution of a VM migration in an Infrastructure-as-a-Service (IaaS) Cloud environment.
To avoid naming collisions with the Actions in the Resource-Demanding Service Effect Specifications in Palladio (RDSEFF), the following and the implementation refer to adaptation actions as Adaptation Behaviors.
Please refer to Chapter 6 of the dissertation by Christian Stier for detailed information on language design and analysis logic. This section focuses on the essentials of using existing adaptation actions, and the definition of new actions.
Use of Adaptation Actions/Behaviors in SimuLizar Analyses
As a prequisite to use existing specifications, the user of a SimuLizar simulation has to specify the Adaptation Action model instance that contains the actions she wants to use:
Example Adaptation Behaviors
The default repository contains a set of Adaptation Behaviors for considering the transient effects of:
- power state transitions: PowerStateChanging,
- VM/component migration: ComponentMigration,
- Component instantiation: ComponentInstantiation,
- Adapting the load distribution of a load balancer: Load balancing behavior.
The behaviors are documented in the dissertation by Christian Stier.
Use in QVTo
To use an existing Adaptation Behavior definition in their reconfiguration, the self-adaptive software architect imports the behavior definition in their reconfiguration. We explain this by the example of reconfigurations defined in QVTo.
As a prequisite to use an adaptation action, the user has to specify the Action model as part of the transformation signature:
transformation ScaleOutReconfiguration(
in prm : RUNTIMEMEASUREMENT,
inout pcmAllocation : PCM_ALLOC,
inout actionsInput : ACTIONS,
out roleSets : INSTANCE) {
The actionsInput model contains the Action repository, the roleSets has to be defined for the adaptation action to have instantiation and output parameters that can be used and read outside of the QVTo model transformation.
Further, the transformation should import the metamodel namespaces of the Action metamodel:
modeltype ACTIONS uses 'http://simulizar.palladiosimulator.org/Actions/Core/1.1';
modeltype INSTANCE uses 'http://simulizar.palladiosimulator.org/Actions/Instance/1.1';
In order to look up the action, the ID or name of the action can be used:
var scaleOut : AdaptationBehavior := adaptationBehaviorRepository.actions[id = scaleOutid]->any(true);
The Behavior then can be executed by calling one of its execute EOperations with instantiation parameters:
helper scaleOut(var instantiateVm : Action, instantiatedComponent : BasicComponent, targetResourceContainer : ResourceContainer, controllerContainer : ResourceContainer) : Boolean {
// Instantiate parameters for Action
var roleSet : RoleSet := object RoleSet@roleSets {
roles += object instance::Role {
roleType := instantiateVm.getRoleTypeById(targetResourceContainerRoleId);
value := targetResourceContainer.oclAsType(EObject);
};
roles += object instance::Role {
roleType := instantiateVm.getRoleTypeById(instantiatedComponentRoleId);
value := instantiatedComponent.oclAsType(EObject);
};
roles += object instance::Role {
roleType := instantiateVm.getRoleTypeById(loadBalancerRoleId);
value := controllerContainer.oclAsType(EObject);
};
roles += object instance::Role {
roleType := instantiateVm.getRoleTypeById(controllerContainerRoleId);
value := controllerContainer.oclAsType(EObject);
};
};
return instantiateVm.execute(roleSet, prepareInputForControllerCall());
In the listed example, the action is parameterized by: targetResourceContainer
- the target location for a scale-out:
instantiatedComponentRole - the component that represents the instantiated VM:
instantiatedComponent - the load balancer component instance that the new component should be wired with:
loadBalancerRole - the location of the middleware component:
controllerContainerRole
Once the resource demands associated with the Adaptation Behavior have been processed, the transformation returns and continues with the remaining steps of the QVTo reconfiguration rule. Note: There are also asynchronous implementation alternatives to execute.
Definition of new Adaptation Actions
The Adaptation Action metamodel was designed to support the reusable specification of Adaptation Behaviors. Each behavior consists of a set of AdaptationSteps that execute parts of it. We refer to the dissertation document for a process overview on how to define additional actions, and detailed semantics of each step type.
Example Instance
There are two basic examples that leverage the Transient Effects Analysis.
Horizontally Scaling Media Store
The horizontally scaling Media Store example from the SimuLizar GIT is a simplified version of the case study system used in the referenced paper. It instantiates additional Reencoder component instances to deal with an increasing rate of reencoding requests. The reconfiguration rule scales the numer of Reencoder components once a predefined threshold is surpassed, and executes the horizontal scaling using the ComponentInstantiation Adaptation Behavior. The reconfiguration rule reconfigurations_active\horizontalscaling.qvto contains this rule definition.
The Monitors contain a monitor which causes the reconfiguration time of each successful reconfiguration execution to be recorded. This recorded reconfiguration time includes the execution of Adaptation Behaviors:
Note: The time is reported at the completion at a reconfiguration. Consequently, the point in time at which a successful reconfiguration was started can be calculated as the difference between the x and y values of its measurement tuple.
Transition Between Power States
The second example is derived from the basic load balancer example of SimuLizar. It is available in the SimuLizar GIT. The example requires the power consumption analysis to function.
The example system integrates a reconfiguration rule that turns off all unused servers. The example uses the PowerStateChanging Adaptation Behavior. During shutdown, the servers consume power according the transition function from its stateful power model. As one server is unused from the beginning, the reconfiguration rule starts the shutdown at the beginning of the simulation. The rule is implemented in the rules_active/switchToStandby.qvto QVTo reconfiguration rule.
References
- Christian Stier and Anne Koziolek. Considering Transient Effects of Self-Adaptations in Model-Driven Performance Analyses. In 2016 12th International ACM SIGSOFT Conference on Quality of Software Architectures (QoSA), Venice, Italy, 2016, QoSA'16. ACM. 2016. .pdf Note: This paper refers to Adaptation Behaviors by the name established in the community, i.e., adaptation actions.
- Christian Stier. Adaptation-Aware Architecture Modeling and Analysis of Energy Efficiency for Software Systems. PhD thesis, Karlsruher Institut für Technologie (KIT), Germany, 2018. .pdf