Performance Analysis and Characterization Tool for Distributed Software Development

(1)

International Journal of Research and Reviews in Computer Science (IJRRCS) Vol. 2, No. 3, June 2011

Performance Analysis and Characterization Tool for

Distributed Software Development

Reheb A. El-kaedy

1

and Ahmed Sameh

2

1_{The American University in Cairo,}2_{Prince Sultan University}

AUC Avenue, P.O.Box 74, P.O.Box 66833 New Cairo 11835, Riyadh 11586 [email protected]

Abstract: Software Performance Engineering encompasses efforts to describe and improve performance, with two distinct approaches: an early-cycle predictive model based approach, and a late-cycle measurement-based approach. The importance of integrating performance considerations into the early stages of the software development process triggers a need to bridge the gap between the fields of software engineering and performance analysis. Failure to detect performance pitfalls in a system at its earliest stages of development could turn up very costly, especially with complex and performance critical systems. Performance engineering strategies and analysis techniques could be used at the design time of the system to avoid such cost. The proposed Integrated Model-based Performance Analysis and Characterization Tool developed attempts to combine already existing standards and proposed frameworks into an automated unified easy-to-use tool. The tool aims to empower the software engineering process and make performance engineering an integral part of the software development cycle.

Keywords: Software performance engineering, UML, MARTE profile, performance analysis, MDA, model-to-model transformation, QVT relations, LQN

1. Introduction

Software performance is such pervasive quality that is difficult to understand, because it is affected by every aspect of the design, code, and execution environment. By conventional wisdom; performance is a serious problem in a significant fraction of projects. It causes delays, cost overruns, failures on deployment, and even abandonment of projects, but such failures are seldom documented.

There are two general approaches found in literature both under the Software Performance Engineering umbrella. The commonest approach is purely measurement-based; it applies testing, diagnosis and tuning late in the development cycle, when the system underdevelopment can be run and measured. The model-based approach, creates performance models early in the development cycle and uses quantitative results from these models to adjust the architecture and design with the purpose of meeting performance requirements. Research in the field of software performance engineering addresses the importance of integrating performance considerations into the early stages of the software development process. Delaying such considerations to later stages of the process with a “fix-it-later” approach has often proven to be costly and unwisely, especially with complex software systems and performance critical parallel/distributed applications.

Several efforts have been made to come up with modeling standards and common frameworks that would concurrently satisfy the requirements of both software engineers and performance experts. Many have proposed systematic transformations of software models to common performance models that already have good tool support and well-developed evaluation techniques like Stochastic Process Algebra (SPA), Stochastic Petri-Net (SPN) and Queuing Networks with their different extended forms including Layered Queuing Networks (LQN) [21]. Some also proposed the use of an intermediate performance model like the Core Scenario Model where relevant information is extracted from the software model and represented in a generic performance representation independent of the performance formalism to be used [17][18]. This intermediate model is then transformed into the target performance model for evaluation and analysis. Performance models describe how system operations use resources, and how resource contention affects operations. The types of models used for software, including queueing networks, layered queues, and types of Petri Nets and Stochastic Process Algebras, were surveyed recently by Balsamo et al [7]. The special capability of a model is prediction of properties of a system before it is built, or the effect of a change before it is carried out. This gives a special “early warning” role to early-cycle modeling during requirements analysis. However as implementation proceeds, better models can be created by other means, and may have additional uses, in particular: design of performance tests, configuration of products for delivery, and evaluation of planned evolutions of the design, recognizing that no system is ever final.

Considering that UML is gaining more consensus as the de facto modeling framework used by most software engineers, more emphasis has been given to transforming UML system models into their corresponding performance models. The Object Management Group (OMG) [10] leads the process of developing standard UML profiles for annotating UML models with performance information. The profile of Schedulability, Performance and Time (SPT) was the first OMG profile for real-time systems adopted in 2005 [15]. It uses tagged-values to annotate UML 1.4 models with the required performance attributes. The OMG profile for Modeling and Analysis of Real Time and Embedded systems (MARTE) then came to replace the SPT profile [11][14]. The MARTE profile supports UML 2.0 and provides more

(2)

International Journal of Research and Reviews in Computer Science (IJRRCS) Vol. 2, No. 3, June 2011 flexibility in defining performance values using the Value

