Performance is a pervasive quality attribute of software systems. Since it plays a key role in the success of many projects, it is important to introduce approaches aimed at satisfying performance requirements from the early phases of software life-cycle. However, this is a complex problem, because a large gap exists between performance analysis results and the feedback expected by software designers. Some approaches proposed in the last few years aim at reducing such gap, based on automated Model-Driven Engineering techniques, but they are fragmented across different paradigms, languages and metamodels. The goal of this paper is to work towards an approach that enables performance problems detection and solution within an unique supporting environment. We rely on the Epsilon platform, which provides an ecosystem of task-specific languages, interpreters, and tools for MDE. We describe the approach that we are implementing, and we show how some of these languages nicely fit the needs of a unifying paradigm for performance-driven software model refactoring.
Over the last decade, research has highlighted the importance of integrating
performance analysis in the software development process. Performance is a crucial
quality attribute of many software systems, but it is a complex and pervasive
property difficult to study. If performance targets are not met, then a variety
of negative consequences (such as user unsatisfaction, lost income, etc.) can
impact on significant parts of a project [
Despite the amount of model-based performance analysis techniques that have been proposed in the last few years, the identification of performance problems is still critical, because the results of performance analysis (i.e., mean values, variances, and probability distributions) are difficult to be interpreted and translated into software feedback (i.e., design alternatives) improving system performance.
Figure 1 illustrates a typical model-based performance analysis process aimed at detecting and removing performance problems. Shaded boxes represent process activities, whereas white boxes represent artifacts.
The process starts with an initial (performance-annotated) Software Model, which represents an abstraction of the system under analysis. Performance annotations are meant to add specific information necessary for performance analysis, such as the incoming workload, service demands, etc. A Performance Model (e.g., Petri Net, Queuing Network) is obtained through model transformation from a performance-annotated software model, and it is solved analytically (in most of the cases) or by simulation during the Performance Model Solution step, which carries out performance indices of interest, e.g., mean response times, throughput distributions, and utilizations.
This represents the forward path of the process. Well-founded model-driven
approaches have been introduced in this path for inducing automation in all
steps [
The backward path takes place in case performance indices do not meet the requirements. In such case performance analysis results have to be interpreted in order to detect performance problems. Then solutions (i.e., model refactoring) have to be applied to remove problems.
The contribution of this paper concerns the backward path of the process, and
it consists of a first step towards building an approach that enables performance
problems detection and solution within an unique supporting environment [
The paper is organized as follows. Section 2 provides a background on the main ingredients of this work, i.e., performance antipatterns and the Epsilon platform. Section 3 reviews related work. Section 4 represents the core of this paper, that is how to exploit the Epsilon platform to achieve our goal, and finally Section 5 concludes the paper. 2
In this section we provide the background of this work, i.e. Performance Antipatterns and the Epsilon platform. 2.1
Since more than a decade, Performance Antipatterns [
Performance antipatterns have been originally defined in natural language
[
Figure 2 provides an UML-like graphical representation of the Pipe & Filter (PaF) antipattern, which occurs when the slowest filter in a “pipe and filter” architecture causes the system to have unacceptable throughput. In Figure 2a, the slowest filter is represented by the Operation Op and its execution causes a bottleneck in the Interaction S, which shows a throughput lower than a certain threshold. This is due to the Operation Op, owned by a Component C, that has resource demands (computation, storage, bandwidth) larger than corresponding thresholds. The Component C is manifested by an Artifact A which is deployed to a Node N showing a mean utilization util which is greater than a certain threshold.
A solution to a PaF antipattern occurrence (see Figure 2b) consists of moving the slowest filter to an ad-hoc software component deployed to a specific node. This refactoring is aimed at reducing the utilization of the node where the component owning the largest filter is deployed, and at increasing the throughput of the involved service. In Figure 2b, the Operation Op representing the slowest filter is moved to a new Component Cnew, which is manifested by a new Artifact Anew deployed on a new Node Nnew.
(a) PaF occurrence. (b) A PaF solution. Epsilon stands for Extensible Platform of Integrated Languages for mOdel maNagement. It is a platform for building consistent and interoperable task-specific languages for model management tasks such as model transformation, code generation, model comparison, merging, refactoring and validation.
Epsilon currently provides eigth languages, and for each language Eclipsebased development tools and an interpreter that can execute programs written in that language are provided.
The Epsilon ecosystem provides an infrastructure suitable for implementing our antipattern-based software model refactoring approach in several ways. In fact, Epsilon Validation Language (EVL), Epsilon Wizard Language (EWL), and Epsilon Pattern Language (EPL), allow to define declarative conditions (i.e guard and/or check) and imperative blocks (i.e., do) that have to be executed if the conditions are not satisfied. This paradigm matches with the concept of detection and solution of performance antipatterns: the declarative conditions codifies antipatterns, whereas in the imperative blocks refactoring actions that might lead to antipatterns solution are codified. The different execution semantics of the three languages mentioned above allow to provide different automated support to the user (see Section 4). 3
The problem of model (and metamodel) refactoring has been largely investigated
in the last few years, and the refactoring criteria span from usability through
modifiability up to evolution needs [
The work in [
In [
In [
In this section, we describe our approach in some detail. The main idea is illustrated in Figure 3. The approach is centered on three performance antipatterns detection and solution engines, providing different interactive support to the designer, based on EPL, EVL, and EWL. The designer selects the engine to use in order to perform refactoring sessions starting from an initial software model, i.e. M0, which conforms to a metamodel M M and is given as input to the selected engine. During a refactoring session, a number of new refactored models, i.e., M1, .., Mn−1, are created, until a software model that satisfies performance requirements is obtained, i.e. Mn. Note that, for each engine, with respect to the metamodel M M which the software model conforms to, the performance expert has to build the basic knowledge, i.e. KMM , manually. This means that she has to write the EPL/EVL/EWL code that implements performance antipatterns occurring conditions and refactorings that can be applied to remove them. 4.1
1 The implementation can be found at http://www.di.univaq.it/davide.arcelli/ resources/projects/Epsilon4PAs.rar. (a) Excerpt of an EPL pattern for PaF. (b) Refactoring session with EPL.
Fig. 4: EPL refactoring engine. (a) Excerpt of an EVL pattern for PaF. (b) Refactoring session with EVL.
Fig. 5: EVL refactoring engine. (a) Excerpt of an EWL pattern for PaF. (b) Refactoring session with EWL.
Fig. 6: EWL refactoring engine.
Figure 7 graphically shows an EVL-based model refactoring. The upper side of the figure illustrates an excerpt of a performance-annotated software model, focusing on its Static and Deployment views, expressed as a UML Component and a Deployment Diagram, respectively. Under these diagrams, their tree-based textual representations within the Eclipse UML perspective are shown. After executing an antipattern detection step that uses the EVL engine of our approach, several actions are proposed to remove the detected antipatterns (see the popup in the middle of Figure 7). When the refactoring application is completed, a new model is obtained (see the bottom of the figure), where antipatterns have been removed. In the example of Figure 7, a detected occurrence of the Pipe and Filter antipattern is removed by applying the solution described in Section 2.1. 4.2
The kind of support that our approach provides strictly depends on the execution semantics of the specific languages of the Epsilon ecosystem. The three languages that we consider in this paper allow to provide the following kind of refactoring sessions to the user.
Batch refactoring sessions (see Figure 4b): implemented as EPL patterns (see Figure 4a), they allow to execute the series of antipattern detection and refactoring specified in the corresponding .epl file. In case of iterative mode, the process is repeated until no more antipattern occurrences have been found or until the specified maximum number of iterations has been reached.
EPL provides the most limiting support to the designer, due to the fact that, in presence of two or more EPL patterns matching on identical conditions in the same .epl file, it is not possible to determine which pattern will be chosen by the Epsilon engine. For this reason, we assume that two EPL patterns matching on identical conditions cannot exist in the same .epl file. As a consequence, each antipattern can be codified only as one EPL pattern, thus limiting the solution to the unique randomly-chosen refactoring.
User-driven multiple refactoring sessions (see Figure 5b): implemented as EVL critiques (see Figure 5a), they allow to execute interactive antipattern detection and refactoring sessions, where antipattern occurrences are firstly detected on the software model, and a number of available refactorings (i.e. EVL fixes) are then selected by the user. Each selection immediately triggers the application of a refactoring on a temporary version of the software model. When the user stops the refactorng session, the temporary software model is finalized.
In the context of performance antipatterns detection and solution, we can assume that, even if more possible solutions are available for the same antipattern, they do not depend one each other (otherwise they could be collapsed into an unique refactoring). Moreover, since each refactoring is aimed at solving a detected antipattern occurrence, we can assume that the designer selects at most only one refactoring to apply for each detected occurrence.
as EWL wizards (see Figure 6a), they are directly integrated in the Eclipse
Fig. 7: Example of model refactoring effect in Epsilon. based modeling environment of the user (e.g., Papyrus2), thus automatically detecting performance antipattern occurrences whenever an element is selected in the modeling environment. They also enable solutions among which the user can select the one to apply immediately on the software model, thus carrying out a refactored one. At this point, the refactoring session is terminated, and a new one might start.
Differently from EPL patterns, two EWL wizards matching on identical conditions can exist in the corresponding .ewl file. As a result, similarly to EVL, more than one solution can be enabled with EWL. 5
In this paper, we have proposed a first step towards an approach that embeds performance antipatterns detection and solution within an unique supporting environment. In the context of the Epsilon platform, which provides an ecosystem of task-specific languages, interpreters and tools for MDE activities, we have selected EPL, EVL, and EWL as basis for three engines that provide different kinds of support to performance-driven software model refactoring.
Several aspects have been discussed in this paper and some other ones have been just mentioned. However, we need to work on them in the near future.
So far, we have implemented occurring conditions and refactorings for four performance antipatterns over twelve existing ones. Hence, we aim at extending our work to other performance antipatterns. Beside this, two next steps ahead in process automation, aimed at reducing redundant coding effort, shall be: (i) generating code from antipattern formulations, and (ii) porting the code among the three considered languages.
Finally, for sake of a future vision, we like to mention two long-term goals.
Metamodel-independence. In general, our approach is metamodel-independent, in the sense that its founding idea works for any modeling notation. However, we have experimented it on UML software models profiled with the MARTE profile. Nevertheless, several other performance-oriented modeling languages exist, e.g., Palladio and Æmilia. With this respect, we intend to enlarge the spectrum of modeling notations addressed by our approach. The approach shall be based on a pivot language (i.e., a DSL transparent to the final user) representing a neutral notation, whose constructs can be mapped to the ones of other modeling languages.
Threshold values. As discussed in [