Applying Model Differences to Automate Performance-Driven ...

Applying Model Differences to Automate Performance-Driven Refactoring of Software Models Davide Arcelli, Vittorio Cortellessa, and Davide Di Ruscio Dipartimento di Ingegneria e Scienze dell’Informazione e Matematica Universit`a degli Studi dell’Aquila 67100 L’Aquila, Italy {davide.arcelli,vittorio.cortellessa,davide.diruscio}@univaq.it

Abstract. Identifying and removing the causes of poor performance in software systems are complex problems, and these issues are usually tackled after software deployment only with human-based means. Performance antipatterns can be used to harness these problems since they capture design patterns that are known leading to performance problems, and they suggest refactoring actions that can solve the problems. This paper introduces an approach to automate software model refactoring based on performance antipatterns. A Role-Based Modeling Language is used to model antipattern problems as Source Role Models (SRMs), and antipattern solutions as Target Role Models (TRMs). Each (SRM, TRM) pair is represented by a difference model that encodes refactoring actions to be operated on a software model to remove the corresponding antipattern. Differences are applied to software models through a model transformation automatically generated by a higher-order transformation. The approach is shown at work on an example in the e-commerce domain.

1

Introduction

Identifying and removing the causes of poor performance in software systems are complex problems due to a variety of factors to take into account. Similarly to other nonfunctional properties, performance results from interactions among software components, underlying platforms, users and contexts [24]. Current approaches to these problems are mostly based on the skills and experience of software developers or, in the best cases, the ones of performance analysts. Profiling tools have been introduced for performance monitoring of running applications [20], but it is well-known that the cost of solving performance problems at runtime is orders of magnitude larger than the one at early phases of the software lifecycle. Hence, instruments that help to identify and remove causes of performance problems early in the lifecycle would be very beneficial. In the last two decades the concept of performance antipattern has been used for “codifying” knowledge and experience of analysts. Smith et al. [21] have ultimately specified 14 performance antipatterns. A performance antipattern identifies a problem, i.e. a bad practice that negatively affects software performance, and a solution, i.e. a set of refactoring actions that can be carried out to remove it. We have based our recent research work on this repository of knowledge with the aim of making it a cornerstone in identifying and removing performance problems. We have first tackled the problem

2

D. Arcelli, V. Cortellessa, D. Di Ruscio

of providing a less ambiguous antipatterns representation, in respect with their original definition in natural language [7]. However, performance antipatterns are very complex (as compared to other software patterns) because they are founded on different characteristics of software systems, and they additionally include values of performance indices. This high complexity requires multi-view representations. Thereafter, we have introduced several techniques aimed at detecting performance antipatters in software models [7]. More recently we undertook the problem of removing performance antipatterns detected in a software model by introducing a role-based approach that allows to formalize the refactoring of the latter [3]. In this paper we build up on previous results and move a further step ahead. We work on introducing automation in refactoring of software models that show unsatisfactory performance indices. In particular, we present an innovative approach that uses model differencing to represent and apply actions that remove performance antipatterns from software models. Goal of the paper is to introduce mechanisms that enable developers to analyze automatically generated solutions to performance problems, instead of looking for them only on the basis of experience.

Fig. 1. Software model refactoring based on antipattern detection.

Model Differencing for Automated Performance-Driven Software Models Refactoring

3

Figure 1 shows the process envisaged to address this problem. Human roles are explicitly shown. Rectangles represent artifacts; gears represent automated activities. The process starts with a Software Model produced by a software designer. A performance expert1 annotates the software model with performance characteristics (i.e. workload, resource demands, etc.), and a round-trip performance engineering process starts in order to meet performance requirements provided by the customer. At each process iteration the (Performance-annotated) Software Model is transformed into a Performance Model (i.e. a queueing network) that, once solved, provides Performance Indices (i.e. response time (RT), throughput (T), and utilization (U)) [9]. If the indices do not meet performance requirements, then the backward path of the round-trip process is executed. A detection step produces a list of Detected Performance Antipatterns (APs) occurring in the software model [7]. Then, with the help of heuristic strategies, the development team can identify critical antipatterns [8] and Refactoring Actions (Ref Actionsj ) that allow to remove them [3]. The final step of the process consists to apply refactoring actions to the (Performance-annotated) Software Model, thus producing a refactored software model where the antipatterns have been removed. The focus of this paper is the specification and automated application of refactoring actions, i.e. Refactoring Actions and Refactoring Application items in Figure 1. The paper is organized as follows: Section 2 provides background on antipatterns and role models; Section 3 describes our approach for antipattern-based software model refactoring; Section 4 shows the approach at work on an e-commerce case study; Section 5 presents related work, and finally Section 6 concludes the paper.

2

Role modeling for Antipatterns definition and solution

In this section we provide a background on performance antipatterns through the rolebased description of the Empty Semi Trucks (EST) antipattern [21]. The concept of role has been introduced in the last years in many contexts to express the possibility to assign different functions to the same entity in different settings. We have used a Role-Based Modeling Language (RBML) to annotate model entities involved in performance antipatterns, and to track these entities for applying refactoring actions that remove antipatterns. In particular, we have ported RBML, that was introduced in [12] to assign roles to UML elements for applying design patterns, into the performance antipattern domain. In order to do this, we have first replaced the original UML elements on which RBML was defined with notation-independent ModelElements2 . They represent a vocabulary, called SML+ [22], used for specifying performance antipatterns within a metamodel called PAML (Performance Antipattern Modeling Language)3 . The left-hand side of Figure 2 shows an excerpt of PAML/SML+. 1 2

3

Note that software designer and performance expert are not necessarily distinct. Since we assume to have multi-view software models annotated with performance-related data that concur to the antipattern definition, ModelElements can appear in static, dynamic and deployment views. In the following we use subsequent notation: with a typewritten font we refer RBML elements, whereas with a sans-serif we refer PAML/SML+ elements.

4

D. Arcelli, V. Cortellessa, D. Di Ruscio

Fig. 2. Role-Based Modeling Language applied to performance antipatterns.

The right-hand side of Figure 2 shows an excerpt of our RBML reference metamodel and the relationships that we have defined with PAML [3]. Topmost boxes represent the RBML concepts we have inherited from [12], that are: RoleModel, Role and RealizationMultiplicity. A RoleModel contains a set of Roles, where each role annotates (is played by) a certain number of ModelElements. A RealizationMultiplicity specifies the number of elements playing a certain role. Furthermore, we have introduced the concepts of SourceRoleModels and TargetRoleModels (as specializations of RoleModel) in order to describe antipattern problems and solutions as pairs of RoleModels, where a SourceRoleModel (SRM) represents (part of) a problem and a TargetRoleModel (TRM) represents the corresponding solution. The set of ModelElement specializations in SML+ represents target elements (i.e. the bases) that should play the Roles (specializations) defined in RBML, thus enabling the role-annotation of software model elements. Bases and roles have been detailed in SML+ and RBML but not reported in Figure 2 for sake of readability. Note that dashed boxes in Figure 2 are not complete, as other ModelElements and Roles have been defined up to now and can be defined in future. Different refactoring actions can be applied to solve a performance antipattern, hence different (SRM, TRM) pairs can be associated to the same antipattern. We have used RBML to build several (SRM, TRM) pairs. Our repository of RoleModels [2] currently contains: three pairs for the Blob antipattern, one pair for the Concurrent Processing Systems antipattern, one pair for the Empty Semi Trucks, and two pairs for the Pipe and Filter. We recall that Smith et al. have specified 14 performance antipatterns [21], hence we cover 4/14 performance antipatterns as a starting point for our work. EST may be due to inefficient use of available bandwidth, an inefficient interface, or both. Refactoring actions have been proposed for both the cases. We consider here the latter one, assuming that the solution applies the Facade design pattern4 . According to the vocabulary and the detection rules defined in [7], an EST antipattern occurs when there is a software entity instance (GenericSwEntityInstance) that: (i) generates an excessive 5 message traffic towards another software entity 4 5

http://developer.java.sun.com/developer/restricted/patterns/SessionFacade.html The characterization of antipattern parameters related to system characteristics (e.g. excessive message traffic) or to performance results (e.g. high, low utilization) is based on thresholds [7].

Model Differencing for Automated Performance-Driven Software Models Refactoring

5

instance (RemoteInstance), (ii) is deployed on a processing node with a high utilization value, i.e. GenericSwEntityInstanceDeployNode, and (iii) the network link on which the message traffic is generated shows a high utilization value, i.e. Network. The simultaneous occurrence of such properties leads to assess that the GenericSwEntityInstance originates an EST antipattern.

3

Model differencing for model refactoring

In this section we propose our approach based on model differencing of (SRM, TRM) pairs and model-to-model transformations for automating the application of refactorings aimed at removing antipatterns from software models. Figure 3 maps the concept of refactoring actions to the metamodeling view of our approach in the MDE domain. In the conceptual domain, we want to apply a set of refactoring actions Ref Actionsj (APi ) to a software model that contains a certain antipattern instance APi problem, in order to produce a new software model where an APi solution has been applied. In the MDE domain, Ref Actionsj (APi ) are represented by their corresponding difference model Dif f M odelj (APi ). This model is the output of a model transformation Dif f Calculation that takes as input a (SRMj (APi ), T RMj (APi )) pair describing APi problem and APi solution. Finally, as illustrated in the bottom part of the MDE domain, refactoring actions are applied by means of the model transformation Dif f Application that produces the (Role-annotated) Refactored Software

Fig. 3. Meta-modeling view and model transformations of the solution step.

6

D. Arcelli, V. Cortellessa, D. Di Ruscio

Model starting from the original (Role-annotated) Software Model 6 . Topmost half of the MDE domain box of Figure 3 describes the metamodels to which models conform and their relationships (level M2 in a MDE hierarchy). Software Models conform to SML+. Dif f M odelj (APi ) conforms to RBMLDIFF, i.e. a difference metamodel corresponding to RBML. RBMLDIFF is automatically generated by means of the M M 2M M DIF F model-to-model transformation we have defined basing on the metamodel-independent approach for differences representation proposed in [6]. RBMLDIFF contains modeling constructs able to manage all the refactoring actions that can be operated on models conforming to RBML and can be grouped as add, delete, change, and keep-as-is actions (see Section 2). By exploiting a “once-defined” higher-order transformation (HOT) M M DIF F 2Dif f Application, it is possible to automatically generate the Dif f Application transformation. Recall that the latter is able to concretely refactor a (Role-Annotated) Software Model by means of a set of refactoring actions represented by Dif f M odelj (APi ) and induced by the (SRMj (APi ), T RMj (APi )) pair. In this paper, Dif f M odelj (APi ) difference models are manually defined, but we might adopt model comparison techniques [13] in order to automatically generate them, as similarly done in [5, 19]. In the remaining of this section, the implementation of our approach7 is detailed. It uses EMF 8 as modeling platform, and ATL9 as model transformation language. 3.1

RBML difference model

The M M 2M M DIF F transformation is based on the metamodel-independent approach for differences representation proposed in [6]. In particular, for each metaclass MC of the RBML metamodel, the metaclasses AddedMC, DeletedMC and ChangedMC are added in the generated difference metamodel to enable the representation of additions, deletions, and changes, respectively. For instance, the metaclass GenericSwEntityInstance of RBML induces the generation of the AddedGenericSwEntityInstance, DeletedGenericSwEntityInstance, and ChangedGenericSwEntityInstance metaclasses. As better explained later in the paper, in order to represent additions, deletions, and changes of structural features (in the elements of the considered software model), RBMLDIFF contains also the metaclasses AddedFeature, DeletedFeature, and ChangedFeature, respectively. Figure 4 shows an excerpt of the difference model for the (SRM1 (EST ), T RM1 (EST )) pair of the EST antipattern discussed in the previous section. The model represents i) the addition of new LocalFacade and RemoteFacade roles and ii) changes of the GenericSwEntityInstanceDeployNode element. On the righthand side of the figure, some properties have been represented. In particular, the metaclass ChangedGenericSwEntityInstanceDeployNode represents the changes which have been operated on the ProcessNode (see the base attribute) where the 6

7 8 9

Note that Software Models are “Role-annotated” because we need to properly assign roles to their elements to reflect the refactoring defined by the (SRMj (APi ), T RMj (APi )) pair. http://www.di.univaq.it/cortelle/docs/ModelRefactoring.rar http://www.eclipse.org/modeling/emf/ http://www.eclipse.org/atl/

Model Differencing for Automated Performance-Driven Software Models Refactoring

7

Fig. 4. Sample difference model

GenericSwEntityInstance is deployed. In particular, the RemoteFacade element is deployed on it. In fact, according to the properties shown on the right-hand side of the figure, the deploy feature of ChangedGenericSwEntityInstanceDeployNode is changed (see the ChangedFeature element named deploy, which refers to the updated deploy feature whose type is AddedRemoteFacade). 3.2

Applying differences for model refactoring

A fragment of the ATL implementation of the Dif f Application model transformation is shown in Listing 1.1. The transformation implements the rules for applying on the source software model (referred by softwareModel in the code) the additions, deletions, and changes specified in the difference model (referred by delta in the code). In particular, for each metaclass MC of RBML, the following rules are provided: – AddedMC: it manages the difference model elements that conform to the AddedMC metaclass of RBMLDIFF. For each element, the rule creates a new element conforming to the metaclass of the SML+ metamodel referred by the feature base of the considered AddedMC role. For instance, lines 3-15 of Listing 1.1 are related to the management of AddedRemoteFacade elements. For each of them, a corresponding SoftwareEntityInstance element is created. By considering the difference model in Figure 4, the rule is applied on the represented added RemoteFacade having SoftwareEntityInstance as base element; – ChangedMC: according to the modifications specified in the difference model by means of instances of the metaclass ChangedMC, the rule generates refactored elements of the SML+ metamodel that play the MC role. For instance, lines 1629 of Listing 1.1 contain the transformation rule managing the ChangedGenericSwEntityInstanceDeployNodes. For each of them a target ProcessNode element is generated, and to set the changed structural features, dedicated helpers are exploited. In particular, to specify the value of the reference deploy for referring to the node where the changed process node is deployed the getChanged deploy helper is used (see lines 23 and 31-35). By considering the changed process node the helper retrieves all the deploy elements that have kept unchanged

8

D. Arcelli, V. Cortellessa, D. Di Ruscio

and those that have been added (e.g., see the software entity instance role named RemoteFacade represented in Figure 4); Concerning the management of deleted role elements (i.e., instances of the metaclass DeletedMC of RBMLDIFF), no rules are provided for them, because they do not contribute to the generation of any target model element. Contrariwise, additional rules are provided to manage the unchanged elements of the source software model. In this respect, for each metaclass MC in the SML+ metamodel a corresponding CopyMC rule is generated. Such rule copies the unmodified model elements playing the MC role. Listing 1.1. Fragment of the DiffApplication ATL transformation 1 module deltaApplication; 2 create refSwModel : SML from swModel : SML, srm : RBML, delta : RBMLDIFF; 3 rule AddedRemoteFacade { 4 from 5 s: ROLEPROFILEDIFF!AddedRemoteFacade ( 6 s.base.oclIsTypeOf(’SML!SoftwareEntityInstance’)) 7 to 8 t : SML!SoftwareEntityInstance ( 9 name first().modelElements first().updatedFeature.type->collect(e|thisModule.resolveTemp(e ,’t’)));

A higher-order transformation M M DIF F 2Dif f Application has been defined to generate the Dif f Application transformation.

4

Application example

In this section we present a case study in the e-commerce domain as an application example of our approach. We first describe the (Performance-Annotated) Software Model of the E-Commerce System (ECS), on which the process in Figure 1 is stepwise applied. Finally, the obtained numerical results are discussed. ECS is a web-based system that manages business data related to generic products. Among all provided services, we focus in this paper on the customer registration scenario, namely Register service (see [2] for a complete figure of ECS).

Model Differencing for Automated Performance-Driven Software Models Refactoring

9

A performance requirement has been defined on the average response time of Register: it has to be completed in 1.4 seconds under workloads of 1, 100 and 200 users. The performance analysis has been conducted by transforming the software model into a Queueing Network (QN) model [9], and by solving the latter with JMT [4]. Table 1. Response times of the Register service. Number of users RT(Register)