Embed Size (px)
Citation preview
Model-Based Performance Predictionwith the Palladio Component Model
Steffen BeckerIPD, University of Karlsruhe76131 Karlsruhe, Germany
Heiko Koziolek∗
Graduate School TrustSoftUniversity of Oldenburg
26111 Oldenburg, Germany
Ralf ReussnerIPD, University of Karlsruhe76131 Karlsruhe, Germany
ABSTRACTOne aim of component-based software engineering (CBSE)is to enable the prediction of extra-functional properties,such as performance and reliability, utilising a well-definedcomposition theory. Nowadays, such theories and their ac-companying prediction methods are still in a maturationstage. Several factors influencing extra-functional propertiesneed additional research to be understood. A special prob-lem in CBSE stems from its specific development process:Software components should be specified and implementedindependent from their later context to enable reuse. Thus,extra-functional properties of components need to be spec-ified in a parametric way to take different influence factorslike the hardware platform or the usage profile into account.In our approach, we use the Palladio Component Model tospecify component-based software architectures in a para-metric way. This model offers direct support of the CBSEdevelopment process by dividing the model creation amongthe developer roles. In this paper, we present our modeland a simulation tool based on it, which is capable of mak-ing performance predictions. Within a case study, we showthat the resulting prediction accuracy can be sufficient tosupport the evaluation of architectural design decisions.
Categories and Subject DescriptorsD.2.11 [Software Engineering]: Software Architectures;C.4 [Performance of Systems]; I.6.5 [Simulation andModelling]: Model Development
KeywordsComponent-Based Software Engineering, Software Architec-ture, Performance Prediction
∗This work is supported by the German Research Founda-tion (DFG), grant GRK 1076/1
1. INTRODUCTIONIn CBSE, a central idea is to build complex software sys-tems by assembling basic components. The initial goal ofCBSE was to increase the level of reuse. However, com-posite structures may also increase the predictability of thesystem during early design stages, because models of indi-vidual components can be certified and then be composed,enabling system architects to reason on the composed struc-ture. This is important for functional properties, but also forextra-functional properties like performance (i.e., responsetime, throughput, resource utilisation) and reliability (i.e.,mean time to failure, probability of failure on demand).
Prediction methods for performance and reliability of gen-eral software systems are still limited and seldomly used inindustry [2, 4]. Especially for component-based systems fur-ther challenges arise. Opposed to object-oriented systemdevelopment and performance prediction [21], where devel-opers design and implement the whole system, several in-dependent developer roles are involved in the creation of acomponent-based software system. Component developersproduce components that are assembled by system archi-tects and deployed by system allocators. The diverse infor-mation needed for the prediction of extra-functional prop-erties is thus spread among these developer roles.
Most existing methods for component-based performanceprediction require system architects to model the systembased on specifications of single components. Often, it isassumed that the system architect can provide missing in-formation. This assumption is necessary because of today’sincomplete component specifications. For example, in [5]system architects model the control flow through the com-ponent-based architecture, which is impossible if compo-nents are black boxes and the dependencies between pro-vided and required interfaces are unknown. Thus, a specialcomponent specification is needed.
Other approaches neglect factors affecting the perceivedperformance of a software component like influences by ex-ternal services [20, 9], changing resource environments [12,17, 6], or different input parameters [5]. However, for accu-rate predictions, these dependencies have to be made explicitin component specifications.
With the Palladio 1 Component Model, a meta-model al-
1Our component model is named after the Italian renais-sance architect Andrea Palladio (1508-1580), who, in a cer-tain way, tried to predict the aesthetic impact of his build-ings in advance.
lowing the specification of performance-relevant informationof a component-based architecture, we provide an initial at-tempt to address the identified problems. First, our modelis designed with the explicit capability of dividing the modelartefacts among the different roles involved in a CBSE de-velopment process. These modelling artefacts can be con-sidered as domain specific modelling languages, which cap-ture the information available to a specific developer role.Second, the model reflects that a component can be usedin changing contexts with respect to the components it isconnected to, the allocation of the component on resources,or different usage contexts. This is done by specifying para-metric dependencies, which allow deferring context decisionslike assembly or allocation.
For an initial validation, we have developed a tool capableof simulating instances of the Palladio Component Model toobtain performance metrics. We used this tool in a casestudy to simulate the performance of a component-basedonline shop. Comparing the simulation results with mea-surements made on an implementation of the architectureenabled estimating the accuracy of our simulations.
The contribution of this paper is a component meta-modelbased on a CBSE role concept which allows parametric spec-ifications done by different developer roles in the CBSEdevelopment-process. Additionally, we present mathemat-ical model concepts of our component model, which allowto use arbitrary stochastic distribution functions for thesetypes of specifications. A case study which applies our sim-ulation tool for instances of our meta-model to the imple-mentation of the modelled architecture finally shows the ex-pressiveness of our model. Assumptions we made in earlierwork [15] have been weakened in this case study but stillwithout significant loss of prediction accuracy.
This paper is structured as follows: In section 2, we brieflyreview related work. Section 3 introduces our CBSE roleconcept and provides details of the component meta-model.Examples of how the parametric dependencies can be spec-ified and evaluated are given in section 4. Section 5 detailson the developed simulation tool. Assumptions and limita-tions of our work are discussed in section 6. In section 7, acase study applying our simulation tool to a model instanceis presented. Finally, we conclude our paper and outlinefuture work.
2. RELATED WORKThe approach presented in this paper is related to perfor-mance meta-models, component models, usage modelling inperformance prediction, and simulations.
Three recent performance meta-models are compared byCortellessa in [7]: The performance domain model of theUML SPT profile [18], the Core Scenario Model from Wood-side et al. [23], and the Software Performance Engineer-ing (SPE) meta-model [21] are designed for general softwaresystems. Another meta-model is KLAPER from Grassi etal. [11], which, like our model, is designed for component-based software systems. KLAPER reduces the complexityof other models with a unifying concept for resources andcomponents. The Palladio Component Model reduces mod-elling complexity by providing different models for differentCBSE developer roles.
Besides models designed specifically for the runtime per-formance prediction of a software system, several other com-ponent models have been proposed. Each model has its
own special focus on a set of particular aspects depend-ing on the respective analysis methods. Recent componentmodels are often divided into two types: industrial- andresearch-oriented models. Industrial models (like EJB orCOM) have been designed to support specific implementa-tion tasks. They often lack the support of broad analysiscapabilities w.r.t. extra-functional properties. Research ori-ented models (like SOFA) are often accompanied with a spe-cial analysis method for a set of system properties. A recenttaxonomy of the models used today is presented in [16].
Other approaches have put emphasis on accurate usagemodelling for performance predictions. Hamlet et al. [12]execute components and measure how they propagate re-quests in order to gain accurate performance predictions.In our approach, we require component developers to spec-ify these propagations, because components are often notavailable for measurements when including them into pre-dictions. Bondarev et al. [6] model cost functions dependingon input parameters, but do not use stochastic characterisa-tions of these parameters. Sitamaran et al. [20] use extendedBig-O Notations to specify the performance of software com-ponents depending on input parameters. Bertolino et al.extend the SPE approach for component-based systems in[5], but do not model input parameters.
Simulation techniques are often used to evaluate perfor-mance models such as queueing networks, stochastic Petrinets, and stochastic process algebras. In a survey on model-based performance predictions techniques by Balsamo et al.[2], simulations models by [8] and [1] are described. TheUML-PSI tool by Marzolla [3] derives an event-driven sim-ulation from UML models, but is not specifically designedfor component-based systems.
3. COMPONENT-BASED PERFORMANCEMODELLING
The Palladio Component Model is a meta-model for the de-scription of component based software architectures. Themodel is designed with a special focus on the prediction ofQuality-of-Service (QoS) attributes, especially performanceand reliability. In the following, we give some details onour envisioned CBSE development process and the partici-pating roles. Afterwards, we highlight some concepts of ourmeta-model omitting concepts not used in this paper.
3.1 CBSE Development ProcessIn the CBSE development process (see also [14]), we dis-tinguish four types of developer roles involved in producingartefacts of a software system (see Figure 1).
Component developers specify and implement the compo-nents. The specification contains an abstract, parametricdescription of the component and its behaviour. Systemarchitects assemble components to build applications. Forthe prediction of extra-functional properties, they retrievecomponent specifications by component developers from arepository.
System deployers model the resource environment and af-terwards the allocation of components from the assemblymodel to different resources of the resource environment.Business domain experts, who are familiar with the cus-tomers or users of the system, additionally provide usagemodels describing critical usage scenarios as well as typicalparameter values.
Usage Model
Component Specifications
<<User>>
Assembly Model
Allocation Model
<<Component Developer>>
QoS EvaluationModel
<<System Architect>>
<<System Deployer>>
<<Domain Expert>>
Figure 1: Process
The complete system model can be derived from the par-tial models specified by each developer role and then extra-functional properties can be predicted. Each developer rolehas a domain specific modelling language and only sees andalters the parts of the model in its responsibility. The in-troduced partial models are aligned with the reuse of thesoftware artefacts.
3.2 Fundamental ConceptsSeveral concepts in the Palladio Component Model havecounterparts in the UML2 meta-model. Hence, we keepthe description of these concepts brief. We do not definea profile for UML2, because we want to avoid ambiguitiesin the UML2 meta-model and restrict the specification onlyto those constructs that can be handled by our evaluationmethod.
Components are generally specified via provided and re-quired interfaces. An interface serves as contract between aclient requiring a service and a server providing the service.Components implement services specified in their providedinterfaces using services specified in their required interfaces.
In its most basic form, an Interface consists of a list ofservice Signatures. A signature has a name, a sorted listof parameters, a return type and an unsorted list of excep-tions it might raise during its execution. This is similar tothe Corba Interface Definition Language (IDL). Interfacesare first-class entities in the Palladio Component Model andthemselves neither providing nor requiring. Only their rela-tions to components define their roles. We call this relationProvided- or Required Role, respectively.
Components and their roles can be connected to build anAssembly using assembly connectors. An assembly connec-tor connects a required role of a component with a providedrole of another component. This means that any call emit-ted by the component requiring a service of the required roleis directed to the connected component providing that ser-vice. For connectors it is important that the required andprovided interfaces match, e.g., that the service is providedas expected by the requiring component. As mentioned ear-lier, the assembly model is specified by the system architectin a domain specific modelling language referring to specifi-cations of individual components from component develop-ers.
3.3 Service Effect SpecificationTo each provided service of a component, component de-velopers can add a so-called ServiceEffectSpecification
(SEFF), which describes how the provided service calls therequired services of the component. In former approaches(e.g., [19]), SEFFs have been described as automata mod-elling the order of calls to required services thus being anabstraction of the control flow through the component.
For performance analysis, the mere sequence of externalcalls is not sufficient. Thus, we extend SEFFs to so-calledResourceDemandingSEFFs. Besides the sequence of called re-quired services, a ResourceDemandingSEFF contains resourceusage, transition probabilities, loop iteration numbers, andparameter dependencies to allow accurate performance pre-dictions. Its meta-model will be described in the following.It can be considered as a domain specific modelling lan-guage for the component developer to specify performancerelated information for a component service. For clarity, wespread the description over multiple figures. Examples forResourceDemandingSEFFs follow in figures 8-13.
AbstractAction
ParametricParameterUsage
ParametricResourceDemanddemand : Stringunit : String
ResourceDemandingBehaviour
ResourceDemandingSEFF
ServiceEffectSpecificationseffTypeID : EString
SignatureserviceName : EString
transition0..1
+ successor_AbstractAction
0..1
+ predecessor_AbstractAction
1
*
1 *
1
*
*
1
Figure 2: Behaviour
Figure 2 shows that a ResourceDemandingSEFF extendsa ServiceEffectSpecification, which itself references theSignature of a service, and a ResourceDemandingBehav-
iour. A ResourceDemandingBehaviour consists of a numberof AbstractActions, a number of ParametricResourceDe-
mands, and a number of ParametricParameterUsages.
AbstractAction
AbstractResourceDemandingActionExternalCallAction ParametricResourceDemand
demand : Stringunit : String
ParametricParameterUsage
PassiveResourceType
ProcessingResourceTypeAquireAction ReleaseAction
Signature
serviceName : EString
transition0..1
+ successor_AbstractAction
0..1
+ predecessor_AbstractAction
1 *1
*
1
1+ calledService_ExternalService
11
1
1
1
1
Figure 3: Abstract Actions
An AbstractAction (Figure 3) can be specialised to be anAbstractResourceDemandingAction or an ExternalCall-
Action to a required service. ResourceDemandingActionscan place loads on the resources, which the component isusing (e.g., CPU, harddisk, network connection, etc.). De-mands can be specified as distribution functions, addition-ally their unit (e.g., CPU operations, harddisk accesses, etc.)has to be specified. Because the actual resources used by
the component are not known during component specifica-tion, the component developer specifies the resource demandonly for abstract resource types (in this case Processing-
ResourceTypes) and not for concrete resource instances.Passive resources, such as threads or semaphors, have
to be acquired before using them, and released afterwards.This can be modelled with the AcquireActions and Re-
leaseActions that are associated with a PassiveResource-
Type.The resource usage generated by executing a required ser-
vice with an ExternalCallAction has to be specified in theSEFF of that required service, and is not part of the SEFFof the component requiring it. An ExternalCallAction isalways associated with the signature of another service. Pa-rameters can be passed with ExternalCallActions. If theyinfluence QoS properties, they should be characterised by aParametricParameterUsage (see section 4.4 for further de-tails).
AbstractResourceDemandingAction
BranchAction
BranchTransition
branchCondition : EString
ForkActionInternalAction
LoopAction
iterations : String
StartAction
StopAction
ResourceDemandingBehaviour
1
*
1 1
1
*
1
1
Figure 4: Actions
Figure 4 shows different specialisations of AbstractRes-
ourceDemandingAction. An InternalAction models com-ponent-internal computations of a service possibly combin-ing a number of operations in a single model entity. Thealgorithms executed internally by the component are thusnot visible in the SEFF to preserve the component black-box principle.
Furthermore, each ResourceDemandingBehaviour has oneStartAction with only successors and possibly several Stop-Actions with only predecessors. AbstractActions are ar-ranged into sequences by associating each one with its pre-decessor and successor. Common control flow primitives,such as branch, loop, and fork can also be used to connectAbstractActions.
LoopAction, BranchTransition, and ForkAction containinner ResourceDemandingBehaviours, which again can bemodelled with ResourceDemandingActions. Modelling innerbehaviours reduces the amount of ambiguities in the speci-fication and eases the later analysis. For example, mergingformerly branched control flow paths is well-defined withinner behaviours.
A BranchAction consists of a number of BranchTransi-
tions, which are attributed with branch probabilities.A LoopAction is attributed with the number of iterations.
Control flow cycles always have to be modelled explicitlywith LoopActions, thus an AbstractAction is not allowedto have another action as one of its predecessors and atthe same time one of its successors. This way, it is dis-allowed to specify loops with a probability of entering theloop and a probability of exiting the loop as it is done forexample in Markov models. Loops in Markov models are
restricted to a geometrically distributed number of itera-tions, whereas our evaluation model supports a generallydistributed or even fixed number of iterations, which allowsanalysing many loops more realistically (for more details onloop modelling, see [13]).
So far, we require component developers to model SEFFsmanually by examining the code of their components. In thefuture, we aim at developing static code analysis techniquesand tools assisting in generating these specifications semi-automatically from component source code.
3.4 Usage ModelAs the usage of a component-based system is relevant forQoS analyses, the Palladio Component Model contains anusage model, which allows describing workloads and usagescenarios. It is a domain specific modelling language in-tended for business domain experts, who are able to describethe expected user behaviour of the system. System archi-tects may also construct usage models from requirementsdocuments.
ClosedWorkload
population : EIntthinkTime : EDouble
OpenWorkload
arrivalRate : EDouble
ScenarioBehaviour
UsageModel UsageScenario Workload
1
1
1 * 1 1
Figure 5: Usage Model
The UsageModel (Figure 5) consists of a number of Usage-Scenarios, which in turn consist of one ScenarioBehaviourand one Workload meaning that the ScenarioBehaviour
is executed with the respective Workload. Workloads de-scribe the usage intensity of the system. They can be Open-
Workloads, modelling users that enter with a given arrivalrate and exit the system after they have executed their sce-nario. Or they can be ClosedWorkloads, modelling a fixednumber of users (population), that enter the system, exe-cute their scenario and then re-enter the system after a giventhink time. This resembles the common modelling of work-loads used in performance models like queueing networks.
AbstractUserActionBranchActionBranchTransition
branchCondition : EDouble
ScenarioBehaviour
SystemCallAction
StartAction StopActionParameterUsage
LoopActioniterations : String
0..1
+ predecessor
0..1+ successor
1
*
1*
1
1
1
1 + bodyBehaviour_Loop
1
*
Figure 6: Scenario Behaviour
A ScenarioBehaviour (Figure 6) consists of a sequenceof AbstractUserActions (notice the predecessor, successorassociation). These can be specialised into control flow prim-itives (BranchAction and LoopAction) or SystemCallAc-
tions, which are calls to component interfaces directly acces-sible by users (on the entry level of the architecture). Forks
in the user control flow are not possible, as it is assumedthat one user can only execute a single task at a time. AScenarioBehaviour does not contain resource usage, whichonly can be generated by components.
SystemCallActions contain a number of ParameterUs-
ages to characterise actual parameters.
3.5 Parameter Model
CollectionParameterCharacterisation
type : CollectionParameterCharacterisationType
CollectionParameterUsageCompositeParameterUsage
PrimitiveParameterCharacterisation
type : PrimitiveParameterCharacterisationType
ParameterUsage
«enumeration»PrimitiveParameterCharacterisationType
VALUEBYTESIZEDATATYPE
Parameter
parameterName : EString
«enumeration»CollectionParameterCharacterisationType
NUMBER_OF_ELEMENTSSTRUCTURE
RandomVariable
specification : String
*
1*
1*
1
Figure 7: Parameter Usage
In addition to formal parameters (Parameter), actual pa-rameters can be characterised with ParameterUsages (Fig-ure 7). These characterisations have been modelled espe-cially for QoS analyses. ParameterUsages of primitive pa-rameters (such as int, float, char, boolean, etc.) can becharacterised by their value, bytesize and type.
CollectionParameterUsages (for arrays, lists, sets, trees,hash maps, etc.) are ParameterUsages themselves and canadditionally be characterised by the number of inner ele-ments and their structure (e.g., sorted, unsorted etc.). Theycontain ParameterUsages to abstractly characterise their in-ner elements.
In a CompositeParameterUsage different primitive andcollection parameters can be grouped together with an innerParameterUsage for each of the grouped parameters. Withthis abstraction, more complex parameters (such as records,objects, etc.) can be modelled.
The different attributes like value or bytesize can be spe-cified as random variables, allowing for example to specifya distribution function for the bytesizes of inner elements ofa collection.
3.6 Resource ModelThe Palladio Component Model differentiates between threetypes of resources: active resources, passive resources, andlinking resources. Active resources process jobs on their own(e.g., a CPU processing jobs or a hard disk processing readand write requests). Opposed to this, passive resources donot process jobs on their own. Instead, their possessionis important as they are limited. For example, if there isonly one database connection it can only be used by onecomponent and all other components in need for the sameconnection have to wait. Linking resources enable modellingof communication. It can be any kind of network connectionbut also some abstraction of it, like a RPC call.
Active and passive resources are bundled in resource con-tainers. A resource container is similar to a UML2 deploy-ment node. Resource containers are connected by linking re-sources. The complete resource model is specified by system
deployers, who also assign components to specific resources.In the future, a more refined resource model could be de-signed according to the General Resource Model (GRM) ofthe UML SPT profile [18].
4. PARAMETRIC DEPENDENCIESThe performance of a software component is influenced byits usage [12]. The resource demand may vary dependingon input parameters (e.g., uploading larger files with a com-ponent service produces a higher demand on hard disk andnetwork). Different required services can be called as a resultof different inputs, thus the branch probabilities in the SEFFare most often linked to the usage profile (e.g., required ser-vice A is called if some integer parameter is larger than zero,otherwise service B is called). Furthermore, the parameterspassed to required services (forming a usage model for therequired component) may also depend on a service’s owninput parameters.
The central dilemma of the component developer is thatduring component specification it is unknown how the com-ponent will be used by third parties. Thus, in case of vary-ing resource demands or branch probabilities depending onuser inputs, the component developer cannot specify fixedvalues. However, to help the system architect in QoS pre-dictions, the component developer can specify the depen-dencies between input parameters and resource demands,branch probabilities, or loop iteration numbers in SEFFs.If an usage model of the component has been specified bybusiness domain experts or if the usage of the componentby other components is known, the actual resource demandsand branch probabilities can be determined by the systemarchitect by solving the dependencies.
In the Palladio Component Model, we use random vari-ables to express resource demands or numbers of loop iter-ations. Mathematically, a random variable is defined as ameasurable function from a probability space to some mea-surable space. More detailed, a random variable is a functionX : Ω → R with Ω being the set of observable events andR being the set associated to the measurable space. Ob-servable events in the context of software models can be forexample response times of a service call, the execution of abranch, the number of loop iterations, or abstractions of theparameters, like their actual size or type.
A random variable X is usually characterised by stochas-tical means. Besides statistical characterisations, like meanor standard deviation, a more detailed description is theprobability distribution. A probability distribution yieldsthe probability of X taking a certain value. It is often ab-breviated by P (X = t). For discrete random variables, itcan be specified by a probability mass function (PMF), asused in our component model. The event spaces Ω we sup-port include integer values N, real values R, boolean valuesand enumeration types (like ”sorted” and ”unsorted”).
Additionally, it is often necessary to build new randomvariables using other random variables and mathematicalexpressions. For example, to denote that the response timeis 5 times slower, we would like to simply multiply a ran-dom variable for a response time by 5 and assign the resultto a new random variable. For this reason, our specifica-tion language supports some basic mathematical operations(∗,−,+,/,...) as well as some logical operations for booleantype expressions (==,>,<,and,or,...).
We use the introduced random variables in the following
to provide several examples for specifying dependencies be-tween input parameters and QoS-related specifications. Wealso use random variables in the case study to characterisethe parameters of the calls issued to the system.
4.1 Branch ConditionsIn Figure 8, the ResourceDemandingSEFF of the service Han-dleShipping from an online-store component is depicted. Ithas been specified by a component developer in a paramet-rised form. The service calls required services shipping a cus-tomer’s order with different charges depending on its costs,which it gets passed as an input parameter. If the order’stotal amount is below 100 Euros, the service calls a servicepreparing a shipment with full charges (ShipFullCharges). Ifthe costs are between 100 and 200 Euros, the online storegrants a discount, so ShipReducedCharges is called. Orderspriced more than 200 Euros are shipped for free with theShipWithoutCharges service.
<<ResourceDemandingBehaviour>>
<<ResourceDemandingBehaviour>><<ResourceDemandingBehaviour>>
<<ExternalCallAction>>ShipReducedCharges
<<ExternalCallAction>>ShipFullCharges
<<ExternalCallAction>>ShipWithoutCharges
<<BranchTransition>>branchCondition =PrimitiveParameter(„costs“).primitiveParameterValue(VALUE)<100
<<BranchTransition>>branchCondition =PrimitiveParameter(„costs“).primitiveParameterValue(VALUE)>=100
<<BranchTransition>>branchCondition =PrimitiveParameter(„costs“).primitiveParameterValue(VALUE)>=200
<<BranchTransition>>branchCondition =PrimitiveParameter(„costs“).primitiveParameterValue(VALUE)<200
<<Parameter>>parameterName=“costs“
<<ResourceDemandingSEFF>>HandleShipping
<<BranchAction>>
<<BranchAction>>
Figure 8: Branch Condition Example
The ResourceDemandingSEFF in Figure 8 is an abstractrepresentation of the control flow through the component.Internal computations as well as resource demands of theservice have been abstracted away, because they are notrelevant for QoS analysis in this case.
Once a domain expert specifies the value of the param-eter costs, it can be derived which of the services will becalled. In this example, the domain expert has specified thevalue as a PMF (Table 1) according to a customer analy-sis. The PMF is used in order represent a whole group ofcustomers using the service. It has been specified withinan UsageModel, which is not illustrated here for brevity. Inthis case, the sample space Ω of the PMF consists of integervalues N representing the costs of an order. Note, that thespecification of the domain expert only refers to parame-ters visible at the service interface. The usage specificationscan be made without referring to internals of the componentthus preserving the black box principle.
Costs (Euro) Probability0-49 0.3550-99 0.25
100-149 0.20150-199 0.15
200- 0.05
Table 1: Probability of costs; specified by DomainExpert
To determine the branch probabilities which are requiredfor the QoS analysis, random variables associated with thebranches have to be evaluated. For the first branch node,the left and right branch conditions are denoted as A and B,where A is the event that costs are below 100 Euro and B theevent that costs are larger than 100 Euros. With the usageprofile by the domain expert, their probabilities of becomingtrue can be computed as: P (A) = 0.35 + 0.25 = 0.6 andP (B) = 0.20 + 0.15 + 0.05 = 0.4.
After any branching event X has occured, the samplespace Ω on subsequent nodes is restricted to Ω′ = Ω ∩ X.This has to be considered by the following evaluations. Inthe example, this situation occurs at the second branchnode. The left and right branch conditions are denoted asC and D, where C is the event that the costs are below200 Euros and D the event that the costs are larger than200 Euros. When computing the probabilities, it has to betaken into account, that the sample space has been restrictedby B. Thus, a new sample space Ω′ = Ω ∩ B has beencreated. Using the usage profile from the domain expert,the conditional probabilities are computed as: P (C|Ω′) =P (C ∩Ω′)/P (Ω′) = 0.35/0.4 = 0.875 and P (D|Ω′) = P (D∩Ω′)/P (Ω′) = 0.05/0.4 = 0.125.
4.2 Loop IterationsIn the Palladio Component Model, it is possible to assign anumber of iterations to a loop. This can be done in a pa-rameterisable form, as illustrated by the following example.Figure 9 shows the ResourceDemandingSEFF of the serviceUploadFiles. It gets an array of files as input parameter andcalls the external service HandleUpload within a loop for eachfile. As an example, the component shall be used in a newarchitecture for an online music repository. Users shall up-load music albums via the service, which are then storedone by one in a database that is connected to the serviceHandleUpload.
<<LoopAction>>
<<ResourceDemandingBehaviour>>
<<ExternalCallAction>>HandleUpload
iterations=CollectionParameter(„files“).CollectionParameterCharacterisation(NUMBER_OF_ELEMENTS)
<<Parameter>>parameterName=“files“
<<ResourceDemandingSEFF>>UploadFiles
Figure 9: Loop Example
A domain expert has analysed user behaviour and found
Number of Files Probability8 0.19 0.110 0.211 0.412 0.2
Table 2: Probability for number of files; specified byDomain Expert
that users usually upload albums with 8-12 music files. Thus,a PMF for the number of files in the input parameter fileshas been specified (Table 2).
With the specified dependency to the number of elementsin the input collection, the probability distribution of ran-dom variable Xiter for the number of loop iterations in theResourceDemandingBehaviour can be determined. The re-quired service HandleUpload will be called 8 times (probabil-ity 0.1), 9 times (0.1), 10 times (0.2), and so on (see Table 2).If the dependency had not been specified, it would not havebeen known from the interfaces how often the required ser-vice would have been called. Thus, with the specified PMF,a more refined prediction can be made for varying usagecontexts.
4.3 Parametric Resource DemandBesides branch conditions and loop iterations, resource de-mands can be specified in a parameterised form. In manycases, this is the most influencing factor for varying responsetimes. In Figure 10, the component service ProcessFile re-ceives an input parameter, which is processed internally.The component developer has specified that the resourcedemand of this service depends on the size of the input file,in particular 3 CPU operations are executed for each byteof the file.
<<InternalAction>>
<<ParametricResourceDemand>>demand = PrimitiveParameter(„file“).PrimitiveParameterCharacterisation(BYTESIZE) * 3unit = „CPU instructions“
<<Parameter>>parameterName=“file“
<<ResourceDemandingSEFF>>ProcessFile
Figure 10: Resource Demand Example
Because of varying file sizes due to varying usages, thedomain expert has specified a PMF for the size of the inputfile. After analysing a large number of usage traces from asimilar system, a fine grain distribution function could bespecified, which is shown in Figure 11. Note, that in thisexample the size of the file is the only attribute relevant forthe QoS analysis. Other attributes of the file parameter,such as the value or the type of the file, are irrelevant inthis case and need not to be specified. This is an example ofabstracting unnecessary details from the model and in manycases such abstractions model reality good enough to makesufficiently accurate predictions.
To compute the actual resource demand on the CPU fromthe specification in Figure 10, the underlying PMF can be
Figure 11: File Sizes (PMF), from Domain Expert
obtained by multiplying the PMF for the file sizes by a factorof 3, thus streching the PMF as depicted in Figure 12. In-stead of file sizes, the PMF now denotes the probabilities forthe number of CPU operations, which are executed for thegiven usage context. Once the actual CPU is known fromthe allocation model, on which the component is deployed,the time for executing service ProcessFile can be computedafter specifying the execution time for a single CPU opera-tion.
Figure 12: CPU operations (PMF), computed
4.4 Parametric Parameter UsageWhen calling required services, component services may passparameters. In many cases, these parameters can be fixed inthe implementation. However, sometimes, input parametersfor required service calls actually depend on the providedservice’s own input parameters. In the Palladio ComponentModel, such a dependency can be expressed by attaching aParametricParameterUsage to an ExternalCallAction.
<<ExternalCallAction>>SendFile
<<InternalAction>>CompressFile
<<ResourceDemandingSEFF>>SendCompressed
<<Parameter>>parameterName=“file“
<<ParametricParameterUsage>>PrimitiveParameter(„fileToSend“).PrimitiveParameterCharacterisation(BYTESIZE) = 0.5 * PrimitiveParameter(„file“).PrimitiveParameterCharacterisation(BYTESIZE)
Figure 13: Parametric Parameter Usage Example
As an example, in Figure 13, the ResourceDemandingSEFFof the service SendCompressed is shown. It receives a file
as an input parameter, compresses it using a ZIP algorithm,and then passes it to another component by calling the ser-vice SendFile. The component developer has specified thatthe compression reduces the size of the input files by 50%.
If a domain expert specifies the input file size, or if it hasbeen specified in the ParametricParameterUsage of anothercomponent calling this component, the file size for the inputparameter of the ExternalCallAction can be determined.If the file size has been specified as a PMF (like in the pre-vious example), its domain values have to be multiplied bya factor of 0.5, thus contracting the PMF.
5. SIMULATION FRAMEWORKTo evaluate the model concepts introduced in the previoussections, we have built a prototypical simulation tool. Thistool takes an instance of the Palladio Component Model andbuilds a simulation in order to get the response times of thespecified workloads. In so doing, we validate two things.First, if the meta model is appropriate and can be usedto model an example system, e.g., if all necessary modelconcepts are available. Second, by comparing the predictedvalues to measured values of an implemented architecture,we can evaluate if the introduced parametric specificationscan be used to give realistic predictions. The latter arepresented in the next section. This section briefly gives somedetails on the implementation of our simulation.
5.1 Technical foundationThe simulation is implemented as a stand-alone Java appli-cation using the Java simulation framework Desmo-J [22].The simulation reads an instance of the Palladio ComponentModel. The construction of simulated (active and passive)resources and loading the configured workload model startsthe simulation. The software architecture is evaluated onthe fly using visitors as depicted in the following.
5.2 VisitorsThe workloads stored in the model instance are transformedinto simulated workload drivers, which simulate the specifiedworkload scenario. This is done by traversing the specifiedusage scenario from the start action to any stop action forthe specified number of clients. The behaviour of a compo-nent’s service is simulated analogously traversing it from itsstart to its stop actions. Sensors in the simulation environ-ment record the execution times during the simulation. Theresults of the simulation run are reported when the simula-tion ends.
Depending on the type of workload, i.e., closed workloador open workload, workload drivers are instantiated accord-ing to the respective workload’s semantics. For closed work-loads, the behaviour of each simulated user is executed, thenthe workload driver waits for the given think time and af-terwards starts from the beginning. For open workloads,the workload driver starts a simulation of the workload be-haviour to meet the specified arrival rate.
The traversal of the behaviour is implemented using theVisitor design pattern [10, p. 331]. A visitor visits the ac-tions of a behaviour until it reaches a stop action. At eachnode simulation code is executed which simulates the spec-ified action in this node. At control flow nodes (branch,loop, ...) the corresponding inner behaviour is executed us-ing a new visitor started at the inner start node. At externalcalls the simulation looks up the respective required inter-face and the connected component. A new visitor is thenstarted simulating the external service’s behaviour.
At internal actions the resource demand is determinedand a respective demand is put on the simulated resources.
For active resource - at present - we only support a FIFOstrategy. Thus, if the resource is busy, the request is putinto a wait queue until the resource becomes available.
Several specifications in the SEFF like number of loopiterations, branch conditions, and resource demand dependon other random variables, i.e., parameter abstractions. Asample of this random variable is generated by the evalua-tion of the definition as outlined in section 4. For this, thespecification of the random variable is parsed. The parsetree is evaluated afterwards. For any random variable inthe parse tree the simulation framework’s random numbergenerators are used to get samples. Mathematical opera-tions are evaluated using their normal semantics. The re-sult of the evaluation is the desired sample of the dependingrandom variable.
5.3 Simulated Stack-FrameSpecial treatment is required for parameter abstractions,since they are only valid during the execution of the calledmethod. To simulate this behaviour, we introduced simu-lated stack frames in alignment with the real execution of asoftware system.
<<InternalAction>><<ExternalCallAction>>
<<ResourceDemandingSEFF>>
Visi
tor
<<Parameter>>parameterName=“files“
<<ParametricResourceDemand>>demand = file.Bytesizeunit = „CPU operations“
StackFramefile.Bytesize 20files.Number_Of_Elements 23… ...
Figure 14: A behaviour visitor and the simulatedstack frame
Whenever an external call is to be simulated, a new sim-ulated stack frame is built analogously to the methods stackframe. To initialize a stack frame the random variables char-acterising the parameters of the called service are evaluatedand the result is stored in the stack frame. It is then passedover to the visitor for the called behaviour (c.f. figure 5.3).In so doing, we simulate the performance relevant part ofthe usage context of the components.
When the simulated control flow returns to the caller theevaluation is continued after the external call using againthe old call stack.
5.4 Simulation EndThe simulation should come to an end as soon as the PMFof the workload scenario’s execution time has been approx-imated in a way that new simulated measurements don’tchange the distribution significantly. This can be done byevaluating the mean and standard deviation of the result-ing PMF. If the change in these characterising attributes ofthe PMF is below a certain configurable threshold after newsimulated measurements are added, the simulation stops.Meanwhile the simulation supports live updates of its sen-sors, so that the system architect can watch the simulation
proceed and cancel it in advance if the results are sufficientfor the analysis.
6. LIMITATIONS / ASSUMPTIONSThere are several assumptions and limitations in the currentversion of the Palladio Component Model and the simulationtool. We briefly summarize the most important ones in thefollowing.
Static architecture: The modelled architecture is as-sumed to be static. This means that neither the connectorschange nor that the components can move like agents todifferent hardware resources.
Abstraction from state: It is assumed that the be-haviour of the system is determined by the parameters ofthe service calls only. No internal state of components orthe runtime environment is regarded.
Information availability: Is is assumed that the neces-sary model information like service effect specifications andparametric dependencies are available and have been spec-ified by the component developer, system architect, systemdeployer and domain expert. Future work is directed to re-trieve as much information as possible from the automatedanalysis of component code.
Limited support for concurrency: Quality propertiesof concurrent systems are hard to predict. Especially onmulti-core processor systems several effects like the CPUcaches lead to differences between an observed system timingbehaviour and an appropriate prediction in our experience.
Limited support for modelling the runtime envi-ronment: Our resource model assumes that processing re-sources can be described by a processing rate only. But oftenmore than a single influence factor is important. For exam-ple, to characterize modern CPUs by the clock frequencyalone, is often not sufficient any more. The CPU architec-ture, pipelining strategy, or the cache sizes as well as theruntime and middleware platform and their configurationscan have a significant influence on the execution time (of anoperation) [17].
Parameter immutability: Parameters of methods aretreated as being read only during a single method execution.Hence, a parameter abstraction is not changeable during theevaluation of a single behaviour.
No return values: Service call return values are not yetmodelled. Hence, for behaviours which depend on the resultof an external call, the accuracy of the prediction might beinsufficient.
Mathematical assumptions: Some random variablesare assumed to be independent. For example, during theevaluation of a loop iterating through a collection, the char-acteristics of collection’s inner elements are not kept con-stant. This limitation is subject to future model enhance-ments.
7. CASE STUDYIn the following, we report on an initial case study to vali-date predictions made by simulating instances of the Pal-ladio component model. This case study is meant as aproof-of-concept evaluation, not as a sound experimentalevaluation of the approach on an industrial sized applica-tion, which is planned for the future. We compare pre-dictions based on architectural specifications with measure-ments made with an implementation of the architecture.The case study involves an online shop, which allows users
uploading and downloading music files [15]. Several param-eter dependencies, which will be explained in the following,can be found in the architecture, so we can test the mod-elling capabilities of our component model.
As we want to support early design decisions with ourapproach, we modelled and implemented two design alter-natives for the online shop. Before the case study, we raisedthe following questions:
1. Are the predictions based on our simulation modelgood enough to support the decision for the designalternative with the actual best performance given aspecified usage model?
2. Can the errors made by the predictions be quantifiedand explained? To answer this question, we analyseddeviations between predictions and measurement inmore detail.
7.1 ArchitectureThe architecture of the ”Web Audio Store” (Figure 15) con-sists of three tiers (client, application server, database) [15].Customers interact with the store via web browsers that ac-cess the component WebForm using DSL lines with a through-put of 128 KBits/s. Several components are located onthe application server in the middle tier: The componentWebForm is connected to the AudioStore component, whichcontrols and manages the whole store. It interacts with auser management component and a database adapter thathandles the connection to a MySQL server on the databasetier. The network between the application server and thedatabase is a dedicated line with a maximum throughput of512 KBit/s.
As a performance critical use case, the response timesfor uploading music files to the store shall be analysed andimproved. It is possible for users to upload multiple filesat once to add complete music albums to the store. Thisusage scenario is described in Figure 16(a). In this case,users upload 8-12 files with the probabilities found in theFigure 16(b) (as ”iterations=...”) and files sizes between3500 and 4500 KBytes. Upon clicking the button ”UploadFiles” the service UploadFiles of the WebForm componentis invoked, whose behaviour is shown in Figure 16(b). Thisbehaviour in turn invokes services from the AudioStore com-ponent. The parametric dependencies for the loop and thebyte size of subsequent input parameters are shown in thefigure. For example, the number of loop iterations dependson the number of input files. Other annotations needed forthe simulation are omitted in the illustration for brevity.
Because response times of this use case are considered toohigh, the system architect has come up with a design alter-native, which is shown within the dashed box in Figure 15and which is transparent for the clients. It is proposed toinsert an encoder component (OggEncoder) into the archi-tecture using an adapter (EncodingAdapter), which imple-ments the IAudioDB interface. The SEFFs of these com-ponents are illustrated in Figure 17(a)-17(b). The encoderis able to reduce the size of the music files by a factor of2/3. Thus, the time for using the network connection to thedatabase server can be reduced, because smaller files haveto be sent. However, encoding the files is computationalintensive and hence, costs an amount of time. With theperformance prediction, the tradeoff between faster networktransfer and reencoding overhead shall be evaluated.
AudioStoreWebForm UserManagement
EncodingAdapterOggEncoder DBAdapter
Web-Browser
MySqlClient MySqlDB
<<ResourceContainer>>Application Server
<<ResourceContainer>>Database Server
<<ResourceContainer>>Client
<<LinkingResource>>throughput = 128unit = KBit/s
<<LinkingResource>>throughput = 512unit = KBit/s
<<Interface>>HTTP
<<Interface>>IEncoder
<<Interface>>IAudioDB
<<Interface>>IAudioStore
<<Interface>>IUserManagement
<<Interface>>IUserDB
<<Interface>>ICommandIConnectionIDataReader
Figure 15: Web Audio Store Architecture
<<SystemCallAction>>WebForm.UploadFiles
<<LoopAction>><<ResourceDemandingBehaviour>>
<<SystemCallAction>>SelectFiles
iterations = (8, 0.1; 9, 0.1; 10, 0.2; 11, 0.4; 12, 0.1)
PrimitiveParameter(„file“).PrimitiveParameterCharacterisation(BYTESIZE) = (3500, 0.1; 4000, 0.6; 4500, 0.3)CollectionParameter(„files“).CollectionParameterCharacterisation(NUMBER_OF_ELEMENTS)=iterations
<<ScenarioBehaviour>>
(a)
<<ResourceDemandingSEFF>>WebForm.UploadFiles
<<ExternalCallAction>>IAudioStore.FinalizeUpload
<<LoopAction>>
<<ExternalCallAction>>IAudioStore.HandleUpload
iterations = CollectionParameter(„files“).CollectionParameterCharacterisation(NUMBER_OF_ELEMENTS)
PrimitiveParameter(„fileToUpload“).PrimitiveParameterCharacterisation(BYTESIZE)=PrimitiveParameter(„file“).PrimitiveParameterCharacterisation(BYTESIZE)
<<ResourceDemanding
Behaviour>>
(b)
Figure 16: Original Design: Usage Model, SEFF
7.2 ResultsFirst, we modelled and simulated both design alternatives,then we also implemented both alternatives in C# usingASP.NET. Using the workloads from the models, the re-sponse times for the described use case of the implementa-tions were measured.
Compared to [15], we only used measured time consump-tions in our prediction model for calls to the database, i.e.,for submitting uncompressed files. The time consumption ofsubmitting compressed files as well as the encoding of fileshad been specified parametric as introduced in the previoussection. In so doing, we further weakened the assumptionswhich we made when we did the predictions in [15].
For the original design without encoder, the simulationresults and the measured time consumptions are presentedin Figure 18. To allow a visual comparison of the results, weshow both histograms in a single diagram by putting themon top of each other. The simulation results are drawn inlight grey and the measured results in dark grey. Overlapsof both functions result in medium grey bars.
Both functions match to a large extent. Hence, our sim-ulation is capable to predict the response time behaviour ofthis design alternative based on a system model. In this vari-ant of the architecture, the main influence on the responsetime is created by the amount of files in a batch upload. As
<<ExternalCallAction>>IEncoder.EncodeFile
<<ResourceDemandingSEFF>>EncodingAdapter.
InsertAudioFile
<<ExternalCallAction>>IAudioDB.InsertAudioFile
PrimitiveParameter(„fileToEncode“).PrimitiveParameterCharacterisation (BYTESIZE) = PrimitiveParameter(„file“).PrimitiveParameterCharacterisation (BYTESIZE)
PrimitiveParameter(„fileToDB“).PrimitiveParameterCharacterisation (BYTESIZE) = PrimitiveParameter(„encodedFile“).PrimitiveParameterCharacterisation (BYTESIZE)
(a)
<<InternalAction>>WriteFileToDisk
<<ResourceDemandingSEFF>>OggEncoder.EncodeFile
<<InternalAction>>ReadEncodedFileFromDisk
<<InternalAction>>ExecuteEncoder
PrimitiveParameter(„encodedFile“).PrimitiveParameterCharacterisation (BYTESIZE) = 0.667 * PrimitiveParameter(„fileToEncode“).PrimitiveParameterCharacterisation (BYTESIZE)
(b)
Figure 17: Design Alternative: Encoding Adapter
we modelled the distribution of the amount of files accord-ing to what we actually used when we measured our system,this result was expected.
For the design alternative with the encoder, we first com-pared the simulation results of the call to EncodeFile withthe measured values as we used a parametric dependencyon the bytesize of the file to encode. The dependency wasderived by a rough guess looking at a few sample encoderruns. The result is depicted in Figure 19.
It can be seen that our estimated dependency is not ex-actly matching, but still quite good. Using the estimatedtimes of EncodeFile and the compression rate of 2/3 wesimulated the whole system. The results are shown in figure20.
Although we used the mentioned approximations of theparametric dependencies, the measured and the simulationresults still match quite good. Moreover, we are able tosee that the design alternative with the encoder is approx-imately 200 seconds faster. Our result favoured the designalternative with the encoder, which is indeed the faster oneas validated by the measurements.
To answer the question whether observable prediction er-rors can be explained, we take a closer look at figure 20 whichhas such prediction errors. It can be seen that the measured
Figure 18: Measured and simulated results for theresponse time of UploadFiles in the design alterna-tive without encoder
Figure 19: Measured and simulated response timesof EncodeFile
values are a bit lower (approx. 10 seconds) than the pre-dicted values. This can be explained by two issues. First,the guessed dependency for EncodeFile is not as accurateas it could be. A linear regression based on some measuredtime consumptions for different bytesizes could help to builda better estimation of the actual dependency. Second, themathematical assumptions on the independence of randomvariables (c.f. section 6) is violated. The bytesize of the filebeing uploaded to the database depends on the bytesize ofthe file being sent to the encoder (we know that it is 2/3 ofthat size). The latter is a shortcoming of our current modelabstraction and will be addressed in future work by allowingto specify correlating random variables.
8. CONCLUSIONSThis paper presents a meta-model designed to support theprediction of extra-functional properties of component basedsoftware architectures. Different possible usage contexts ofa component are supported by this model. Additionally,parametric context dependencies to system resources anddependencies to parameter usages can be modelled. Thesoundness of the model concepts is validated by a simulationtool capable of simulating model instances. The results ofthe simulation are validated in a case study.
The presented method is designed to support early designtime quality evaluations of component based software archi-tectures. Based on models, a system architect can evaluate
Figure 20: Measured and simulated results for theresponse time of UploadFiles (architecture with en-coder)
the quality of the modelled system. The evaluation of designalternatives can be performed by changing the input modelsand re-running the simulation tool. The focus on systemmodels enables a quick feedback cycle by the use of MDDideas.
Our work will be extended in the future into several direc-tions. The Palladio Component Model serves as a basis forfurther model transformations. Especially the generation ofcode skeletons for different industrial component models isan important research topic. Additionally, we try to gener-ate application prototypes from model instances which offersimilar QoS properties by enriching the aforementioned codeskeletons with time consuming dummy functions.
The simulation tool is implemented as a prototype. Thisprototype can be extended to support all model conceptsof our component model and to address some of the knownlimitations. Especially for systems with a lot of concurrencythe simulation can serve as a basis for experiments and com-parisons with running systems.
The specification of the model concepts as well as theirintended semantics is still an ongoing activity. Especiallythe concept of using random variables for the specificationof parametric dependencies is still a fairly new concept andneeds further validation. Additionally, we are developingtools to ease the creation of model instances of the PalladioComponent Model by the implementation or generation ofgraphical editors based on the Eclipse platform. These edi-tors allow the specification of model instances in a graphicalway.
Last but not least, we also plan to extend our mathemat-ical analysis model to support additional concepts of thePalladio Component Model. Our model which is based onstochastical regular expressions should also be included intoa MDD process which allows to derive it directly from in-stances of the Palladio Component Model.
9. REFERENCES[1] L. B. Arief and N. A. Speirs. A UML Tool for an
Automatic Generation of Simulation Programs. InProceedings of the Second International Workshop onSoftware and Performance, pages 71–76. ACM Press,2000.
[2] S. Balsamo, A. D. 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. Balsamo and M. Marzolla. A Simulation-BasedApproach to Software Performance Modeling. InProceedings of the 9th European software engineeringconference held jointly with 10th ACM SIGSOFTinternational symposium on Foundations of softwareengineering, pages 363–366. ACM Press, 2003.
[4] S. Becker, L. Grunske, R. Mirandola, and S. Overhage.Performance Prediction of Component-Based Systems:A Survey from an Engineering Perspective. InR. Reussner, J. Stafford, and C. Szyperski, editors,Architecting Systems with Trustworthy Components,volume 3938 of LNCS, pages 169–192. Springer, 2006.
[5] A. Bertolino and R. Mirandola. CB-SPE Tool:Putting Component-Based Performance Engineeringinto Practice. In I. Crnkovic, J. A. Stafford, H. W.Schmidt, and K. C. Wallnau, editors, Proc. 7thInternational Symposium on Component-BasedSoftware Engineering (CBSE 2004), Edinburgh, UK,volume 3054 of Lecture Notes in Computer Science,pages 233–248. Springer, 2004.
[6] E. Bondarev, P. de With, M. Chaudron, andJ. Musken. Modelling of Input-Parameter Dependencyfor Performance Predictions of Component-BasedEmbedded Systems. In Proceedings of the 31thEUROMICRO Conference (EUROMICRO’05), 2005.
[7] V. Cortellessa. How far are we from the definition of acommon software performance ontology? In WOSP’05: Proceedings of the 5th International Workshop onSoftware and Performance, pages 195–204, New York,NY, USA, 2005. ACM Press.
[8] M. de Miguel, T. Lambolais, M. Hannouz,S. Betge-Brezetz, and S. Piekarec. Uml extensions forthe specification and evaluation of latency constraintsin architectural models. In WOSP ’00: Proceedings ofthe 2nd international workshop on Software andperformance, pages 83–88, New York, NY, USA, 2000.ACM Press.
[9] E. Eskenazi, A. Fioukov, and D. Hammer.Performance prediction for component compositions.In Proceedings of the 7th International Symposium onComponent-based Software Engineering (CBSE7),2004.
[10] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.Design Patterns: Elements of ReusableObject-Oriented Software. Addison-Wesley, Reading,MA, USA, 1995.
[11] V. Grassi, R. Mirandola, and A. Sabetta. From Designto Analysis Models: a Kernel Language forPerformance and Reliability Analysis ofComponent-based Systems. In WOSP ’05:Proceedings of the 5th international workshop onSoftware and performance, pages 25–36, New York,NY, USA, 2005. ACM Press.
[12] D. Hamlet, D. Mason, and D. Woit. Component-BasedSoftware Development: Case Studies, volume 1 ofSeries on Component-Based Software Development,chapter Properties of Software Systems Synthesizedfrom Components, pages 129–159. World ScientificPublishing Company, March 2004.
[13] H. Koziolek and V. Firus. Parametric PerformanceContracts: Non-Markovian Loop Modelling and anExperimental Evaluation. In Proceedings ofFESCA2006, Electronical Notes in Computer Science(ENTCS), 2006.
[14] H. Koziolek and J. Happe. A Quality of Service DrivenDevelopment Process Model for Component-basedSoftware Systems. In Component-Based SoftwareEngineering, volume 4063 of Lecture Notes inComputer Science. Springer-Verlag GmbH, July 2006.
[15] H. Koziolek, J. Happe, and S. Becker. Parameterdependent performance specification of softwarecomponents. In Proceedings of the SecondInternational Conference on Quality of SoftwareArchitectures (QoSA2006), number To appear inLNCS. Springer-Verlag, Berlin, Germany, 2006.
[16] K.-K. Lau and Z. Wang. A Taxonomy of SoftwareComponent Models. In Proceedings of the 31stEUROMICRO Conference, pages 88–95. IEEEComputer Society Press, 2005.
[17] Y. Liu, A. Fekete, and I. Gorton. Design-LevelPerformance Prediction of Component-BasedApplications. IEEE Transactions on SoftwareEngineering, 31(11):928–941, 2005.
[18] Object Management Group (OMG). UML Profile forSchedulability, Performance and Time. http://www.omg.org/cgi-bin/doc?formal/2005-01-02,January 2005.
[19] R. H. Reussner, I. H. Poernomo, and H. W. Schmidt.Reasoning on Software Architectures withContractually Specified Components. In A. Cechich,M. Piattini, and A. Vallecillo, editors,Component-Based Software Quality: Methods andTechniques, number 2693 in LNCS, pages 287–325.Springer-Verlag, Berlin, Germany, 2003.
[20] M. Sitaraman, G. Kuczycki, J. Krone, W. F. Ogden,and A. Reddy. Performance Specification of SoftwareComponents. In Proceedings of the 2001 symposiumon Software reusability: putting software reuse incontext, 2001.
[21] C. U. Smith and L. G. Williams. PerformanceSolutions: A Practical Guide to Creating Responsive,Scalable Software. Addison-Wesley, 2002.
[22] University of Hamburg, Department of ComputerScience. The DESMO-J Homepage. http://asi-www.informatik.uni-hamburg.de/desmoj/.
[23] M. Woodside, D. C. Petriu, H. Shen, T. Israr, andJ. Merseguer. Performance by unified model analysis(PUMA). In WOSP ’05: Proceedings of the 5thInternational Workshop on Software and Performance,pages 1–12, New York, NY, USA, 2005. ACM Press.