Specification Language (VSL).

OMG also advocates the use of the Meta Object Facility 2.0 Query, View, and Transformation (QVT) specification [12] as a standard for model transformation in line with its vision of Model Driven Architecture (MDA) [13]. QVT provides hybrid declarative/imperative model transformation languages used to methodologically describe the transformational mapping between a source and target meta-models. Recently there has been significant progress in the availability of tools supporting the editing, compilation and execution of QVT transformations at its different levels of language abstractions, namely the core, relational and operational mappings languages [9][22].

Our Integrated Model-based Performance Analysis and Characterization Tool (IMPACT) attempts to integrate these standardization efforts into a unified early software performance evaluation platform. The performance information provided through the MARTE annotations of the UML model are transformed using standard QVT transformations into an equivalent performance model for evaluation and analysis. The model is then analyzed using an existing performance model solver and the results are reported back to the designers of the system.

In the rest of the paper, we present the structure of the IMPACT system and the tools used for its different components. Section 2 gives a general overview of the system. Section 3 discusses the OMG MARTE profile and the Papyrus modeling tool used as the development environment [16]. Section 4 deals with the QVT model transformation language and the mediniQVT tool used for its implementation [9]. Section 5 discusses the performance model generatedand the solver used for its analysis [8]. In the end, we discuss the integration platform of our system and summarize possibilities for future enhancements.

2. IMPACT System Overview

Figure 1 presents the general architecture of IMPACT in accordance with the model analysis framework presented in the MARTE profile specification [14].

The Papyrus modeling tool [16] is used to produce a MARTE annotated UML model of the system being designed. The relational QVT implementation of mediniQVT [9] is then used to execute a relational model-to-model transformation to generate an equivalent LQN model for the system. A relational QVT implementation has been used to allow for the bi-directional transformation between the source and target models. The reverse transformation is necessary for integrating the performance results back into the UML model and implementing the reverse feedback path.

A Layered Queuing Model is used as the performance model as it provides layers to capture contention for both hardware and software resources [1][7]. LQN Model analysis scales well with complex large systems as it is based on mean-value analysis unlike SPAs and SPNs that are based on stochastic discrete-state analysis. A direct transformation to an LQN performance model is used to avoid a double transformation through an intermediate performance model at this stage. This might however be a good option to consider in the future for system generality and tool interoperability. The LQN model generated could then be analyzed using existing LQN solvers. We use the LQNS solver of [8] as an illustration to produce the analysis results.

3. MARTE Profile and the PAPYRUS Modeling

Tool

The UML profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE) extends the UML meta-model with the capability to annotate meta-models with information required to perform model-based analysis and quantitative predictions of system properties [14]. The profile, as illustrated in Figure 2, consists of foundation modules that provide the basic elements for describing time, non-functional properties, and the use of resources. The design modules refine these foundations to model the features of real-time and embedded systems, and the analysis modules utilize them to define the information needed for model- based analysis of system properties. The Generic Quantitative Analysis Modeling (GQAM) part provides a general analysis framework to support the analysis of generic system properties.

The Schedulability Analysis Modeling (SAM) and Performance Analysis Modeling (PAM) components are specialized analysis sub-profiles that provide particular support for the analysis of schedulability and performance aspects of systems.

Performance properties that could be represented in MARTE include five types of quantities: time durations (including forced durations like a user think time), occurrence frequencies, probabilities, repetitions and data sizes. The Figure 1. MARTE Profile Architecture

(3)

International Journal of Research and Reviews in Computer Science (IJRRCS) Vol. 2, No. 3, June 2011 performance analysis typically yields information like the

average response time of components or systems, mean throughput capacity, resource utilization or probabilities of missing delay targets. Some properties may be considered as “input” properties required for carrying out the analysis of the model, and some properties could be used as “output” properties that are produced by the analysis.

Figure 3. MARTE annotated UML diagram for a simple web application

Figure 3 presents a sample UML model of a simple web application annotated with performance information using MARTE (as provided in the MARTE specification document [14]). It illustrate the basic features of the profile including open arrival rates, average processor demands, operation repetitions, multithreaded processes and communication overheads on the processing nodes.

IMPACT uses the information provided through the MARTE Performance Analysis Modeling framework to build the performance model of the system and analyze it. It transforms the performance properties defined by PAM into their corresponding performance features in the equivalent LQN model.

