Automatically Improve Software Architecture Models for

Automatically Improve Software Architecture Modelsfor Performance, Reliability, and Cost

Using Evolutionary Algorithms

Anne Martens?, Heiko Koziolek†, Steffen Becker‡, Ralf Reussner?‡?Karlsruhe Institute of Technology, Karlsruhe, Germany

Email: {martens,reussner}@ipd.uka.de†ABB Corporate Research, Ladenburg, Germany

Email: [email protected]‡FZI Karlsruhe, Karlsruhe, Germany

Email: {becker,reussner}@fzi.de

ABSTRACTQuantitative prediction of quality properties (i.e. extra-functional properties such as performance, reliability, andcost) of software architectures during design supports a sys-tematic software engineering approach. Designing architec-tures that exhibit a good trade-off between multiple qual-ity criteria is hard, because even after a functional designhas been created, many remaining degrees of freedom inthe software architecture span a large, discontinuous designspace. In current practice, software architects try to findsolutions manually, which is time-consuming, can be error-prone and can lead to suboptimal designs. We propose anautomated approach to search the design space for goodsolutions. Starting with a given initial architectural model,the approach iteratively modifies and evaluates architecturalmodels. Our approach applies a multi-criteria genetic algo-rithm to software architectures modelled with the PalladioComponent Model. It supports quantitative performance,reliability, and cost prediction and can be extended to otherquantitative quality criteria of software architectures. Wevalidate the applicability of our approach by applying it toan architecture model of a component-based business infor-mation system and analyse its quality criteria trade-offs byautomatically investigating more than 1200 alternative de-sign candidates.

Categories and Subject DescriptorsC.4 [Computer Systems Organization]: Perfor-mance of Systems—modelling techniques; D.2.8 [SoftwareEngineering]: Metrics—performance measures; D.2.11[Software Engineering]: Software Architecture

1. INTRODUCTION

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.WOSP/SIPEW 2010, San Francisco Bay Area, USACopyright 200X ACM X-XXXXX-XX-X/XX/XX ...$10.00.

One benefit of modelling software architectures is theability to quantitatively analyse extra-functional properties,such as performance or reliability, based on the softwarearchitecture model during early design stages. This ap-proach avoids cost for late life-cycle performance/reliabilityfixes and architectural redesigns. Several methods (e.g.,UML [31], SySML [32], LQN [17], Palladio [3]) allow tomodel a software architecture including static structure, dy-namic behaviour and allocation to resources. Such modelscan be annotated with estimated or measured quality anno-tations (e.g., UML MARTE [30] for performance) and anal-ysed for the different quality properties. For example, per-formance can be analysed using numerical techniques fromqueueing theory or simulation.

However, while many approaches allow to predict singlequality properties of a given design, they do not supportthe software architect if the predictions indicate a viola-tion of the requirements. For performance, the softwarearchitect needs to understand the performance predictionresults, manually identify the root cause for the insufficientperformance and manually determine an improved architec-ture model. An improved architecture model can for ex-ample contain faster / more reliable software components,a more powerful hardware environment, or a different allo-cation of components to hardware nodes. Even if require-ments are fulfilled, there might be potential for improve-ment in the software architecture to save cost by reducingover-provisioned resources. In general, improving one qual-ity property can deteriorate another, thus, quality propertiescannot be improved in isolation.

Interpretation of prediction results, problem identifica-tion, and improvement of the software architecture are man-ual tasks in current practice [35]. Automation is desirable,because the manual tasks (i) require vast architectural ex-perience, (ii) are laborious and therefore cost-intensive, and(iii) are error-prone due to the overwhelmingly complex de-sign space for human beings.

