Performance Prediction Process

Model-based performance prediction methods work according to a common process which is depicted in figure2.10.

The process starts with a software system’s model. The respective system can be an already existing system, but it needs not necessarily. The system model is expressed in a design-oriented modelling language like the UML. Hence, it is called the design model. It is the task of the software designer to create it. Usually, this model exists already as part of the software engineering process without performance engineering.

Performance prediction needs additional information not present in most design lan- guages like UML. In such cases, the first step in the process is to annotate the design model with performance data. For UML models, UML profiles determine the amount of additional data. The annotations cover resource demands, branching probabilities, input parameter characterisations, workload specifications, etc.

Software Model Annotated Software Model transformation Prediction Results feedback QoS Analysis Model analyse / simulation Software System models estimate/ measure Queuing Networks, Stochastic Petri Nets,

Stochastic Process Algebras, Simulation, ... Hidden in Tools Response Time, Throughput, Failure Probability, ...

UML Performance Profile, QML, ...

UML,ADL, ...

Legend

Artefact Activity Relation

Figure 2.10: Model-based Performance Prediction Process (based on (Object Management

Group (OMG),2005a, p. 9-2))

.

The following three process steps should be executed by tools. First, these tools trans- form the annotated input model into a performance (QoS) analysis model, e.g., a queue- ing network model. Second, (standardised) tools solve the prediction model instance, resulting in metrics on the elements of the prediction model like overall response time or the queue length of a specific wait queue. The set of available metrics depends on the modelling formalism and its solver’s capabilities.

Finally, the prediction tool relates the prediction results back to the originating soft- ware model. It stores the results as annotations on elements of the design model. The feedback is supposed to answer the evaluation questions, for example, whether a specific response time maximum can be reached with the given workload and resources. Ad- ditionally, in cases in which the results indicate insufficient performance, the feedback should indicate the main sources of these issue.

The final step is crucial for the overall success of the prediction method. However, it is difficult to realise because of the semantic differences between the analysis model and the design model. At least, the whole transformation tool chain needs tracing capabilities to trace back elements of the analysis model into elements of the design model. But even in the context of fully traceable transformations, the source of a performance issue can be ambiguous. Imagine the analysis results in a resource being overloaded. The question re- mains if it is overloaded because of too many requests arriving or because of the requests being too resource consuming. Even if an answer exists to this question, the questions

remains which part of the software must be altered.

Input Models The performance prediction process introduced in this section uses an-

notated models for the transformation into analysis models. For many prediction meth- ods this means UML models annotated using the UML profile for Schedulability, Per- formance and Timing (UML-SPT, Object Management Group (OMG) (2005b)) designed for UML 1.4. Other options are the UML Profile for QoS (also designed for UML 1.x,

Object Management Group (OMG)(2005a)), and the UML-MARTE profile (designed for

UML2, currently under construction, Object Management Group (OMG)(2006f)). Other meta-models explicitly designed for QoS predictions already contain measures to add performance information to the design model, for example KLAPER (Grassi et al.,2005). However, the amount of information is similar.

UML-SPT Profile Because of its widespread use in current performance prediction ap-

proaches, the following paragraph briefly introduces the UML-SPT profile. The profile consists of three main parts: modelling of real-time, modelling of schedulability, and modelling of performance. A general resource model is available for use in all three parts. Only the performance and resource model relate to the context of this thesis.

In the performance model, scenarios described as sequence or activity diagrams define performance critical execution paths. Scenarios consist of a sequence of steps. The first step caries annotations specifying the workload of the scenario. Workloads can either be closed or open. In a closed workload, a population of n users execute the scenario concurrently. After finishing a scenario run, they hold for a short delay called think time after which they execute the scenario again. In an open workload, users, which enter the scenario at a specific arrival rate, execute the scenario one time.

Annotations on steps specify performance relevant information like the resource de- mand of the step in time units, average repetition count, or execution probabilities. Anno- tations for resources are twofold. The stereotype PAResource marks software resources having their own thread of control, resources marked with PAHost represent hardware processors. The later, usually denoted as UML2 nodes, carry annotations on their pro- cessing rate, scheduling policy, and context switching time. PAResources have tagged values for the capacity of the resource, time to acquire and release, and scheduling policy. In addition to the annotations, SPT supports the use of variables and mathematical expressions in tagged values. In this way, additional expressiveness is available. For example, the specification of resource demands becomes hardware independent if a con- version factor is multiplied with each demand expressed in an independent unit, e.g., a demand of 10 CPU instructions multiplied by 1 ms per instruction results into a demand

of 10 ms.