Our system is based on the implementation of the MARTE profile provided by the Papyrus software modeling tool [16]. Papyrus is an open source tool for UML 2 modeling provided by the French Commission of Atomic Energy - Lab of applied research on software-intensive technologies [5]. It is based on the Eclipse environment and follows the Eclipse Modeling Framework for model representations [4].

4. QVT Transformation and the MEDINIQVT

Tool

OMG’s Meta Object Facility 2.0 Query/View/Transformation (QVT) specificationprovides a standard for expressing model transformations defined precisely in terms of the relationship between a source and a target meta-model [12]. It realizes the Model Driven Architecture (MDA) vision to treat models as the primary artifacts of software development.

QVT provides transformation syntax at various language levels. The Core and Relations languages are declarative

languages that explicitly define the relationship between the source and target meta-models. The Relations semantics is a higher level language that could be transformed into the simpler, more basic Core transformation semantics.

QVT also provides imperative transformation formalisms that explicitly define transformation actions from source to target meta-models. These could either be defined through black-box transformation implementations or through the QVT standard Operational Mapping language.

MediniQVT is a tool provided by ikv++ technologies, Germany to implement OMG’s QVT Relations specification [9]. It provides an interactive environment to support the development, debugging and execution of QVT Relational transformations. It is also provided as an Eclipse plug-in based on the Eclipse Modeling Framework (EMF). Its trace management option enables incremental model updates and maintains the operation efficiency of model retransformations during the UML model development. The bidirectional nature of the relational transformation allows for the reverse transformation required to integrate the performance results back into the UML model.

Figure 4 illustrates sample QVT relational transformations that map the web application model of section 3 into its equivalent LQN model

5. LQN Performance Model

The Layered Queuing Network is an extended form of Queuing Networks that captures contention for both software and hardware resources in a layered interconnection topology [1][7]. An LQN model contains processors representing actual processors of the system or other logical resources that only accept requests from other servers and clients. Resources including software processes and hardware devices are represented as tasks with entries to accept synchronous or asynchronous requests. Activities are used to represent more sophisticated call sequences in non-sequential execution scenarios.

Figure 5 shows the Layered Queuing model of the web application model presented in section 3. Once the LQN model of the system is produced by the QVT transformation process, an LQN solver could be used to evaluate the model and generate the required performance indicators. To demonstrate the operation of IMPACT, we use the LQNS solver of [8] to analyze the model generated. The performance results produced should then be parsed and integrated back into the UML design to provide the system designer with the required performance feedback information.

LQNS is developed at Carleton University, Canada by the Real-Time and Distributed Systems Group (RADS) [20]. The tool includes both an analytic LQN mean-value solver and an LQN simulator. IMPACT uses the analytic version of the solver, providing it with the generated LQN model as input to generate performance information as illustrated in Figure 6.

(4)

6. Previous Work

In surveying different approaches and methodologies concerning the derivation of performance models from software architecture specification, we consider the generality of the methodologies and we point out whether they introduce architectural constraints or special assumptions on the software system. Each approach is based on a certain type of performance model and specification language. The latter include specification formalisms such as process algebras, Petri nets and Chemical abstract machine, and UML based specification. Performance models include queueing networks (QN) and their extensions called Extended Queueing Networks (EQN) and Layered Queueing Networks (LQN), Stochastic Timed Petri nets (STPN), Stochastic Process Algebras (SPA) and simulation models.

Some of the proposed methods are based on the Software Performance Engineering (SPE) methodology introduced by Smith in her pioneer work [15]. It has been the first comprehensive approach to the integration of performance analysis into the software development process, from the earliest stages to the end. The SPE methodology is based on two models: the software execution model and the system

execution model. The former is based on execution graphs

(EG) and represents the software execution behavior, the latter is based on queueing network models and represents the computer system platform, including hardware and software components. The analysis of the software model gives information concerning the resource requirements of the software system. The obtained results, together with information about the hardware devices, are the input parameters of the system execution model, which represents the model of the whole software/hardware system.

We review some approaches that propose a general methodology for deriving performance models from software architecture specifications. These methods refer to different specification languages and performance models and they consider the combination of different tools and environments for system performance evaluation.