Researchers have proposed rule-based and metaheuristic-based solution approaches for the problem of automaticallyfinding architectural designs with improved performance orreliability properties. Rule-based approaches (e.g., [38, 12,33, 28] try to identify problems in the model (e.g. bottle-

necks) based on predefined rules and apply predefined solu-tions for these problems. Existing rule-based approachesonly focus on performance analysis without consideringother quality criteria. They operate on the performancemodel instead of the architectural model and are thereforedifficult to use for regular architects not familiar with perfor-mance formalisms. These approaches cannot find solutionsfor which no rule exists, thus, they cannot cover all possi-ble solutions and might result in locally optimal solutions.Metaheuristic-based approaches (e.g., [1, 8]) encode the chal-lenge of improving architectures as an optimization problemand use metaheuristic search techniques [4, 22] (e.g., geneticalgorithms, simulated annealing, etc.) to find better designmodels. Existing metaheuristic approaches do not supportperformance prediction and only study the effect on relia-bility and cost of replicating components.

In this work, we present an approach which is capable toautomatically improve a given architecture model with re-spect to performance, reliability, and cost. The approachis best suited for component-based software architectures.Components encapsulate functionality that can be indepen-dently reused, and thus component-based software architec-tures provide degrees of freedom to be exploited by our ap-proach. In particular, we model architectures with the Palla-dio Component Model (PCM) [3] in this work. Quality prop-erty prediction is done using Layered Queueing Networks(LQN) [17] (or SimuCom EQNs [3]) for performance met-rics; Markov models for reliability metrics [25]; and a newlyintroduced PCM cost extension for cost. The approach au-tomatically searches the design space starting from a giveninitial architectural model. Using existing multi-criteria evo-lutionary algorithms, it iteratively modifies and evaluates ar-chitecture models. It searches for Pareto-optimal [15] archi-tecture models with respect to performance, reliability, andcost. As metaheuristics are used, it is a best-effort approachand cannot guarantee global optimality of the results.

With our approach, software architects do not have tosearch for alternative solutions manually. Instead, they canfocus on good solutions automatically determined by our ap-proach for trade-off decisions between multiple quality cri-teria. As the approach works on the architectural modellevel (as opposed to the performance model), architects candirectly understand and use the automatically found solu-tions.

The contribution of this paper is a new approach to findarchitectural design models with optimal performance, reli-ability, and cost properties. So far, we explore four degreesof freedom (processor speed, number of servers, componentallocation, and component selection), that together are notsupported by existing approaches. The approach supportsadding of more degrees in the future. Our approach workson the architectural level and does not require knowledge onquality criteria analysis models and methods (e.g. queueingtheory knowledge for performance). We have implementedour approach in the PerOpteryx tool1. We present a casestudy for a business reporting system (12 components, 40tasks in LQN).

This paper is organized as follows. Section 2 comparesrelated approaches to our approach. Section 3 introducesa running example to explain the problem in detail as wellas the used architecture model and quality prediction tech-

1palladio-approach.net/ PerOpteryx

niques. Section 4 describes the optimisation process. Thecase study is presented in Section 5. Finally, Section 6discusses assumptions and limitations before Section 7 con-cludes.

2. RELATED WORKOur approach is based on software performance predic-

tion [34, 2], architecture-based software reliability analy-sis [18], and search-based software engineering [22]. Wecategorize closely related approaches into (i) rule-based ap-proaches and (ii) metaheuristic-based approaches.Rule-based Approaches: Xu et al. [38] present a semi-automated approach to find configuration and design im-provement on the model level. Based on a LQN model, per-formance problems (e.g., bottlenecks, long paths) are iden-tified in a first step. Then, rules containing performanceknowledge are applied to the detected problems. The ap-proach cannot detect improvement for which no rules havebeen defined, and some of the suggested improvements re-quire changing the implementation of components, which isnot desired when dealing with black box components. As theapproach suggests changes on the level of LQNs, it might notbe feasible to map suggested solutions back to the design.For example, it might be impossible to speed-up a certaincomponent implementation to reach a certain service timebecause of inherent algorithmic complexity.

McGregor et al. [28] have developed the ArchE frame-work. ArchE assists the software architect during the designto create architectures that meet quality requirements. Ithelps to create architectural models, collects requirements(in form of scenarios), collects the information needed toanalyse the quality criteria for the requirements, providesthe evaluation tools for modifiability or performance anal-ysis, and suggests improvements. Compared to our work,ArchE does not search the whole design space, but advancesstep-wise based on rules. It does not support reliability andonly features a simple performance model. The architec-ture model is not component-based, consequently, degreesof freedom as presented later in this paper cannot be readilyidentified.

Cortellessa et al. [12] propose an approach for auto-mated feedback generation for software performance anal-ysis, which aims at systematically evaluating performanceprediction results using step-wise refinement. The approachrelies on the (yet manual) detection of common performanceproblem patterns (performance anti-patterns) in the perfor-mance model. There is no support to automatically solvea detected anti-pattern, and there is no suggestion of newarchitecture candidates.

Bondarev et al. [6] introduce the DeepCompass frame-work for design space exploration of embedded systems. Theframework relies on the ROBOCOP component model. Ituses a Pareto analysis to resolve the conflicting goals of op-timal performance and low cost for different architecturecandidates. Therefore, performance metrics for each archi-tecture candidate are plotted against the cost of each can-didate. The approach requires a manual specification of allarchitecture candidates and provides no support for suggest-ing new candidates.

Parsons et al. [33] present a framework for detectingperformance anti-patterns in Java EE architectures. Themethod requires an implementation of a component-basedsystem, which can be monitored for performance proper-

ties. It uses the monitoring data to construct a performancemodel of the system and then searches for EJB-specific per-formance antipatterns in this model. This approach cannotbe used for design space exploration in early developmentstages, but only to improve existing systems.Metaheuristic-based Approaches: Aleti et al.[1] presenta generic framework to optimise architectural models withevolutionary algorithms for multiple arbitrary quality crite-ria. So far, only component deployment is considered as adegree of freedom so far, and data transmission reliabilityand communication overhead are the only presented qualitycriteria. In comparison, our approach supports four degreesof freedom at once at this time. In addition, we study trade-offs between three quality criteria (cf. Section 3). Bothapproaches are extensible for more degrees of freedom andmore quality criteria.

Canfora et al. [8] optimise service composition cost usinggenetic algorithms while satisfying SLA constraints. Ser-vices are assumed to have fixed performance metrics thatdo not change for changing composition. Only service se-lection is considered as a degree of freedom, and trade-offswith other quality criteria are not considered

Kavimandan et al. [24] presents an approach to optimisecomponent allocation in the context of distributed real-timeembedded component-based systems. They enhance pre-existing bin packing algorithms with the consideration ofcomponent consideration and deploy components togetherthat have a compatible configuration. In total, only alloca-tion is considered as a degree of freedom, but the authorsalso mention that their approach could be combined withother approaches.

Grunske et al. [19] survey more related optimisation ap-proaches with a focus on real-time embedded systems de-sign. The presented approaches evaluate reliability, real-time properties, and/or cost, and support various degrees offreedom. In contrast to our work, none of the presented ap-proaches considers the degrees of freedom of processor speed,component selection, and component allocation at the sametime.

3. BACKGROUND ANDRUNNING EXAMPLE

To quickly convey our contributed concepts to the reader,we provide a running example in the following and introducethe existing quality analyses methods our approach is basedon.

Our approach requires a (preferably component-based) ar-chitecture model with performance, reliability, and cost an-notations as input. Balsamo et al. [2] have surveyed manydifferent methods for specifying performance models. UML2extended with the MARTE profile is a popular example fora performance modelling notation. A survey on reliabilityprediction approaches is given in [18].

We have implemented our approach based on the Pal-ladio Component Model (PCM). In principle, our ap-proach could be applied to most known architectural per-formance and reliability models and analysis methods. ThePCM is beneficial for our purposes as it is specifically de-signed for component-based systems. It strictly separatesparametrized component performance models from the com-position models and resource models, and it provides con-figuration options of the models. Thus, the PCM naturally

supports many architectural degrees of freedom (e.g., sub-stituting components, changing component allocation, etc.)to be exploited by our approach. Additionally, the model-driven capabilities of the PCM allow an easy generation ofalternative architecture candidates.

Consider the minimal PCM model example in Fig. 1,which is realised using the Ecore-based PCM metamodeland visualized here in UML-like diagrams for quick compre-hension. The system model specified by the software archi-tect consists of three connected software components C1 -C3 deployed on three different hardware nodes. The soft-ware components contain cost annotations, while the hard-ware nodes contain annotations for performance (processingrates), reliability (mean time to failure (MTTF), mean timeto repair (MTTR)), and cost (fixed and variable cost in anabstract cost unit).

Server S1

Component C2

[Cost = 5 Units]

Server S2

Component C3

[Cost = 3 Units]

Server S3

Action

Resource Demand

= 4E+9 CPU Instr.

Failure Probability

= 0.0001

Call

Component 2

Call

Component 3

Processing Rate = 35E+9 Instr./Second

MTTF = 300.000 hours

MTTR = 6 hours

Cost = 12 + (1E-9 * Rate) Units



MTTR = 3 hours




MTTR = 4 hours


P=0.8

P=0.2

Action

Action

Action

Action

Component C1

[Cost = 4 Units]

<<implements>> <<implements>> <<implements>>

Resource Demand

= 3E+9 CPU Instr.

Failure Probability

= 0.0001

Resource Demand

= 2E+9 CPU Instr.

Failure Probability

= 0.0002

User Population

= 25

Think time = 5.0s

Failure Probability

= 0.0002

Resource Demand

= 3E+9 CPU Instr.

Failure Probability

= 0.0001

Resource Demand

= 4E+9 CPU Instr.

Failure Probability

= 0.0003

P=0.6P=0.4

Figure 1: Simple Example PCM Model

For each software component service, the component de-velopers provide an abstract behavioural description calledservice effect specification (SEFF). SEFFs model the ab-stract control flow through a component service in terms ofinternal actions (i.e., resource demands accessing the under-lying hardware) and external calls (i.e., accessing connectedcomponents). Modelling each component behaviour withseparate SEFFs enables us to quickly exchange componentspecifications without the need to manually change system-wide behaviour specifications (as required in e.g. UML se-quence diagrams).

Component developers can specify resource demands fortheir components (e.g., in terms of CPU instructions to beexecuted), which can then be divided by the processing rate

of the modelled resource environment to determine the ac-tual execution time demanded from the processors. Theycan also specify failure probabilities for component internalactions, which can be determined for example using softwarereliability growth models [29], or code coverage metrics dur-ing testing. The PCM also supports hard disk drive ratesand software resources such as thread pools.

A software architect composes component specificationsby various component developers into an application model.With an additional usage model describing user arrival rates(open workload) or user population and think time (closedworkload) of the system, and an additional model of theresource environment and the allocation of components toresources, the model is complete and can be transformedinto analytical or simulation-based models for quality anal-yses. For the PCM, we briefly explain the analysis methodsfor the three considered quality criteria performance, relia-bility, and cost. For each architectural candidate, we eval-uate the quality property (e.g. “response time 5 sec”) foreach quality criterion (e.g. criterion “performance” with themetric “response time of a service”).

• Performance: For performance analysis, the PCMsupports a transformation into a discrete-event sim-ulation (SimuCom [3]) or LQNs to derive responsetimes, throughputs, and resource utilizations. Simu-Com is based on model-to-code transformations andthe SSJ simulation framework. It is in the class of ex-tended queueing networks and allows analysing mod-els containing resource demands specified as arbitrarydistribution functions, but can be time-consumingto derive stable results. The LQN transformationPCM2LQN [26] generates an LQN instance from aPCM instance. The LQN solver [17] provides a heuris-tic performance analysis and can often quickly produceresults. However, it does only support mean values asprediction results and does not support arbitrary dis-tribution functions. In the remainder of this paper, wereport results obtained using the LQN solver.

• Reliability: For reliability analysis, the PCM sup-ports a transformation into absorbing discrete timeMarkov chains (DTMC) [25] or a reliability simulationto derive the probability of failure on demand (PO-FOD) for an usage scenario. The Markov chain gener-ator combines all behavioural models and creates fail-ure states for hardware resources based on the MTTF/ MTTR values in a PCM instance. The reliabilitysimulator is based on SimuCom and emulates the exe-cution of the system. It generates exceptions based onthe failure probabilities specified in the PCM and sim-ulates hardware crashes based on the MTTF / MTTRvalues of modelled hardware resources. In the remain-der of this paper, we report results obtained using theanalytic DTMC solver.

• Cost: For cost analysis, we have developed a PCMcost solver for this paper. It relies on a static anal-ysis of a PCM model instance. It calculates the costfor each component and resource based on the anno-tations specified in the PCM instance and then addsthese cost to derive the overall expected cost for thearchitecture. Cost can include both initial and oper-ational cost. If a server specified in the model is not

used, i.e. no components are allocated to it, its costdo not add to the overall cost. The goal of this sim-plistic model is to allow cost to be considered, not toprovide a sophisticated cost estimation technique. Forthe latter, existing cost estimation techniques such asCOCOMO II [5] could be integrated here to obtainmore accurate values.

The predicted quality properties for the example shownin Fig. 1 are depicted in Tab. 1. Although the example inFig. 1 is simple, it is not obvious on how to change the ar-chitectural model efficiently to improve the quality proper-ties. For example, the software architect could increase theprocessing rate of server S1, which would result in betterperformance but higher cost. The software architect couldalso change the component allocation (33 = 27 possibilities)or incorporate other component specifications with differentQoS attributes.

Quality Criterion Metric Value

PerformanceAvg. Resp. Time 4.6 secUtilization S1 42 %Utilization S2 37 %Utilization S3 10 %

Reliability POFOD 7.36E-4 %Cost Overall Cost 54 units

Table 1: Quality Property Prediction Results

The design space even for such a simple example is huge.Manually checking the possible design alternatives in a trial-and-error approach is laborious and error-prone. The soft-ware architect cannot easily create design alternatives thatare even locally optimal for all quality criteria, and findingglobal optima is practically impossible because it requiresmodelling each alternative. In practice this situation is of-ten mitigated by overprovisioning (i.e., incorporating fastand expensive hardware resources), which can lead to un-necessary high cost.

4. OPTIMISATION PROCESSTo automatically improve software architectural models

for performance, reliability and cost, we propose an auto-mated optimisation process that takes an initial architec-tural model as an input and searches for Pareto-optimal [15]candidate solutions. With the results of our process, soft-ware architects can focus on good solutions for their trade-offdecisions between multiple quality criteria.

To present our optimisation process, we first give anoverview on the process in Section 4.1. Then, we describe indetail the considered degrees of freedom (Section 4.2), theresulting search problem formulation (Section 4.3) and theevolutionary optimisation (Section 4.4).

4.1 Overview and ExampleFigure 2 shows an overview of our optimisation process.

Input is an initial architectural model of the system, namedinitial candidate. In our case, this is a complete PCM modelinstance as shown in Figure 1. In addition, generic degreesof freedom to be considered by the approach must be definedin advance. An example generic degree of freedom is com-ponents reallocation to other servers. The optimisation pro-cess starts with the search problem formulation. The initial

1. Search problem formulation

Initial candidate

System-specific

degrees of freedomInitial candidate

Resulting candidates QoS metrics

Generic degrees of freedom

2. Evolutionary Optimisation

3. Present results

Sec. 4.2

Sec. 4.3

Sec. 4.4

Sec. 4.5

Sec. 3

Figure 2: Optimisation Process Overview

candidate is analysed for occurrences of the generic degreesof freedom, resulting in system-specific degrees of freedom.An example system-specific degree of freedom is allocatingcomponent C1 to server S1, S2 or S3.

In the second step, evolutionary algorithms iterativelysearch for better solutions, by applying the main steps of(a) reproduction, (b) evaluation, and (c) selection to a pop-ulation of candidate solutions in each iteration.

The results of the optimisation phase is a set of Pareto-optimal candidate solutions, probably superior to the initialcandidate. The Pareto-optimal candidates are presented tothe software architect, who can study the remaining optimaltrade-offs between possibly conflicting objectives.

4.2 Generic Degrees of FreedomThe system cannot be changed arbitrarily in an auto-

mated approach. A human designer cannot be replaced.But to our advantage, software architectural models containa number of explicit degrees of freedom for variation thataffect quality properties, but do not affect the functionalityof the system. In particular, we only consider degrees offreedom that do not modify the interfaces used in the ar-chitecture. We further assume that components providingthe same interface provide the same functionality. From thisit follows that the variation along the considered degrees offreedom retains functionality.

In the following, we present the generic degrees of freedomthat we have identified so far in software architectural mod-els and which can be exploited by our approach. We startour list with four generic degrees of freedom that are alreadyexploited by our current optimisation process implementa-tion. We continue with three degrees of freedom currentlyavailable in the PCM and similar models but not yet ex-ploited in our implementation. Finally, we present furtherthree envisioned degrees of freedoms.

Allocation of components to servers can be changed, thisis an integral part of most performance-prediction modelsand has large effects on the performance of a system.

Processing rates of the available hardware resources(CPU, HDD, ...) can be changed in a certain range. Here, adiscrete set of CPU types all having a defined processing rateand cost could be modelled. Currently, we model processingrates as a continuous range, assuming that a CPU model forvirtually any processing rate within a range is available (e.g.by considering energy saving states (P-state) with resultinglower cost).

Number of servers: Servers can be added to providemore processing capacity or can be removed to save cost.

Selection of components and services: If function-ally-equivalent components with different non-functionalproperties are available, they can be exchanged. Currently,we deem that a component B can replace a component Aif B provides (i.e. implements) all interfaces provided by Aand if B requires at most the interfaces required by A. Simi-larly, external services such as web services in a SOA systemcan be exchanged.

Component replication: In addition to servers, soft-ware components can be replicated and distributed to sev-eral servers. For example, large scale web applications willhave several web servers and application servers. Here, con-straints can be formulated for software components that arenot ready for replication, for example because of componentstate.

Component configuration parameters: If compo-nents and their performance models provide configurationparameters, their values can be varied during the search.For example, a component can have a parameter to choosefrom several available compression algorithms.

Passive resources multiplicity, such as thread poolsize or database connection pool size, can be varied to finda good balance for the utilisation of underlying resources.Of course, multiplicity of locks for mutual exclusion regions(which can also be modelled with passive resources with ca-pacity of 1) must not be varied by our approach.

Further configuration of the software stack couldbe available in the architectural model. Models have beenproposed for operating system (OS) scheduler configura-tion [20], message-oriented-middleware configuration [21];and can be envisioned for other configurable OS proper-ties or JVM configuration of for example garbage collection.In addition, selection of software stack elements can be ex-plored by the optimisation if models are available: JVMselection (Sun’s JVM, Oracle’s JRockit JVM, ...), OS se-lection (Windows, Linux, ...), possibly also the choice ofhypervisors in virtualised environments. These options caneither be explicitly provided in software architectural modelas suggested by [23], or their effects can be added to theperformance model as completions, as suggested by [36] andrealised in e.g. [21].

Priorities: For several usage scenarios with differentquality requirements, the system could prioritise requestswith tight response time requirements. For example,business-relevant transactions can be assigned a higher pri-ority than maintenance functions. Priority optimisation aspresented by [16] could be included here.

Custom degrees of freedom could be specified by thesoftware architect by annotating any model element witha range of possible values and possibly the related per-formance, reliability and cost effects. For example, if acomponent-internal algorithm is designed, software archi-tects could identify possibilities for tuning the algorithm,resulting in lower resource demand of a component’s inter-nal action but higher cost of the component. A languagefor specifying such custom degrees of freedom would be re-quired.

In any case, to exploit a degree of freedom, it has to beavailable in the software architectural model and meaning-ful transformations to performance models, reliability mod-els and for cost calculation have to be available. For our

Generic degree offreedom

System-specificdegree of free-dom

Design option set

Processing rateof CPU Server1 {x ∈ N | 25E+9

≤ x ≤ 50E+9 }of CPU Server2 {x ∈ N | 25E+9

≤ x ≤ 50E+9 }of CPU Server3 {x ∈ N | 25E+9

≤ x ≤ 50E+9 }

Allocationof C1 {S1, S2, S3}of C2 {S1, S2, S3}of C3 {S1, S2, S3}

Componentselection

Alternatives forC2

{C2, C2a}

Table 2: Degrees of freedom in the example

running example, we consider three generic degrees of free-dom in the following: 1. “Change CPU speed of a server”,2. “Component allocation” and 3. “Component selection”.

4.3 Search Problem FormulationAs a first step in the optimisation process for a specific

system, we analyse which system-specific degrees of freedomare available in the given software model based on the givengeneral degrees of freedom. For the three generic degreesof freedom used in our motivating example, seven system-specific degrees of freedom can be identified as shown inTable 2. We identify three system-specific degrees of free-dom to change a processing speed of a CPU, one for eachconcrete CPU in the model, as well as three allocation de-grees. For the third generic degree of freedom, assume afourth available component C2a, that is faster, more reli-able but also more expensive than C2, exists as shown inFigure 3. Then, for the component selection, one systemspecific degree of freedom exists for C2, whereas C1 and C3have no alternatives available.

Component C2a

[Cost = 6 Units]

Action Action

Resource Demand

= 15E+8 CPU Instr.

Failure Probability

= 0.0001

Resource Demand

= 15E+8 CPU Instr.

Failure Probability

= 0.00015

<<implements>>

Figure 3: Alternative Implementation of C2

For each system-specific degree of freedom, we can deter-mine a range of options. For example, the system-specificdegree of freedom of where to allocate C1 has the three op-tions {S1, S2, S3}. CPU speed of available CPU modelsmight range from 25E+9 to 50E+9 instructions / sec.

In general, for each system-specific degree of freedom Di

(with an index set I and i ∈ I), we can derive the set of pos-sible choices: the design option set Oi, as exemplary shownin the last column of Table 2. Constraints on the system-specific degrees of freedom can be formulated at this pointby reducing the design option set of a system-specific degreeof freedom. For example, it could be excluded that C1 canbe allocated to S3 in our example, resulting in the remainingoptions {S1, S2}.

The design space DS in which the search problem is theCartesian product of the design option sets of all system-

specific degrees of freedom: DS = Πi∈IOi. The designspace DS is at the same time the set of all possible can-didate solutions. Each candidate c can be expressed asa vector of chosen design options: c ∈ DS with c =[o1 ∈ O1, ..., on ∈ On] , n = |I|. In our example, the initialcandidate c0 can be expressed as [ 35, 40, 30, S1, S2, S3, C2] with the ordering of degrees of freedom as given in Table 2and omitting the E notation part.

With these definitions, the problem is suited for evolution-ary algorithms. A candidate is represented by a vector ofchosen design options, which is named the candidate’s geno-type. The genotype is varied in the reproduction phase,where it is ensured that each gene has a value within thedesign option set. Based on a candidate c’s genotype, asoftware architecture model for c can be derived by insert-ing the chosen design options in the initial candidate model.The resulting model is named the phenotype of c. For thisphenotype of c, quality properties can be predicted in theevaluation phase, in our case with the PCM.

With this problem formulation, every newly generatedgenotype is valid, as long as there are no further constraintson combinations of degrees of freedom. An example for aconstraint on combinations is that C1 and C2 must not bedeployed on the same server because of e.g. conflicting sys-tem library version requirements. This does not limit thedesign options for each degree of freedom, but does con-strain the set of all candidates DS. Checks must be madein the selection phase of the metaheuristic, or the reproduc-tion phase has to take constraints into account. Note thatsuch a constraint is only formulated if a candidate is (1)functionally infeasible or (2) infeasible for quality criteriathat cannot be automatically quantitatively evaluated, suchas maintainability.

4.4 Evolutionary OptimisationCandidate solutions can be evaluated for optimal trade-

offs, i.e. for Pareto-optimality. A candidate architecture isPareto-optimal, if it is superior to any candidates evaluatedso far in at least one quality criterion. More formally: Leta be a candidate solution, let DS be the set of all possiblecandidates, let C ⊆ DS be a set of candidate solutions eval-uated so far, and let q be a quality criterion with a domainDq, an evaluation function fq : C → Dq so that fq(c) de-notes the quality property of a c ∈ C for the quality criterionq, and an order ≤q on Dq so that c1 ≤q c2 means that c1 isbetter than or equal to c2 with respect to quality criterionq. Then, candidate solution a is Pareto-optimal with respectto a set of evaluated candidate solutions C, iff

∀b ∈ C ∃q : fq(a) ≤q fq(b)

If a candidate solution is not Pareto-optimal, then it isPareto-dominated by at least one other candidate solution inC that is better or equal in all quality criteria. Analogously,a candidate is globally Pareto-optimal, if it is Pareto-optimalwith respect to the set of all possible candidates DS.

The optimisation problem can be formulated as followsfor a set of quality criteria Q = {q1, ..., qm}:

minc∈DS

[fq1(c), ..., fqm(c)]

Constraints on combinations can be added to the optimisa-tion problem at this point.

For the optimisation, we face a non-linear combinatorialoptimisation problem [4, Def. 1.1]. We cannot apply classic

Set of candidates

Set of candidates with

QoS metrics

Se

t o

f ca

nd

ida

tes

Mutation Crossover

Reproduction:

Generate new candidates

Initial candidate

Random

a

b

QoS requirements

constraint checks

Pareto-

optimality check

c

Performance Reliability Cost

Selection: Choose candidates for

next generation

Evaluation of each candidate

Stop? Set of Pareto-optimal

candidates

System-specifc degrees of freedom

2. Evolutionary Optimisation

Figure 4: Evolutionary optimisation process

techniques such as Branch-And-Bound [13]. Metaheuristicshave been successfully applied to similar problems in soft-ware engineering [22]. In this work, we use evolutionaryalgorithms, as for example described in [4, p. 284], as theyare found useful for multi-objective problems [10]. Othermetaheuristics such as simulated annealing or stochastic hill-climbing could be used as well.

We chose not to use a rule-based approach (which is alocal search technique) as other work do [38, 12, 33, 28], asthey are restricted to limited degrees of freedom each. No a-priori knowledge about the effects of many of the degrees offreedom is available. For example, rules for the exchange ofcomponents would require a numerical solution for optimalcomponent composition, which is not possible in general be-cause of the parametrisation of the component SEFFs. Forother degrees of freedom, such as allocation, rules can giveguidance, but cannot foresee the complexity of performancemetrics introduced by software resources and contention ef-fects. For example, if passive resources such as thread poolsare involved, allocation of components to servers cannot besolved by a bin-packing algorithm based on the resource de-mand of components only. Metaheuristic can search regionsof the search space for which no prior knowledge about therelation between choices and resulting quality properties ex-ists. Only a quantitative evaluation function for each qualitycriterion based on an architectural model is required.

Figure 4 shows the process model of our method. Themethod is described here exemplary for our current reali-sation with the PCM and the NSGA-II evolutionary algo-rithm [14] as implemented in the Opt4J framework [27], butcan as well be used for other software architecture mod-elling languages and other population-based metaheuristicsearch techniques. The process starts with an initial modelof a component-based software architecture (initial candi-date) and modifies it along the system-specific degrees offreedom. As the software model contains all required anno-

[27,50,50,S3,S1,S2,C2]

c0

c2c1 c3 c4

c5c7

[35,40,30,S1,S2,S3,C2]

[35,40,30,S1,S2,S2,C2] [26,45,44,S3,

S2,S1,C2a][36,35,28,S2,S3,S2,C2]

[55,40,30,S1,S2,S3,C2] [35,45,44,S1,

S2,S2,C2a]

[26,45,44,S1,S2,S1,C2a]

[29,40,50,S2,S3,S3,C2a]

c8c6

Cre

ate

d in

ite

ratio

n n

um

be

r

Random

Mutation

Crossover

Removed

Input population for:

Iteration 1

Iteration 2

Iteration 3

1

2

Figure 5: The beginning of an exemplary optimisa-tion run

tations, all steps of the search can be completely automated.Figure 5 shows the first two iterations of an exemplary run,starting with an initial given candidate c0 (we left the Enotation out and rounded to E+9 for brevity).

a© Reproduction: Based on the currently available can-didates in the population, new candidate solutions arederived by “mutation” or “cross-over” or they are ran-domly created. With mutation, one or several designoptions are varied. In our exemplary run, based on theinitial candidate c0, a new candidate c2 with changedallocation is derived in the first iteration that allocatesC3 on S2. Candidate c7 derives from c3 in the sec-ond iteration by reallocating C2a to S1. With cross-over, the genotypes of two good candidate solutionsare merged into one, by taking some of each candi-dates design option values for the cross-over. For ex-ample, candidate c2 and candidate c3 are combined bycross-over in the second iteration to produce c6. In ad-dition, candidates can be randomly generated based onthe available design options. For example, candidatec1 is randomly created here in the first iteration.

Performance domain specific heuristics could be inte-grated here to guide the search. For example, a heuris-tic mutation could move a component from an over-utilised server to a lightly utilised server.

b© Evaluation: In the second step, each newly derivedcandidate is evaluated for each quality criterion of in-terest. In our case, performance, reliability and costmetrics are predicted as described in sections 3. Asa result, each candidate is annotated with the deter-mined QoS properties. In our example, candidates c1to c4 are evaluated in the first iteration, and candi-dates c5 to c8 are evaluated in the second iteration.Candidate c0 has been evaluated before the actual op-timisation starts. The results for each candidate aredepicted in Figure 7 in the next section.

c© Selection: After the reproduction phase, the popu-lation has grown. In the selection phase, the pop-ulation is again reduced by removing less promisingcandidates. Here, we first remove candidates that vi-olate quality requirements. Second, we filter Pareto-dominated candidates and only keep Pareto-optimal

Server S1

Component C2a

[Cost = 6 Units]

Server S2

Component C3

[Cost = 3 Units]

Server S3

Rate = 35E+6 Instr./Second


MTTR = 6 hours


Rate = 45E+6 Instr./Second


MTTR = 6 hours


XCost = 0

Component C1

[Cost = 4 Units]Arrival

Rate

= 0.2 per

second

x : differ-

ences to c0

: not in

usex

Figure 6: Example PCM Model for Pareto-optimalcandidate c6

ones. In our example, candidates c0, c1 and c4 areremoved in the selection phase of iteration 1, and can-didates c5 and c7 are removed in the selection phase ofiteration 2. Possible future selection strategies couldalso keep a number of dominated or violating candi-dates to keep a diverse “gene pool” and avoid over-specialisation in local optima.

Over several iterations, the combination of reproductionand selection lets the population converge towards the frontof globally Pareto-optimal solutions. If the search also keepsa good diversity of candidates, we can find solutions nearto the global optima. In our example, a resulting solutionwith a good tradeoff is c6, shown in Figure 6. It is superiorto the initial candidate in average response time (3.23 sec)and cost (43), and has just as slightly higher probability offailure on demand (74E-04).

We currently use a predefined number of iterations to de-termine the end of the search. More sophisticated stop crite-ria could use convergence detection and stop when the globaloptimum is probably reached.

4.5 Present ResultsFinally, the resulting set of Pareto-optimal solutions is

presented to the software architect. The software architectcan identify interesting solutions and make well-informedtrade-off decisions between the multiple quality criteria andthe candidates that feature optimal tradeoffs. An examplevisualisation considering only response time and cost aftertwo iterations is shown in Figure 7. A visualisation for allthree considered quality criteria can be found in Section 5for the case study. In future work, more dimensions couldbe visualised with Radar-charts [9].

In an optional last step, interesting candidates, i.e. re-sulting Pareto-optimal candidates and candidates that areclose to them, can be automatically examined more closely.For example, a more detailed performance analysis of theinteresting candidates can be conducted to obtain more pre-cise performance metrics, for example by conducting long-running simulations.

5. CASE STUDYThis section describes a case study to demonstrate the

applicability and usefulness of our approach and is organ-ised as follows. Section 5.1 introduces the architecture and

c0

c1

c2

c3

c4

c5c6

c7

c8

2

3

4

5

6

7

40 42 44 46 48 50 52 54 56

Ave

rage

Re

spo

nse

tim

e in

se

c

Cost

Figure 7: Resulting candidates after 2 iterations(Pareto-optimal candidates: 3, initial candidate: 4,others ×)

the Palladio model of the system under study, the so-calledbusiness reporting system. Section 5.2 describes the degreesof freedom in this system and formulates the search prob-lem. Section 5.3 details on an optimisation run performedon the model. Finally, Section 5.4 presents and discussesthe results of the automatic optimization.

Notice that we do not compare our prediction results fromthe models with actual measurements from the system im-plementation. For our validation, we assume that the un-derlying modelling and prediction methods are sound anddeliver accurate prediction results as demonstrated in otherpapers [3, 7].

5.1 Business Reporting SystemThe system under study is the so-called business reporting

system (BRS), which lets users retrieve reports and statisti-cal data about running business processes from a data base.It is loosely based on a real system [37]. Fig. 8 shows someparts of the PCM instance of the BRS visualised using an-notated UML diagrams. It is a 4-tier system consisting ofseveral software components.

The WebServer component handles user requests for gen-erating reports or viewing the plain data logged by the sys-tem. It delegates the requests to a Dispatcher component,which in turn distributes the requests to four replicatedReportingServers. The replication helps balancing the loadin the system, because the processing load for generating re-ports from the database contents is considered significant.Each ReportingServer component is a composite compo-nent consisting of an inner ReportingEngine and a Cache

component. The ReportingServers access two replicatedDatabases for the business data.

Besides the static view of the system, Fig. 8 also containsa behavioural view in form of service effect specifications inthe upper half of the figure. The SEFFs contain the resourcedemands, failure probabilities, and call propagations laterpredictions will be based on. The components are allocatedon eight different servers connected by different network de-vices. Our case study analyses a usage scenario, where 50users access the system concurrently. Each user requests areport or view from the system and then looks at the re-sults for 10 seconds before issuing the next request (closedworkload).

For the performance prediction, we transform the modelinto a LQN using PCM2LQN [26]. The average responsetime for this model as predicted by the LQNS tool is 2.2seconds.

Web Server

Dispatcher

Reporting

EngineCache

Data

base

ReportingServer

Reporting

EngineCache

ReportingServer

Reporting

EngineCache

ReportingServer

Reporting

EngineCache

ReportingServer Data

base

<<implements>> <<implements>> <<implements>>



MTTR = 6 hours

Cost = 10 Units

Processing Rate =

10E+9 Instr./Second

MTTF = 219.000

hours

MTTR = 6 hours

Cost = 10 Units



MTTR = 6 hours

Cost = 10 Units

User

Population

= 50

Think time

= 10.0 s



MTTR = 8 hours

Cost = 10 Units

InternalAction

rd=2E+08

fp=0.00012

InternalAction

rd=4E+09

fp=0.0005

ExternalCall

report

ExternalCall

view

p=0.3 p=0.7

InternalAction

rd=5.2E+08

fp=0.00034

InternalAction

rd=1.0E+08

fp=0.00050

InternalAction

rd=3.3E+08

fp=0.00098

InternalAction

rd=2.5E+08

fp=0.0037

ExternalCall

getSmallReport

ExternalCall

getCachedData

ExternalCall

getBigReport

p=0.1p=0.9

loopCount = 7

loopCount = 2

InternalAction

rd=1.0E+08

fp=0.00055

getSmallReport

InternalAction

rd=3.0E+08

fp=0.00050

getBigReport

InternalAction

rd=3.0E+07

fp=0.00021

getCachedData

Cost =

7 Units

Cost =

4 Units

Cost =

12 UnitsCost =

5 Units

serveRequest

report

Figure 8: Business Reporting System: PCM instance of the case study system

For the reliability prediction, we use the PCM Markovtranslator [7], which predicts a probability of failure on de-mand for the system of 0.0605 percent. This means thateach user request will be successful with a probability of99.9395 percent. The cost for the system calculated by thePCM cost solver are 98 units.

5.2 Search Problem FormulationTo formulate the search problem for the business reporting

system, first the system specific degrees of freedom have tobe determined. For our case study, we consider the followingdegrees of freedom: component selection, server processingrates, and component allocation.

Component selection is possible in this system as it con-tains several replaceable standard components. The Web

Server as well as the Database can be realised using thirdparty components. The software architect can choose amongmultiple functional equivalent components with differentnon-functional properties and cost. For the BRS, we havemodelled two additional web servers and one additionaldatabase which have different performance and reliabilityproperties, but also higher or lower cost than the compo-nents in the initial system.

Server processing rates can be adjusted at multiple loca-tions in the model as it contains 8 servers. It is expectedthat the overall performance of the system increases mostsignificantly when using faster processing rates for highlyutilised components. We assume here that the bounds forthe processing rate are 1/2 of the initial rate (lower bound)and 2 times the initial rate (upper bound). Currently, the

processing rate is modelled as a continuous variable.Component allocation can be crucial for the non-

functional properties and cost of the system. It could bepossible to allocate multiple components on the same serverwithout affecting the performance or reliability significantly.This could allow to remove some servers to save cost.

The genome of the initial candidate determined by Per-Opteryx looks as follows: [1, 1, 1, 1, 1, 1, 1, 1, DB, Web-Server, DB, server1, server2, server4a, server4b, server3a,server3b, server3c, server3d]. It reflects the processing rates,the alternatively used components as well as the componentallocation to different servers (e.g., WebServer is deployedon server 1 and Dispatcher is deployed on server 2).

5.3 Evolutionary OptimisationFor the evolutionary optimisation of the model, our pro-

totype PerOpteryx tool follows the process described inSection 4.4. We configured Opt4J to run for 40 iterationsand to produce 60 candidates per iteration. The LQN solverwas configured with a convergence value of 0.001 and an it-eration limit of 200 (see [26] for details). The PCM Markovmodel solver was used in a standard configuration.

The automatic improvement process took 8 hours, pro-duced more than 1235 valid architectural candidates andmade performance, reliability, and cost predictions for them.The average creation, transformation, and prediction timeper candidate was 24 seconds. 58 of the candidates weredeemed Pareto-optimal by the evolutionary algorithm.

The evolution process run time could be shortened sig-nificantly by executing the candidate analyses per candi-

Figure 9: BRS system: 3D-Pareto front Perfor-mance vs. Reliability vs. Cost

date concurrently (e.g., on multicore processors or in a dis-tributed environment). We consider this enhancement toour tool as future work.

5.4 Present ResultsThe results of the evolutionary optimisation run are de-

picted in Figures 9 to 11.Figure 9 visualizes the three dimensional Pareto front for

performance, reliability, and cost. Figure 10 shows the re-sponse time in seconds over the cost per candidate, whileFigure 11 shows the probability of failure on demand overthe cost per candidate. The software architect can use theseresults to make an informed trade-off decision among thedifferent quality criteria.

In Figures 10 to 11, the 58 Pareto-optimal points are high-lighted as thick squared marks. These points are not locatedat the borders of the candidate sets, as it would be the casefor a two-dimensional set. Pareto-optimal points locatedwithin the set are superior to others in the third quality cri-terion not shown in the respective diagram (i.e., reliabilityin the first case and performance in the second case). Forexample, the highlighted candidate in Figure 10 has a higherresponse time and higher cost than some other candidates,but its reliability is superior to these other points.

We describe one of the found Pareto-optimal solutions inmore detail. It is highlighted in Fig. 10 and Fig. 11 usingcircles. The response time of this solution is 1.34 seconds(initial candidate: 2.2 seconds), its POFOD is 0.0526 per-cent (initial candidate: 0.0605), and its cost are 69.83 units(initial candidate: 98 units). Therefore it is superior to theinitial candidate in all quality criteria.

The genome of this solution is: [1.76, 1.19, 1.01, 0.53,1.02, 2, 1.62, 1.71, DB, WebServer3, DB, server1, server1,server4a, server3d, server2, server1, server4a, server3d].This means that the evolutionary algorithm has increasedthe processing rates of almost all CPUs. Server1 was for-merly fully utilised by the WebServer component, but nowcan also host the Dispatcher component, because of the in-creased processing rate. Therefore an additional server forthe Dispatcher can be saved lowering the overall cost.

The algorithm has also selected the component Web-

Server3 instead of WebServer, because of its better per-formance with only slightly higher cost. Furthermore, the

0

2

4

6

8

10

12

14

16

18

20

0 20 40 60 80 100 120 140 160

Ave

rage

Re

spo

nse

Tim

e (

Seco

nd

s)

Costs (Units)

All candidates

Pareto-optimal candidates

Initial Candidate

Example Pareto-optimalCandidate

Figure 10: BRS system: Performance vs. CostTradeoff

0.0000

0.0001

0.0002

0.0003

0.0004

0.0005

0.0006

0.0007

0 20 40 60 80 100 120 140 160

Pro

bab

ility

of

Failu

re o

n D

em

and

Costs (Units)

All candidates

Pareto-optimal candidates

Initial Candidate

Example Pareto-optimalCandidate

Figure 11: BRS system: Reliability vs. Cost Trade-off

optimization run deemed the DB2 component as too expen-sive and continued to use the DB component. Two of theReportingServers have been allocated to the same server,thereby saving the cost for an additional server while stillproviding adequate performance and reliability.

Our main contribution in this work is to formulate thesearch problem and allow automatic search, and not theparticular chosen optimisation strategy. Thus, we have notcompared our optimisation run with random search in thiswork. Such a comparison can be found at2.

To conclude, the optimisation run of our case study wasable to reduce the amount of over-provisioning present in theinitially modelled system and presented a solution candidatewith improved performance and reliability for lower cost.The software architect does not have to use this solutionexactly as produced by the optimization run. However, it isnow known that faster processors within the system can helpto reduce the amount of needed servers, and that buying theWebServer2 component justifies its higher cost.

6. LIMITATIONS AND FUTURE WORKBesides inheriting all limitations of the underlying qual-

ity prediction techniques (see [3] for performance, [25] forreliability), our approach exhibits the following limitations:

• No guaranteed optimality: The approach itself is abest-effort approach and does not guarantee to find the

2palladio-approach.net/ PerOpteryx

real Pareto-front, i.e. the globally optimal solutions,because metaheuristics are used.

• Questionable efficiency: As the evaluation of eachcandidate solution, mainly due to the performanceevaluation, takes several seconds, the overall approachis considerably time consuming. Here, software archi-tects should run it in parallel to other activities orover night. A distribution of the analyses on a clus-ter of workstations could lead to significant improve-ments. It could also be possible to split the optimisa-tion problem into several independent parts that aresolved separately and thus quicker. Problem-specificheuristics allowing faster convergence and thus requir-ing less evaluations are a crucial extension.

• No regard for uncertainties: For the results, uncer-tainty of estimations, uncertainty of the workload, andthe resulting risks are not taken into account. Here,sensitivity metrics could be an additional quality cri-terion.

• Limited degrees of freedom: Currently, design op-tions that offer new degrees of freedom are not yetconsidered. For example, adding a new server resultsin further options to configure that server. Such de-sign options could be integrated by formulating thegenotype as a tree structure rather than a vector.

• Simplistic cost model: The cost model used hereis simplistic, as we only wanted to demonstrate theapproach. We do not want to devise a new cost esti-mation technique. However, more sophisticated costestimations techniques such as COCOMO II [5] couldbe integrated.

• Limited genetic encoding: So far, the genetic en-coding is an array of choices. More complex degrees offreedom like replacement of subsystem, which opens upmore degrees of freedom for inner components, cannotbe expressed yet.

An important aspect of future work is to combine ourapproach with subordinate heuristics to make use of perfor-mance domain knowledge. For example, heuristics to im-prove allocation based on the resource demands of compo-nents and utilisation of servers could be introduced. In ad-dition, rules as presented in [38, 12, 28] could be integratedin specialised mutation operators. Performance antipatterndetection and solution as suggested in [11] could comple-ment this approach. Such subordinate heuristics can helpthe approach to find good solutions more quickly.

7. CONCLUSIONSThis paper presents an approach to automatically improve

software architectures with respect to performance, reliabil-ity, and cost. Using this approach, the design space spannedby different design options (e.g. available components andconfiguration options) can be systematically explored usingmetaheuristic search techniques. Based on an initial archi-tectural model of a system, new candidates are automati-cally generated and evaluated for the quality criteria. Theprocess is extensible for different modelling notations, analy-sis methods, and quality criteria. We provide a prototypicalimplementation of our approach with the PerOpteryx tool

based on the PCM as well as a case study to demonstratethe feasibility and the benefits.

Our work saves software architects effort to manually ex-plore the design space of their software architecture understudy, and instead allows them to focus on Pareto-optimalsolutions for their trade-off decisions between multiple qual-ity criteria. In addition, software architecture alternativescan be found that might have escaped human attention.Thus, our approach can reduce development cost and resultin software architectures with better quality properties.

The next steps to extend our work will be the integra-tion of subordinate heuristics to include performance domainknowledge. Here, we plan to integrate our metaheuristic ap-proach with existing rule-based approaches to leverage theadvantages of both. Furthermore, we will enhance our ap-proach to allow the specification and checking of quality cri-teria requirements as well as manually specified constraintson the architectural model, which can help avoid undesiredor infeasible design alternatives.

8. REFERENCES[1] A. Aleti, S. Bjornander, L. Grunske, and

I. Meedeniya. Archeopterix: An extendable tool forarchitecture optimization of AADL models.International Workshop on Model-BasedMethodologies for Pervasive and Embedded Software(MOMPES), pages 61–71, 2009.

[2] S. Balsamo, A. Di Marco, P. Inverardi, andM. Simeoni. Model-Based Performance Prediction inSoftware Development: A Survey. IEEE Transactionson Software Engineering, 30(5):295–310, May 2004.

[3] S. Becker, H. Koziolek, and R. Reussner. The Palladiocomponent model for model-driven performanceprediction. J. of Systems and Software, 82:3–22, 2009.

[4] C. Blum and A. Roli. Metaheuristics in combinatorialoptimization: Overview and conceptual comparison.ACM Computing Surveys, 35(3):268–308, 2003.

[5] B. W. Boehm, C. Abts, A. W. Brown, S. Chulani,B. K. Clark, E. Horowitz, R. Madachy, D. J. Reifer,and B. Steece. Software Cost Estimation with CocomoII. Prentice Hall, Upper Saddle River, NJ, USA, 2000.

[6] E. Bondarev, M. R. V. Chaudron, and E. A. de Kock.Exploring performance trade-offs of a JPEG decoderusing the DeepCompass framework. In Proc. ofWOSP’07, pages 153–163, New York, NY, USA, 2007.ACM Press.

[7] F. Brosch and B. Zimmerova. Design-Time ReliabilityPrediction for Software Systems. In Proceedings of theInternational Workshop on Software Quality andMaintainability (SQM’09), pages 70–74, March 2009.

[8] G. Canfora, M. D. Penta, R. Esposito, and M. L.Villani. An approach for qoS-aware servicecomposition based on genetic algorithms. In H.-G.Beyer and U.-M. O’Reilly, editors, Proc. of Geneticand Evolutionary Computation Conference 2005,pages 1069–1075. ACM, 2005.

[9] J. M. Chambers, W. S. Cleveland, B. Kleiner, andP. A. Tukey. Graphical Methods for Data Analysis.Wadsworth Internat. Group, 1983.

[10] C. A. C. Coello. A comprehensive survey ofevolutionary-based multiobjective optimizationtechniques. Knowledge and Information Systems,

1:269–308, 1999.

[11] V. Cortellessa, A. Di Marco, R. Eramo,A. Pierantonio, and C. Trubiani. Approaching themodel-driven generation of feedback to removesoftware performance flaws. In Proc. of EuromicroConference on Software Engineering and AdvancedApplications, to appear, 2009.

[12] V. Cortellessa and L. Frittella. A framework forautomated generation of architectural feedback fromsoftware performance analysis. In K. Wolter, editor,Proc. of Fourth European Performance EngineeringWorkshop, volume 4748 of Lecture Notes in ComputerScience, pages 171–185. Springer, 2007.

[13] R. Dakin. A tree search algorithm for mixed integerprogramming problems. Computer Journal, 8:250–255,1965.

[14] K. Deb, S. Agrawal, A. Pratap, and T. Meyarivan. Afast elitist non-dominated sorting genetic algorithmfor multi-objective optimization: NSGA-II. In ParallelProblem Solving from Nature PPSN VI, volume1917/2000, pages 849–858. Springer-Verlag, Berlin,Germany, 2000.

[15] M. Ehrgott. Multicriteria Optimization.Springer-Verlag, New York, USA, 2005.

[16] H. El-Sayed, D. Cameron, and M. Woodside.Automation support for software performanceengineering. In Proc. of the 2001 ACM SIGMETRICSinternational conference on Measurement andmodeling of computer systems, pages 301–311, NewYork, NY, USA, 2001. ACM.

[17] G. Franks, T. Omari, C. M. Woodside, O. Das, andS. Derisavi. Enhanced modeling and solution oflayered queueing networks. IEEE Trans. SoftwareEng, 35(2):148–161, 2009.

[18] S. S. Gokhale. Architecture-based software reliabilityanalysis: Overview and limitations. IEEE Trans. onDependable and Secure Computing, 4(1):32–40,January-March 2007.

[19] L. Grunske, P. A. Lindsay, E. Bondarev,Y. Papadopoulos, and D. P. 0002. An outline of anarchitecture-based method for optimizingdependability attributes of software-intensive systems.In R. de Lemos, C. Gacek, and A. B. Romanovsky,editors, WADS, volume 4615 of Lecture Notes inComputer Science, pages 188–209. Springer-Verlag,Berlin, Germany, 2006.

[20] J. Happe. Predicting Software Performance inSymmetric Multi-core and MultiprocessorEnvironments. Dissertation, University of Oldenburg,Germany, August 2008.

[21] J. Happe, S. Becker, C. Rathfelder, H. Friedrich, andR. H. Reussner. Parametric Performance Completionsfor Model-Driven Performance Prediction.Performance Evaluation, 2009. Accepted forpublication in 2009.

[22] M. Harman. The Current State and Future of SearchBased Software Engineering. Proc. of Future ofSoftware Engineering, pages 342–357, May 23-25 2007.

[23] M. Hauck, M. Kuperberg, K. Krogmann, andR. Reussner. Modelling Layered ComponentExecution Environments for Performance Prediction.In Proc. of the International Symposium on

Component Based Software Engineering, number 5582in LNCS, pages 191–208. Springer, 2009.

[24] A. Kavimandan and A. S. Gokhale. Applying modeltransformations to optimizing real-time QoSconfigurations in DRE systems. In Proc. of Quality ofSoftware Architectures, pages 18–35, 2009.

[25] H. Koziolek and F. Brosch. Parameter dependenciesfor component reliability specifications. In Proc. ofWorkshop on Formal Engineering approaches toSoftware Components and Architectures. Elsevier,2009.

[26] H. Koziolek and R. Reussner. A ModelTransformation from the Palladio Component Modelto Layered Queueing Networks. In PerformanceEvaluation: Metrics, Models and Benchmarks, SIPEW2008, volume 5119 of Lecture Notes in ComputerScience, pages 58–78. Springer-Verlag BerlinHeidelberg, 2008.

[27] M. Lukasiewycz. Opt4j - the optimization frameworkfor java. http://www.opt4j.org, 2009.

[28] J. D. McGregor, F. Bachmann, L. Bass, P. Bianco,and M. Klein. Using arche in the classroom: Oneexperience. Technical Report CMU/SEI-2007-TN-001,Software Engineering Institute, Carnegie MellonUniversity, 2007.

[29] J. D. Musa, A. Iannino, and K. Okumoto. SoftwareReliability – Measurement, prediction, application.McGraw-Hill, New York, 1987.

[30] Object Management Group (OMG). UML Profile forModeling and Analysis of Real-Time and Embeddedsystems (MARTE) RFP (realtime/05-02-06), 2006.

[31] Object Management Group (OMG). Unified ModelingLanguage: Superstructure Specification: Version 2.1.2,Revised Final Adopted Specification(formal/2007-11-02), 2007.

[32] Object Management Group (OMG). OMG SystemsModeling Language (OMG SysMLTM).http://www.sysmlforum.com/docs/specs/OMGSysML-v1.1-08-11-01.pdf, 112008.

[33] T. Parsons and J. Murphy. Detecting performanceantipatterns in component based enterprise systems.Journal of Object Technology, 7(3):55–90, Mar. 2008.

[34] C. U. Smith and L. G. Williams. PerformanceSolutions: A Practical Guide to Creating Responsive,Scalable Software. Addison-Wesley, 2002.

[35] M. Woodside, G. Franks, and D. C. Petriu. The Futureof Software Performance Engineering. In Proceedingsof ICSE 2007, Future of SE, pages 171–187. IEEEComputer Society, Washington, DC, USA, 2007.

[36] M. Woodside, D. C. Petriu, and K. H. Siddiqui.Performance-related Completions for SoftwareSpecifications. In Proc. of the International Conferenceon Software Engineering, pages 22–32. ACM, 2002.

[37] X. Wu and M. Woodside. Performance Modeling fromSoftware Components. SIGSOFT Softw. Eng. Notes,29(1):290–301, 2004.

[38] J. Xu. Rule-based automatic software performancediagnosis and improvement. In Proc. of WOSP’08,pages 1–12, New York, NY, USA, 2008. ACM.

Automatically Improve Software Architecture Models for

Documents

Transcript of Automatically Improve Software Architecture Models for