Automatic Derivation of a Product Performance Model from a Software Product Line Model

Abstract

We propose to integrate performance analysis in the early phases of the model-driven development process for Software Product Lines (SPL). We start with a multi-view UML model of the core family assets representing the commonality and variability between different products, which we call the SPL model. We add another perspective to the SPL model, annotating it with generic performance specifications expressed in the standard UML profile MARTE, recently adopted by OMG. The runtime performance of a product is affected by factors contained in the UML model of the product (derived from the SPL model), but also by external factors depending on the implementation and execution environments. The external factors not contained in the SPL model need to be eventually represented in the performance model. In order to do so, we propose to represent the variability space of different possible implementation and execution environments through a so called "performance completion (PC) feature model". These PC features are mapped to MARTE performancerelated stereotypes and attributes attached to the SPL model elements. A first model transformation realized in the Atlas Transformation Language (ATL) derives the UML model of a specific product with concrete MARTE annotations from the SPL model. A second transformation generates a Layered Queueing Network (LQN) performance model for the given product by applying an existing transformation named PUMA, developed in previous work. The proposed technique is illustrated with an e-commerce case study. A LQN model is derived for a product and the impact of different levels of secure communication channels on its performance is analyzed by using the LQN model.

Software Performance Modeling

“…Since our goal is to automate the derivation of a performance model for a specific product from the SPL model, we propose to deal with performance completions in the early phases of the SPL development process by using a Performance Completion feature (PC-feature) model as described in the previous section. The PC-feature model explicitly captures the variability in platform choices, execution environments, different types of communication realizations, and other external factors that have an impact on performance, such as different protocols for secure communication channels and represents the dependencies and relationships between them [41]. Therefore, our approach uses two feature models for a SPL: 1) a regular feature model for expressing the variability between member products, and 2) a PC-feature model introduced for performance analysis reasons to capture platform-specific variability.…”

“…The concept of "performance completions" was introduced by Woodside et al [47] to close the gap between abstract design models and external platform factors. The PC feature model, introduced in the work of the Palladio group (see [27]) and also used in [41], defines the variability in platform choices, execution environments, types of platform realizations, and other external factors that have an impact on the system's performance. Since the regular notation for feature diagrams is not part of UML, we use a UML class diagram extended with stereotypes to represent the PC feature model, where each feature is represented as a class element.…”

Requirements modeling languages for software product lines: A systematic literature review

“…[52] This evolves separately variability models when the base model is changed using concepts from CVL. [57] This allows to derive automatically a given product model from a SPL model with the goal of generating a product performance model. [96] An alternative implementation to report ill-formed product configurations, which enables the SPL analysis consisting of thousands of products.…”

Scaling Size and Parameter Spaces in Variability-Aware Software Performance Models (T)

“…For qualitative analyses, examples are featureaware model-checking algorithms [11] or behavioral equivalences [19], [37]. For quantitative properties, Tawhid and Petriu derive performance models from a UML software product line model [33], but commonalities across model instances are not exploited to provide an efficient familybased analysis. Exteberria et al consider the situation of a feature-aware software performance design in the presence of uncertainty [18].…”