Authors in [12] apply the SPE methodology to evaluate the performance characteristics of a software architecture. The emphasis is in the construction and analysis of the software execution model, which is considered the target model of the specified SA and is obtained from the Sequence diagrams. The Class and Deployment diagrams contribute to complete the description of the SA, but are not involved in the transformation process. The SPE process requires additional information that includes software resource requirements for processing steps and computer configuration data.

In [13], authors present a methodology to derive QN performance models from SA specification. It has been developed and used by the authors in a design of client/server applications. The methodology is based on CLISSPE (CLIent/Server Software Performance Evaluation), a language for the software performance engineering of client/server applications. Although the methodology does not explicitly use UML, the functional requirements of the system are specified in terms of use cases, and the system model is specified by the analogous of a Class diagram. The use cases,

together with the client/server SA specification and the mapping associating software components to hardware devices, are used to develop a CLISSPE program specification. The CLISSPE system provides a compiler that generates a corresponding QN model. By considering specific scenarios one can define the QN parameters and apply appropriate solution methods, such as the Layered Queuing Models (LQN) to obtain performance results.

In [17] authors provide a method for the automatic derivation of a queuing network model from a SA specification, described using the CHAM formalism (CHemical Abstract Machine). Informally, the CHAM specification of a SA [16] is given by a set of molecules which represent the static components of the architecture, a set of reaction rules which describe the dynamic evolution of the system through reaction steps, and an initial solution which describes the initial static configuration of the system. The paper presents an algorithm to derive a QN model from the CHAM specification of a SA architecture. It is based on the analysis of the Labeled Transition System (LTS) that represents the dynamic behavior of the CHAM architecture, and that can be automatically derived from the CHAM specification. The algorithm does not completely define the QN model whose parameters, such as the service time distributions and the customer's arrival processes, have to be specified by the designer. The solution of the QN model is derived by analytical methods or possibly by symbolic evaluation. Parameter instantiation identify potential implementation scenarios and the performance results allow to provide insights on how to carry on the development process in order to satisfy given performance criteria.

In [19] authors propose a methodology making a joint use of information from different UML diagrams to generate a performance model of the specified system. The paper refers to SPE methodology and specifies the software architecture by using Deployment, Sequence, and Use Case diagrams. This approach is a more formal extension of the WS approach and consists of the following steps:

1. Enrich the Use Case diagram (UCD) by assigning a probability to every edge that links a type of user to a use case, so that such probability applies to the execution of the corresponding set of Sequence diagrams. This leads to the definition of the workload of the performance model.

2. For each Use Case in the UCD, process the corresponding set of Sequence diagrams to obtain the meta-EG (execution graph). The algorithm incrementally builds the EG by processing in turn all the Sequence diagrams and building, for each one, the part of the EG it contributes to. It considers only Sequence diagrams without noreply and asynchronous interactions.

3. Use the Deployment Diagram both to obtain the EQN model of the hardware platform and to appropriately tailor the

meta-EG so obtaining an EG-instance that defines the

workload of the EQN. In this step, the basic idea is to enrich the Deployment Diagram, that shows the topology of the platform and the type of sites, with the information needed to build the EQN, such as the internal structure and parameters of devices. Moreover the EG-instance defines the type of communication and the size of data exchanged. The paper

(5)

International Journal of Research and Reviews in Computer Science (IJRRCS) Vol. 2, No. 3, June 2011 does not present the details of the EQN construction from the

Deployment diagram.

4. Assign numerical parameters, defined by the designer, to the EG-instance.

5. Combine EG-instance and EQNM to solve the obtained performance model by using the SPE approach. Note that a key point of the methodology is adding the information concerning performance evaluation to the considered UML diagrams, and to the obtained EQN model. The methodology is not yet implemented in a tool.

Authors in [21] propose an approach to automatically generate queuing network models from software architecture specifications described by means of Message Sequence Charts (MSC), that correspond to Sequence diagrams in the UML terminology. The idea is to analyze MSCs in terms of the trace languages (sequences of events) they generate, in order to single out the real degree of parallelism among components and their dynamic dependencies. This information is then used to build a QN model corresponding to the software architecture description. The authors present an algorithm to perform this step.

The approach proposed by authors in [22] concerns the derivation of QN models from Labeled Transition Systems (LTS) describing the dynamic behavior of SAs. Starting from a LTS description of a SA makes it possible to abstract from any particular SA specification language. The approach assumes that LTSs are the only knowledge on the system that they can use. This means, in particular, that it does not use any information concerning the system implementation or deployment. This approach is an extension of [22], considering a finite state representation independent of a specific architectural description language and modeling more complex interaction patterns and synchronization constraints that can be represented by extended QN. Such EQN models the software concurrent execution and component interaction at the SA design level.

Authors in [17] propose an architectural description language based on stochastically timed Process Algebras. This approach provides an integration of a formal specification language and performance models. The aim is to describe and analyze both functional and performance properties of SAs in a formal framework. The approach proposes the adoption of an architectural description language called EMPA, gives its syntax with a graphical and textual notation and its semantics in terms of EMPA specifications, that is a stochastically timed process algebra. The authors illustrate various functional and non-functional properties, including performance evaluation which is based on the generation of the underlying Markov chain that is numerically solved. To this aim the authors propose the use of TwoTowers [17], a software tool for systems modeling and analysis of functional and performance properties, that support system EMPA description.

In [18] authors investigate the design and performance modeling of component interconnection patterns for client/server systems. Such patterns define and encapsulate the way client and server components of software architecture communicate with each other via connectors. The idea is to start with UML design models of component interconnection patterns, using Class diagrams (to model their static aspects)

and Collaboration diagrams (to depict the dynamic interactions between components and connectors objects – instances of the classes depicted on the Class diagrams). Such models are then provided with additional performance annotations, and translated into an XML notation, in order to capture both the architecture and performance parameters in one notation. The performance models of the considered patterns are extended QN and their definition, based on previous work of the authors, depends on the type of communication. The EQN model solution is obtained by Markov chain analysis or approximate analytical methods. In [19] authors consider a significant set of architectural patterns (pipe and filters, client/server, broker, layers, critical section and master-slave) specified by using UML-Collaborations that are combined Class and Sequence diagrams showing explicitly the collaborating objects. The approach shows the corresponding performance models based on LQN models. Moreover, they propose a systematic approach to build performance models of complex SAs based on combinations of the considered patterns. The approach follows the SPE methodology and generates the software and system execution models by applying graph transformation techniques. SAs are specified using UML-Collaborations, Deployment and Use Case diagrams. The Sequence diagram part of the UML-Collaboration is used to obtain the software execution model (which is represented as a UML Activity diagram); the Class part is used to obtain the system execution model (which is represented as a LQN model). Use Case diagrams provide information on the workloads, and Deployment diagrams allow for the allocation of software components to hardware sites.

The approach proposed by authors in [20] presents a simulation framework named Simulation Modeling Language (SimML) to generate a simulation program from the system design specified with the UML. The proposed UML tool allows the user to draw Class and Sequence diagrams and to specify the information needed for the automatic generation of the process oriented simulation model. The simulation program is generated in the Java programming language. The approach proposes an XML translation of the specified UML models, in order to store the information about the design and the simulation data in a structured way.

The approach proposed by authors in [21] focus on real time systems, and proposes extensions of UML diagrams to express temporal requirements and resource usage. The extension is based on the use of stereotypes, tagged values and stereotyped constraints. SAs are specified using the extended UML diagrams without restrictions on the type of diagrams to be used. Then these UML diagram are used as input for the automatic generation of the corresponding simulation models in OPNET. They also define a middleware model for scheduling analysis. The simulation model is defined by instantiating with the application information the generic models that represent the various UML metaclasses. The approach generates submodels for each application element and combines them into a unique simulation model of the UML application. The approach provides also a feedback mechanism: after the model has been analyzed and simulated,

(6)

International Journal of Research and Reviews in Computer Science (IJRRCS) Vol. 2, No. 3, June 2011 some results are included in the tagged values. This constitutes

a relevant feature, which ease the SA designer in obtaining feedback from the performance evaluation results.

7. Future Difficulties

The abstractions provided by performance models are valuable, but some way must be found to create the models more easily and more quickly. For performance models made early in the lifecycle from specified scenarios, automated model-building has been demonstrated and is supported by the UML profiles. The future challenge is to handle every scenario that a software engineer may need to describe, and every way that engineer can express them (including the implied scenario behavior of object call hierarchies, and the composition of models from component designs). The multiplicity of model formats hinders tool development, and would be aided by standards for performance model representations. Interoperability of performance building tools with standard UML tools is also helpful. For instance, the PUMA architecture[20] shown in Figure 7 supports the generation of different kinds of performance models (queueing networks, layered queueing networks, Petri nets, etc.) from different versions of UML (e.g., 1.4 and 2.0) and different behavioral representations (sequence and activity diagrams). PUMA also provides a feedback path for design analysis and optimization. Mid and late-cycle performance models should be extracted from prototypes and implementations. Trace-based automated modeling has been described in [20][21], including calibrated CPU demands for operations [22]. Future research can enhance this with use of additional instrumentation (e.g. CPU demands, code context), efficient processing, and perhaps exploit different levels of abstraction. Abstraction from traces exploits certain patterns in the trace, and domain-based assumptions; these can be extended in future research.

A prime goal of future work is automatic performance optimization of architecture, design and run-time configuration. We see optimization as an extension of tuning, to include more fundamental changes to the system.

A first approach uses methods, not yet well worked out, to optimize design decisions represented in performance models. Manual search within this approach is described in [22] and [20]. An evolutionary approach could apply automated search techniques to models derived from the specification, with results fed back into the UML. Alternatively the search could be carried out on the UML design, with evaluation by models. The design can be parameterized, so optimization can be applied to the parameter values. A second constructive

approach is to begin from the requirements in the form of scenarios, and proceed to optimally cluster operations and data into objects and concurrent processes, also selecting communications patterns subject to various constraints (such as mutual exclusion). Both approaches can be adapted to re-use of component and platform services with known properties, applying optimization to the transformation steps which add these features. In both cases also there are design decisions (such as storage mapping) that are below the level of

abstraction in the model, which will perhaps be evaluated and optimized by running small measurement experiments on prototypes, or by applying general rules based on the context. Both approaches also require some way to provide defaults for the configuration decisions discussed next, since performance can only be evaluated for a complete system. Configuration decisions are applied at load and run time to adapt the software to its workload, platform and environment. Examples of decisions needing optimization include replication levels of servers and data [15], allocation of distributed processes to processors [12], to priorities [15]. Further candidates include buffer and thread pools [13], middleware parameters [20], and virtual machine parameters. The future is expected to include systematic and efficient optimization approaches covering all these problems. For complex products, optimization problems yet to be solved include selection of alternative components from a product line, and selection of their configuration parameters and installation parameters. In [10] is presented an experimental methodology to evaluate the statistical significance of configurable parameters in e-commerce systems. Measurements are used to identify key configuration parameters that have a strong impact on performance, which are ranked in order of relevance. The impact of various parameters on the types of requests submitted to the site is also analyzed. A different experimental approach to detect performance degradation in software systems with large configuration spaces is proposed in [14]. Formally designed experiments, called screeningdesigns, are run with the goal of identifying important performance effects caused by the simultaneous interaction of n configuration parameters (n = 1,2,...). The conclusion was that screening designs can correctly identify important options used to produce reliable performance estimates across the entire configuration space, at a fraction of the cost of exhaustive testing. In general, such experimental methods require a lot of computing power, so heuristics may be necessary to select the most promising experiments.

Agile Programming is becoming a mainstream approach to development, in which very frequent releases are made with small increments in function. Ancillary documents tend to be ignored, to concentrate on code. Quality control in agile programming is a current issue, for instance the role of test cases, and performance engineering fits into this concern. Performance specifications may not even be known for each incremental release. Given the importance of performance to final products, a way must be found to do SPE in agile development, as discussed in [11]. This can be through test procedures or through models based on suitable design documents (e.g. based on Agile Modeling, e.g. [14]), or on test executions. A Performance Knowledge Base may be well-adapted to agile development, because it can be driven from the code (through tests and automatically generated models) and it accumulates history that is useful.

Design for Evaluation, Predictability and Adaptation: Progress can be expected in software design ideas that make it easier to evaluate and manage performance, something like design for testability. A framework called PACC, Predictive Assembly from Certifiable Components [17], addresses the predictability of properties (including performance) of systems built from

(7)

International Journal of Research and Reviews in Computer Science (IJRRCS) Vol. 2, No. 3, June 2011 components, applied to real-time system assembly. It shows

that some properties of some kinds of components can be predicted with certainty. This is a question with wide practical resonance. Adaptive or autonomic systems make performance engineering decisions on the fly, by optimizing the configuration of a running system. Software design for adaptation must include reflective capabilities to monitor its performance, strategies for adaptation, and handles on the system for effecting the necessary changes. Design considerations in adaptive computing are considered in [12]. Some strategies for adaptation are based on simple rules and simply modify provisioning of processors, but others use performance models as a basis for decisions [1]. Since the system may be changing, the use of models and tracking of model parameters for autonomic control was addressed in [11]. These models can be derived during development. Integration with other evaluations: Other “nonfunctional” properties of software systems may also be evaluated from design documents, and it is natural to look ahead to integrating them with performance evaluation. For example security mechanisms often have a heavy performance penalty, and a joint evaluation would support a tradeoff between security effectiveness and performance cost. Reliability/availability concerns have long been integrated with performance analysis in “performability” modeling (e.g. [22]), for similar reasons. Ensuring system performance over the life of the software brings in concerns which are usually thought of as capacity planning, deployment or configuration, and management. The boundaries are not sharp, for instance capacity planning affects requirements for the software, and configuration must be considered in evaluation as described just above. Scalability: this is a complex issue that rests heavily on performance limitations and bottlenecks. Research into scalable design approaches and patterns would be fruitful for the field.

8. Conclusion

IMPACT is a performance plug-in that makes use of the modeling capabilities of the Papyrus tool and the relational QVT model transformation implementation of mediniQVT to produce an LQN performance model of a MARTE annotated UML design. The tool is based on the Eclipse environment and Eclipce Modeling Framework. The LQN model produced is in XML format suitable for input to the LQNS analytical model solver, which in turn generates the performance information required. The major challenge is to develop a comprehensive and robust set of transformation rules that makes use of the performance information provided through the stereotypes of the Performance Analysis sub-profile of MARTE.

As a future step, the IMPACT tool can be further enhanced to make use of advanced features provided by MARTE like performance analysis contexts with varying workload distributions or resource platforms. The tool has been tested on a reasonable power development station on small size simple case models. In order to validate its operation, the tool is still to be tested on more complex case studies to evaluate

the performance information produced. More work also needs to be done in the area of results feedback. Reverse relational QVT transformations need to be executed to integrate the generated performance information back where they belong on the UML design and provide the user with more detailed feedback about the system’s performance profile.

9. References

[1]

C.M. Woodside, Tutorial Introduction to Layered Modeling of Software Performance - Edition 3.0, Department of Systems and Computer Engineering, Carleton University, Ottawa (Canada), May 2002.

[2]

Cortellessa, V., Di Marco, A., and Inverardi, P. 2006. Software performance model-driven architecture. In Proceedings of the 2006 ACM Symposium on Applied Computing (Dijon, France, April 23 - 27, 2006). SAC '06. ACM, New York, NY, 1218-1223. DOI=

http://doi.acm.org/10.1145/1141277.1141565

[3]

D’Ambrogio A.: A Model Transformation Framework for the Automated Building of Performance Models from UML Models. In Proceeding of ACM Workshop on Software and Performance. (2005)

[4]

Eclipse Modeling Framework (EMF) Project: http://www.eclipse.org/modeling/emf/

[5]

The French Commission of Atomic Energy - Lab of applied research on software-intensive technologies. http://www-list.cea.fr/

[6]

Gu, G. P. and Petriu, D. C. 2002. XSLT transformation from UML models to LQN performance models. In

Proceedings of the 3rd international Workshop on Software and Performance (Rome, Italy, July 24 - 26, 2002). WOSP '02. ACM, New York, NY, 227-234. DOI=

http://doi.acm.org/10.1145/584369.584402

[7]

J.A. Rolia, K.C. Sevcik, The Method of Layers, IEEE Transactions on Software Engineering, 21(8):689-700, August 1995.

[8]

The Layered Queuing Network Solver software package. RADS research group, Carleton University, Ottawa (Canada). http://www.sce.carleton.ca/rads/lqns/

[9]

The medini QVT tool official website: http://projects.ikv.de/qvt/

[10]

Object Management Group (OMG): http://www.omg.org/

[11]

The official OMG MARTE website: www.omgmarte.org

[12]

OMG. Meta Object Facility (MOF) 2.0

Query/View/Transformation (QVT).Version 1.0, formal/08-04-03, April 2008.

[13]

OMG. Model Driven Architecture guide. Version 1.0.1, omg/03-06-01, June 2003.

(8)

International Journal of Research and Reviews in Computer Science (IJRRCS) Vol. 2, No. 3, June 2011 [14]

OMG. UML Profile for Modeling and Analysis of

Real-time and Embedded Systems (MARTE). Version 1.0 Beta2, formal/08-06-08, June 2008.

[15]

OMG. UML Profile for Schedulability,

Performance, and Time Specification. Version 1.0, formal/03-09-01, September 2003.

[16]

Papyrus UML – open source tool for graphical UML2 modeling: www.papyrusuml.org

[17]

Petriu D.., Woodside M: A Metamodel for Generating Performance Models from UML Designs, Proc. of UML Conference, LNCS 3273, pp 41-53. (2004)

[18]

Petriu D.., Woodside M: An intermediate metamodel with scenarios and resources for generating performance models from UML designs

[19]

Ramrao, W.: Transformation of uml design model into performance model: A model driven framework. In ECOOP Student Workshop (2006)

[20]

Real-Time and Distributed Systems Group, Department of Systems and Computer Engineering, Carleton University, Ottawa (Canada). http://www.sce.carleton.ca/rads/

[21]

Simonetta Balsamo, Antinisca Di Marco, Paola Inverardi, Marta Simeoni, "Model-Based Performance

Prediction in Software Development: A Survey," IEEE Transactions on Software Engineering, vol. 30, no. 5, pp. 295-310, May, 2004.

[22]

SmartQVT - An open source model transformation tool implementing the MOF 2.0 QVT-Operational language. http://smartqvt.elibel.tm.fr/

Figure 2. IMPACT System Architecture

Figure 4. QVT Operational transformation

(9)

International Journal of Research and Reviews in Computer Science (IJRRCS) Vol. 2, No. 3, June 2011 Webthreads

Webserver

AppHost database DBHost [dbthreads]

htmlReq 4.5 ms

dbReq 12.4 ms

Arrivals at 58.8/sec

(1.3)

Figure 5. Equivalent Layered Queuing model

Generated by lqns, version 3.10

Copyright the Real-Time and Distributed Systems Group,

Department of Systems and Computer Engineering

Carleton University, Ottawa, Ontario, Canada. K1S 5B6

Convergence test value: 6.49181e-006

Number of iterations: 5

MVA solver information:

Submdl n k srv step() mean stddev wait() mean stddev

1 5 1 1 26 5.2 0.4 272 54.4 8.8 2 9 1 2 46 5.1111 0.31427 708 78.667 10.371 3 5 1 1 26 5.2 0.4 272 54.4 8.8 Total 19 0 0 98 5.1579 0.36464 1252 65.895 15.444

Elapsed: 0:00:00.00

.

Type 1 throughput bounds:

Task Name Entry Name Throughput Users users 0.000651103 webserver htmlReq 3.06279 database dbReq 0.403226

Mean delay for a rendezvous:

Task Name Source Entry Target Entry Phase 1 Users users htmlReq 0 webserver htmlReq dbReq 0

Service times:

Task Name Entry Name Phase 1 Users users 1487.86 webserver htmlReq 26.12

(10)

database dbReq 12.4

Service time variance (per phase)

and squared coefficient of variation (over all phases):

Task Name Entry Name Phase 1 coeff of var **2

Users users 2.315e+006 1.04574 webserver htmlReq 1082.03 1.58596 database dbReq 153.76 1

Throughputs and utilizations per phase:

Task Name Entry Name Throughput Phase 1 Total

Users users 0.000672106 1 1 webserver htmlReq 0.0395198 1.03226 1.03226 database dbReq 0.0497703 0.617152 0.617152

Utilization and waiting per phase for processor: AppHost

Task Name Pri n Entry Name Utilization Ph1 wait webserver 0 80 htmlReq 0.395198 0

Utilization and waiting per phase for processor: DBHost

Task Name Pri n Entry Name Utilization Ph1 wait database 0 5 dbReq 0.617152 0